Chapter 2 The Language: Rationale and Fundamentals (Part II) Nick Russell Arthur ter Hofstede

Outline Part II The BPM Landscape Conceptual Foundations the Workflow Patterns Initiative Control-flow patterns

Business Process Management (BPM) “Supporting business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information” W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske. Business Process Management: A Survey. In W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske, editors, International Conference on Business Process Management (BPM 2003), volume 2678 of Lecture Notes in Computer Science, pages 1–12. Springer-Verlag, Berlin, 2003.

Setting the scene – BPM: what and why? Genesis in the fields of office information systems and workflow technology Support for coordination of humans and applications in performing business activities Explicit representation of control flow and data dependencies, and resourcing strategies Benefits: Improved efficiency (time, cost) Compliance Improved responsiveness

Evolution of BPM technology Application Application Client Device Client Device Client Device User Interface User Interface User Interface User Interface User Interface Application Application Application Application Logic Application Logic Application Logic Application Logic Service Service Service Business Rules Business Rules Business Rules Business Rules Rules Engine Control Flow Control Flow Control Flow Business Rules Data Workflow BPMS Control Flow Control Flow Resourcing Resourcing Database System Database System Database System Database System Data Data Data Data 1960s 1970s 1980s 1990s 2000s

Gartner top 10 strategic technologies 2008 Green IT Unified communications Business process modeling Metadata management Virtualization 2.0 Mashup & composite apps Web platform & WOA (software as a service) Computing fabric Real world web Social software     

BPM tools in active use by practitioners BPTrends, The State of Business Process Management 2008

Scope of BPMS offerings M. Dumas, W.M.P van der Aalst, A.H.M ter Hofstede, Process-Aware Information Systems: Bridging People and Software through Process Technology, John Wiley & Sons, 2005

The BPM lifecycle Business Process Modelling Tools diagnosis process design Project Management Tools process enactment Workflow Management Systems process implementation M. Dumas, W. van der Aalst, A. ter Hofstede, Process-Aware Information Systems: Bridging People and Software through Process Technology, John Wiley & Sons, 2005

Problems in the BPM field Lack of commonly accepted conceptual foundations Lack of proper formal foundations (despite the rhetoric …) No lack of proposed standards … Tools are typically hard to use, expensive and not easily integrated Lack of support for processes that need to change on-the-fly Lack of proper support for exceptions Limited support for design time analysis (verification and validation) Resource perspective does not match real-world needs Insufficient support for inter-process communication

Workflow animation © Wil van der Aalst, Vincent Almering and Herman Wijbenga

Lack of commonly accepted conceptual foundations How do various workflow environments deal with this? A B C D OR AND Forbid Execute D once, ignore second triggering Execute D twice Execute D once or twice depending on execution … SAP workflow ? HP Change Engine Werve, Forte conductor (numera uppköpt av SUN) Staffware

BPMN: handling of concurrent execution threads

Staffware: handling of concurrent execution threads

Workflow Patterns Initiative Started in 1999, joint work TU/e and QUT Objectives: Identification of workflow modelling scenarios and solutions Benchmarking Commercial BPM products (MQ/Series Workflow, Staffware, etc) Open source workflow products (OpenWFE, jBPM, Enhydra Shark) Proposed standards for web service composition (BPML, BPEL) Process modelling languages (UML, BPMN) Foundation for selecting workflow solutions Home Page: www.workflowpatterns.com Primary publication: W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barros, “Workflow Patterns”, Distributed and Parallel Databases 14(3):5-51, 2003. Citations: 1,500+ (Google Scholar); 500+ (Scopus); 300+ (Web of Science) Evaluations of commercial offerings, research prototypes, proposed standards for web service composition, etc

Workflow Patterns Framework Control-flow P:s 20 W. van der Aalst A. ter Hofstede B. Kiepuszewski A. Barros The ordering of activities in a process 2000 CoopIS’2000 DAPD’2003 2003 Jun 2005 Resource P:s - 43 Resource definition & work distribution in a process N. Russell W. van der Aalst A. ter Hofstede D. Edmond CAiSE’2005 Oct 2005 Data P:s - 40 N. Russell A. ter Hofstede D. Edmond W. van der Aalst Data representation and handling in a process ER’2005 Control-flow P:s 43 - 23 new patterns Formalised in CPN notation TR N. Russell A. ter Hofstede W. van der Aalst N. Mulyar Sep 2006 revised Exception P:s Exception handling in a process CAiSE’2006 N. Russell W. van der Aalst A. ter Hofstede Jun 2006 time These perspectives follow S. Jablonski and C. Bussler’s classification from: Workflow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, 1996

Workflow Patterns Framework Control-flow P:s 20 2000 2003 XPDL, BPEL4WS, BPML, WSFL, XLANG, WSCI, UML AD 1.4 UML AD 2.0, BPMN COSA FLOWer Eastman Meteor Mobile I-Flow Staffware InConcert Domino Workflow Visual Workflow Forte Conductor MQSeries/Workflow SAR R/3 Workflow Verve Workflow Changengine Jun 2005 Resource P:s - 43 BPEL4WS UML AD 2.0 BPMN Staffware WebSphere MQ FLOWer COSA iPlanet XPDL, BPEL4WS UML AD 2.0, BPMN MQSeries Data P:s - 40 Oct 2005 Exception P:s Jun 2006 Staffware WebSphere MQ FLOWer COSA iPlanet XPDL 2.0, BPEL4WS 1.1, BPMN Control-flow P:s 43 Sep 2006 revised WebSphere I.D. SAP Filenet Oracle BPEL BPEL4WS, XPDL 2.0, UML AD 2.0 BPMN, EPC (ARIS) time Eva l ua t I on s Language Development: YAWL/newYAWL

Pattern validation: tool evaluation Identify patterns Set evaluation criteria Select tools to be assessed Assess pattern support Review findings with vendors

Impact of the Workflow Patterns Systems inspired or directly influenced by the patterns FLOWer 3.0 of Pallas Athena Ivolutia Orchestration Bizagi of Vision Software OpenWFE (an open source WFMS) Staffware Process Suite Zebra (an open source WFMS) Pectra Technology Inc.’s tool Alphaflow (an open source WFMS) Lynx Workflow by InsuraPro jBPM (a free workflow engine) Use of the workflow patterns in selecting a WFMS the Dutch Employee Insurance Administration Office the Dutch Justice Department Other Pattern-based evaluations (e.g. ULTRAflow, OmniFlow, @enterprise, BPMN) Main patterns papers are all highly cited Education (used in teaching at 10+ Universities) Web site: 300+ visits on an average working day

What is a pattern ? “Abstraction from concrete form which keeps recurring in specific, non-arbitrary contexts” D. Riehle and H. Züllighoven. Understanding and Using Patterns in Software Development. Theory and Practice of Object Systems 2(1):3-13, 1996. In process context: Imperative in format Not dependent on actual products/technologies Motivated Solution-oriented Components Description: what is it? Synonym(s) Example(s) Motivation: why needed? Context: conditions + CPN formalisation Implementation: how typically realised? Issues: what problems can be encountered? Solutions: how and to what extent can these problems be overcome? Evaluation criteria

Business process perspectives: ARIS (source: A. W Business process perspectives: ARIS (source: A.W. Scheer, ARIS – Business Process Modelling, Springer, Berlin, Germany, 2000.)

Business process perspectives: CIMOSA (source: F. B Business process perspectives: CIMOSA (source: F.B. Vernadat, Enterprise Modeling and Integration. Chapman and Hall, London, UK, 1996.)

Business process perspectives: Zachman Framework (source: J.A. Zachman. A framework for information systems architecture. IBM Systems Journal, 26(3):276-292, 1987.) Source:

Workflow perspectives: control-flow and data Control-flow perspective Focuses on the representation and execution of processes in terms of tasks and arcs indicating how the thread of control is passed between them Abstracts from the actual implementation of individual tasks Data perspective Focuses on the representation and utilisation of data in a process context Considers both internal and external data resources and the interactions between them

Workflow perspectives: resource Focuses on the manner in which work is offered to, allocated to and managed by process participants Considers both the system and resource perspectives Assumes the existence of a process model and related organisational and work distribution models Takes into account differing operational paradigms: richness of process model (esp. allocation directives) autonomy of resources alternate routing mechanisms work management facilities

Control-flow patterns overview

Classes of control-flow patterns Branching Patterns capture branching scenarios in processes. Synchronisation Patterns describe synchronization scenarios arising in processes. Repetition Patterns describe various ways in which repetition may be specified. Multiple Instances (MI) Patterns delineate situations with multiple threads of execution in a workflow which relate to the same activity. Concurrency Patterns reflect situations where restrictions are imposed on the extent of concurrent control-flow in a process instance Trigger Patterns catalogue the different triggering mechanisms appearing in a process context. Cancellation and Completion Patterns categorise the various cancellation scenarios that may be relevant for a workflow specification. Termination Patterns address the issue of when the execution of a workflow is considered to be finished.

Branching constructs AND Split Parallel split, initiation of parallel threads OR Split Multi-choice, thread of control is passed to one or more outgoing branches XOR Split Exclusive choice, thread of control is passed to exactly one of the outgoing branches Deferred choice, thread of control is passed to exactly one of the outgoing branches. Selection decision is deferred to the user and/or operating environment. Thread Split Thread split, thread of control is split into multiple concurrent threads in same branch.

Branching patterns Parallel split, initiation of parallel threads Multi-choice, thread of control is passed to one or more outgoing branches Exclusive choice, thread of control is passed to exactly one of the outgoing branches Deferred choice, thread of control is passed to exactly one of the outgoing branches. Selection decision is deferred to the user and/or operating environment. Thread split, thread of control is split into multiple concurrent threads in same branch.

Parallel split Definition CPN: The divergence of a branch into two or more parallel branches each of which execute concurrently. Definition CPN:

Multi-choice The divergence of a branch into two or more branches such that when the incoming branch is enabled, the thread of control is immediately passed to one or more of the outgoing branches based on a mechanism that selects one or more outgoing branches. Definition CPN: context condition: choice construct has access to all required resources when making routing decision

Multi-choice Straightforward when transition conditions are supported (e.g. MQSeries/Workflow, Verve, Forte Conductor). Otherwise: and-split followed by xor-splits exhausting all combinations; xor-split followed by and-splits (only needed if combination contains more than one branch) exhausting all combinations.

Multi-choice: Example (source: [AHKB03] p.14) y>7 Solution 1: A A Solution 2: AND x<5 & y>7 XOR x5 & y7 AND XOR XOR x<5 & y7 x<5 y>7 y7 B C B B x5 C x5 & y>7 C

Deferred choice Choice made by the environment not the system Essential in workflow context Not widely supported, though its importance seems to be increasingly recognised (e.g. BPEL) Naturally supported by notations that offer direct support for the notion of state, e.g. statecharts or Petri nets vs WCP 4 Exclusive Choice Choice made by the system, based on data

Deferred choice vs Exclusive choice: definitions context condition: only one instance of the construct can operate at any time in a case Exclusive choice context condition: choice construct has access to all required resources when making routing decision + FLOWer, COSA, BPEL, Oracle BPEL, BPMN, XPDL, UML 2.0 AD - EPC (implemented by ARIS toolset 6,2, SAP Workflow 4.6c, iPlanet 3.0, Staffware 10, WebSphere MQ 3.4

Deferred choice vs Exclusive choice + FLOWer, COSA, BPEL, Oracle BPEL, BPMN, XPDL, UML 2.0 AD - EPC (implemented by ARIS toolset 6,2, SAP Workflow 4.6c, iPlanet 3.0, Staffware 10, WebSphere MQ 3.4

Deferred Choice - UML Solution in UML 2.0 AD

Deferred choice - BPMN Solution in BPMN with Event-Based Exclusive Gateway and Message Events with Event-Based Exclusive Gateway and Receive Activities

Thread split At a given point in a process, a nominated number of execution threads can be initiated in a single branch of the same process instance. Definition CPN context condition: required number of threads known at design-time

Synchronisation patterns: AND-join variants Synchronisation, wait for all incoming threads context assumption: each incoming branch will signal exactly once Generalised AND-Join, wait for all incoming threads Structured partial join, wait for some (but not all) incoming threads context assumption: structured workflow Blocking partial join, wait for some (but not all) incoming threads context assumptions: workflow is safe, join blocks until remaining threads arrive Cancelling partial join, wait for some incoming threads, cancel the rest

Synchronisation patterns: the differences

Synchronisation vs Generalised AND-Join Definition CPN Context condition (Synchronisation) Once the synchroniser has been activated (and not reset), it is not possible for another signal to be received on the activated branch or for multiple signals to be received on any incoming branch.

Structured partial join Triggered by completion of n of the m parallel incoming branches (where n < m) Subsequent threads do not cause triggering Partial join resets when all branches have completed Context conditions Corresponding and-split All branches structured (e.g. balanced corresponding splits and joins) Either all branches can be cancelled or none Special case where n=1 is sometimes termed the discriminator

Structured partial join

Structured partial join: operation - UML 2.0 AD, SAP Workflow 4.6c, iPlanet 3.0, COSA 5.1, Staffware 10 + Webshpere MQ 3.4, FLOWer 3.51, FileNet 3.5, BPEL 1.1, Oracle BPEL 10.1.2, BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2)

Structured partial join: CPN definition - UML 2.0 AD, SAP Workflow 4.6c, iPlanet 3.0, COSA 5.1, Staffware 10 + Webshpere MQ 3.4, FLOWer 3.51, FileNet 3.5, BPEL 1.1, Oracle BPEL 10.1.2, BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2)

Structured partial join: Usage issue Structured workflow imposes serious usage restrictions blocking and cancelling pattern variants - UML 2.0 AD, SAP Workflow 4.6c, iPlanet 3.0, COSA 5.1, Staffware 10 + Webshpere MQ 3.4, FLOWer 3.51, FileNet 3.5, BPEL 1.1, Oracle BPEL 10.1.2, BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2)

Blocking partial join Removes the requirement that each incoming branch can only be enabled once between join resets. It allows each incoming branch to be triggered multiple times although the construct only resets when one triggering has been received on each input branch

Cancelling partial join Improves the efficiency of the pattern further by cancelling the other incoming branches to the join construct once n incoming branches have completed

Synchronisation patterns: OR-join variants Structured synchronising merge, wait for all enabled branches context assumptions: structured workflow, local semantics Local synchronising merge, wait for all enabled branches context assumption: local semantics General synchronising merge, wait for all enabled branches

Structured synchronising merge: operation Structured synchronising merge, wait for all enabled branches context assumptions: structured workflow, local semantics - UML 2.0 AD, SAP Workflow 4.6c, iPlanet 3.0, COSA 5.1, Staffware 10 + Webshpere MQ 3.4, FLOWer 3.51, FileNet 3.5, BPEL 1.1, Oracle BPEL 10.1.2, BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2)

Structured synchronising merge Convergence of two or more branches (which diverged earlier in the flow) into a single subsequent branch. The thread of control is passed to the subsequent branch when each active incoming branch has been enabled. Context conditions: Single earlier corresponding multi-choice While merge has not fired, this multi-choice cannot be re-enabled No cancellation of selective branches after firing multi-choice These conditions are such that firing decision can be made based on local knowledge

Structured synchronising merge

Structured synchronising merge: possible realisations I

Structured synchronising merge: possible realisations II

Local synchronising merge This pattern does not require the process model to be structured, but its usage in the context of loops is restricted A possible realisation is through so-called “dead-path elimination” (see MQSeries, BPEL – note the implication this has on the types of loops allowed) Evaluation of whether this merge is enabled can still be done locally

Local synchronising merge: CPN definition

Local synchronising merge: another solution Communication between OR-split and OR-join cf. Rittgen, 1990 active branches A OR split OR join Z

Local synchronising merge: operation WebSphere MQ, FLOWer, COSA, BPEL and EPCs provide support for this pattern. UML 2.0 ADs seems to provide support although there is some ambiguity over the actual JoinSpec configuration required context conditions: (1) all input places to the construct are (2) must be able to determine how many incoming branches to synchronise based on local knowledge

A (very) complex CF pattern: General synchronising merge Basically: Wait only if you have to Problems: How should you treat other OR-joins? How do you deal with cycles? How do you treat decomposed tasks? Is an analysis of the future possible? How complex will it be? (for a detailed discussion see [WEAH05] and work by Kindler et al)

Non-local semantics of General Synchronising Merge ("bus driver semantics") Not only in EPCs but also in many WFM systems: Domino Workflow, Eastman, MQ Series, etc.

General Synchronising Merge in CPN

General synchronising merge: operation FileNet 3.5 supports this pattern context conditions: none!

Synchronisation patterns: XOR and thread join XOR-join variants Simple merge,wait for one of the incoming branches context assumption: only one incoming branch active Multi-merge, wait for one of the incoming branches Thread join variants Thread merge, coalesce specified number of threads in branch into single thread

XOR-join variants: Simple & Multi-merge context condition: the merge construct will never receive another execution thread whilst it is merging a previously received thread onto the output branch context condition: the merge construct must be associated with a preceding multi-choice (OR-split)

BPMN BPMN Several solutions for the most basic patterns

Basic control-flow patterns in UML2.0 AD

Repetition patterns - 1 Structured loop, the ability to execute a task or sub-process repeatedly on the basis of a pre or post test where there is a single entry/exit point

Repetition patterns - 2 Describe various ways in which repetition of tasks or sub-processes may be specified. Arbitrary cycles, cycles in a process with more than one entry or exit point Recursion, repetition of a task through self-invocation

Arbitrary Cycles & Expressiveness Not all arbitrary cycles can be converted into structured ones (e.g. while or repeat loops; for further details see [KtHB00] and [Kie03]). Block structured offerings such as WebSphere MQ, FLOWer, SAP Workflow and BPEL are not able to represent arbitrary process structures.

Multiple instance patterns Delineate situations with multiple threads of execution in a workflow which relate to the same activity MI without Synchronisation, multiple concurrent instances but no synchronisation requirements MI with a priori Design Time Knowledge, number of concurrent instances known at design-time, all must finish MI with a priori Runtime Knowledge, number of concurrent instances known at runtime, all must finish MI without a priori Runtime Knowledge, number of concurrent instances only known at completion, all must finish Static Partial Join for MI, number of concurrent instances known at design-time, specified number must finish, remainder inconsequential Cancelling Partial Join for MI, number of concurrent instances known at design-time, specified number must finish, remainder cancelled Dynamic Partial Join for MI, number of concurrent instances only known at completion, dynamic completion condition

MI patterns: variation points

MI without synchronisation context condition: the number of task instances is fixed at design-time

MI without synchronisation in CPN

Multiple instances without synchronisation (source: [AHKB03], p. 24)

MI without Synchronization Solution in UML 2.0 AD Solution in BPMN

MI with a priori runtime knowledge context condition: the number of task instances is fixed at design-time

MI with a priori runtime knowledge in CPN

Multiple instances with a priori runtime knowledge (source: [AHKB03], p. 24)

Multiple instances with a priori runtime knowledge (source: [AHKB03], p. 24)

MI with a Priori Run-Time Knowledge Solution in UML 2.0 AD Solution in BPMN

MI without a Priori Run-Time Knowledge Creation of a number of concurrently executing instances of an activity, this number is not known before invocation of the MI activity. Synchronisation of all instances created is required. More advanced MI patterns address: Creation of new instances on-the-fly Threshold for completion (partial join) Cancellation of remaining threads in case of a partial join

MI without a Priori Run-Time Knowledge: Definition

MI without a Priori Run-Time Knowledge: Animation

Multiple instances without a priori runtime knowledge (source: [AHKB03], p. 28)

MI without a Priori Run-Time Knowledge Workaround in UML 2.0 AD NB! In practice this pattern is implemented by the user. Solution with object streams and weights The solutions require advanced data manipulation and special attribute settings. Solution with variables

MI without a Priori Run-Time Knowledge Workaround in BPMN NB! In practice, a modeller has to implement this pattern. The solution requires advanced data manipulation and special attribute settings.

Dynamic partial join for MI: operation

Dynamic partial join for MI context conditions: initial number of instances is set at design-time must be possible to evaluate completion condition

Concurrency patterns Reflect situations where restrictions are imposed on the extent of concurrent control-flow in a process instance Sequence, sequential task execution Interleaved routing, execution of a set of tasks can occur in any order but not concurrently Interleaved parallel routing, a set of tasks, which have a partial ordering amongst them, and execute in order order that satisfies this sequence but not concurrently Critical section, two or more regions in a process model that cannot be active simultaneously Milestone, the execution of a nominated task can only proceed when the process instance is in a specified state

Sequence Definition CPN: An activity in a workflow process is enabled after the completion of a preceding activity in the same process. Definition CPN:

Interleaved routing: operation Interleaved routing, execution of a set of tasks can occur in any order but not concurrently

Interleaved routing: definition context condition: tasks initiated and completed sequentially and cannot be suspended

Milestone In some cases a thread needs to check whether some other parallel thread has reached a certain point (but has not moved beyond it) As long as this is the case a certain task may execute Hard to realise when a language does not support the notion of state explicitly

Milestone (source: [AHKB03], p. 36)

Milestone (source: [AHKB03], p. 35)

Milestone The execution of a nominated task can only proceed when the process instance is in a specified state

Milestone in CPN

Trigger patterns Allow for synchronisation with the operating environment Persistent trigger, task initiation triggered by external signal. Triggers are durable and retained if not immediately used Transient trigger, task initiation triggered by external signal. Triggers are emphemeral and are lost if not immediately used

Cancellation and completion patterns Categorise the various cancellation scenarios that may be relevant for a workflow specification Cancel task, withdraw a specified task instance Cancel case, withdraw all task instances in a case Cancel region, withdraw task instances in a specified region of a process Cancel MI task, withdraw all instances of a specified MI task Complete MI task, withdraw all remaining instances of a specified MI task, completed instances are unaffected and the MI task is deemed to have sucessfully completed

Cancellation region Generalisation of Cancel activity and Cancel case Region associated with a task This region is emptied of tokens upon completion of that task. Rarely fully supported (only UML 2.0 ADs through InterruptibleActivityRegion construct and YAWL)

Cancel region pattern

Cancel region: operation

Termination patterns Address the issue of when the execution of a workflow is considered to be finished Implicit termination, finish the case when there is no more work to do Explicit termination, finish the case when the thread of control reaches a specified end node

UML activity diagram - 1 What are the termination semantics? ActivityFinalNode What are the termination semantics? → explicit termination

UML activity diagram - 2 FlowFinalNode What are the termination semantics? → implicit termination

UML activity diagram - 3 What are the termination semantics?

BPMN – termination semantics 1 → implicit termination End Event End Event

BPMN – termination semantics 2 → explicit termination Terminate End Event Terminate End Event

Control-flow perspective: evaluation 1 – BPMN 2 – UML AD 3 – BPEL

Epilogue - I Patterns Provide an effective foundation for training workflow designers and developers; Present a means of assessing and comparing tool capabilities and are particularly useful in tool evaluation and selection exercises (e.g. tender evaluations); Offer the basis for vendors to identify functionality gaps and potential areas for enhancement.

Epilogue - II Patterns range from simple to (very) complex Patterns typically observed Comprehensive support lacking Problems so complex that informal approaches fall short

Further details Key papers Online references www.workflowpatterns.com W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003. N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22, BPMcenter.org, 2006. Online references www.workflowpatterns.com www.BPMcenter.org

Instruction questions - 1 Sketch the Petri-net representations of the main control-flow connectors i.e. AND-split OR-split XOR-split AND-join OR-join XOR-join Each of these constructs can be represented by a number of distinct control-flow patterns. What are the correspondences between these constructs and the various control-flow patterns? What are the difficulties associated with the use of the OR-join construct?

Instruction questions - 2 Identify the control-flow patterns in the following process model

Instruction questions - 3 Model the following process as a YAWL process model A travel agency makes travel arrangements for people A travel arrangement may include one or more of the following activities: book flight, book car and book hotel These activities occur in parallel As they involve dealing with third parties, each of the booking activities may be either successful or unsuccessful When all booking activities requested by a customer have completed successfully, the payment activity is triggered If any of the booking activities are unsuccessful, any further progress on the booking activities (if any) is cancelled The process completes after either a payment or cancellation activity What difficulties arise when trying to model this as a Petri net?

Instruction questions - 4 Illustrate how the cancel case pattern could be applied to a process model

Instruction questions - 5 The illustration below shows the nominal form of the milestone pattern. The difficulty with this form is that if the thread of control has passed place X, then the milestone task will never be enabled. Modify the model so that the milestone task can still be enabled if the thread of control has already passed X.

Instruction questions - 6 Sketch the Petri-net representations for the following situations. Which pattern do each of them correspond to? After the sound alarm task, either the evacuate lab task or the handle false alarm task commences depending on whether the value of the heat sensor variable is above 30 degrees At the conclusion of the test oil pressure, the pilot decides to initiate the repressure task or ignore reading and reset task depending on the oil pressure returned When the calculate depth task completes, based on the value returned for the depth, if it is less than 5 metres, initiate the short fill task, it is is greater than 5 metres initiate the long fill task, if it is greater than 10 metres initiate the check valve task Run the g23 genome sequence task, then run the g24 genome sequence and/or the g25 genome sequence task Run the measure yeast content task, after this has completed if the time is before 12:00pm, run the fill main tank task otherwise run the fill task 2 task

Instruction questions - 7 Outline the possible approaches to implementing a 1-out-of-3 join. What are the advantages and disadvantages of each? The Ad-hoc activity construct in BPMN allows a set of nominated tasks to run in arbitrary order. Each task can execute an arbitrary number of times (including not at all). Draw the Petri-net to illustrate the behaviour of this construct where it contains four tasks A, B, C and D. How does this behaviour compare to the interleaved routing patterns?

Instruction questions - 8 The local synchronising merge relies on local semantics for its operation i.e., the OR-join must be able to determine when to fire based on the availability of locally available information Why might this approach to OR-join enablement be popular with tool vendors? How might you implement this form of OR-join? WebSphere MQ, FLOWer, COSA, BPEL and EPCs provide support for this pattern. UML 2.0 ADs seems to provide support although there is some ambiguity over the actual JoinSpec configuration required

References I www.workflowpatterns.com W.M.P. van der Aalst. Patterns and XPDL: A Critical Evaluation of the XML Process Definition Language. QUT Technical report, FIT-TR-2003-06, Queensland University of Technology, Brisbane, 2003. W.M.P. van der Aalst. Don't go with the flow: Web services composition standards exposed. Web Services - Been there done that?, Trends & Controversies. IEEE Intelligent Systems 18(1):72-76. Wil M.P. van der Aalst and Kees M. van Hee. Workflow Management: Models, Methods, and Systems. The MIT Press, 2002. W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003. W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Advanced Workflow Patterns. In O. Etzion and P. Scheuermann, editors, 7th International Conference on Cooperative Information Systems (CoopIS 2000), volume 1901 of Lecture Notes in Computer Science, pages 18-29. Springer-Verlag, Berlin, 2000. W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. Web Service Composition Languages: Old Wine in New Bottles? In G. Chroust and C. Hofer, editors, Proceedings of the 29th EUROMICRO Conference: New Waves in System Architecture, pages 298-305. IEEE Computer Society, Los Alamitos, CA, 2003. M. Dumas and A. ter Hofstede. UML Activity Diagrams as a Workflow Specification Language. In Proceedings of the International Conference on the Unified Modeling Language (UML), Toronto, Canada, October 2001. Springer Verlag.

References II Marlon Dumas, Wil M.P. van der Aalst, Arthur H.M. ter Hofstede (Editors), Process-Aware Information Systems: Bridging People and Software Through Process Technology, John Wiley & Sons, September 2005. B. Kiepuszewski, A.H.M. ter Hofstede, C. Bussler. On Structured Workflow Modelling. Proceedings CAiSE’2000, Lecture Notes in Computer Science 1789, Stockholm, Sweden, June 2000. B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003. B. Kiepuszewski, A.H.M. ter Hofstede and W.M.P. van der Aalst. Fundamentals of Control Flow in Workflows. Acta Informatica 39(3):143-209, 2003. P. Rittgen. From process model to electronic business process. In D. Avison, E. Christiaanse, C.U. Ciborra, K. Kautz, J. Pries-Heje, and J. Valor, editors, Proceedings of the European Conference on Information Systems (ECIS 1999), pages 616–625, Copenhagen, Denmark, 1999. http://www.adm.hb.se/~pri/ecis99.pdf. N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22 , BPMcenter.org, 2006. N. Russell, Wil M.P. van der Aalst , A.H.M. ter Hofstede , and Petia Wohed. On the Suitability of UML 2.0 Activity Diagrams for Business Process Modelling. In M. Stumptner, S. Hartmann, and Y. Kiyoki, editors, Proceedings of the Third Asia-Pacific Conference on Conceptual Modelling (APCCM2006), volume 53 of CRPIT, pages 95-104, Hobart, Australia, 2006. ACS.

References III P. Wohed, E. Perjons, M. Dumas, and A. ter Hofstede, Pattern-Based Analysis of EAI Languages: The Case of the Business Modeling Language. in Proc. of the 5th Int. Conf. on Enterprise Information Systems (ICEIS), Angers, France, April 2003. P. Wohed, W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede, Analysis of Web Services Composition Languages: The Case of BPEL4WS. in I.Y. Song, et al, eds, 22nd Int. Conf. on Conceptual Modeling (ER 2003), vol. 2813 of LNCS, pp. 200-215, Springer-Verlag, 2003. P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell, Pattern-based Analysis of the Control-Flow Perspective of UML Activity Diagrams. in L. Delcambre et al., eds, Proc. of the 24th Int. Conf. on Conceptual Modeling (ER 2005), vol. 3716 of LNCS, pp. 63-78. Springer-Verlag, Berlin, 2005. P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell, On the Suitability of BPMN for Business Process Modelling. in Proc. of the 4th Int. Conf. on Business Process Management, Vienna, September 2006. P. Wohed, W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and N. Russell. Pattern-based Analysis of BPMN - An extensive evaluation of the Control-flow, the Data and the Resource Perspectives (revised version) . BPM Center Report BPM-06-17 , BPMcenter.org, 2006. M. Wynn, D. Edmond, W.M.P. van der Aalst, A.H.M. ter Hofstede. Achieving a General, Formal and Decidable Approach to the OR-join in Workflow using Reset nets. Proceedings of ATPN’2005. Miami, Florida, 2005.

Disclaimer No legal liability or responsibility is assumed for the accuracy and completeness of any product-specific information.