The Language: Rationale and Fundamentals (Part I)

The Language: Rationale and Fundamentals (Part I)
Nick Russell Arthur ter Hofstede 1

Overview Fundamental theory Introduction to BPM Patterns
Control-flow Control-flow specification in YAWL Pattern (cont’d) Data (incl how realised in YAWL) Resources (incl how realised in YAWL) Syntax of YAWL (ORM and set theory) Example: Order fulfillment 2

Part I: Fundamentals Overview: Petri nets
Mapping workflow concepts to Petri nets Some fundamental results Workflow nets Reset nets Coloured Petri Nets 3

Petri Nets Originate from C.A. Petri’s PhD thesis (1962)
Technique for the description and analysis of concurrent systems Graphical notation Formal Based on a few simple concepts, yet expressive Many analysis techniques exist Many extensions and variants have been defined over the years 4

Applications Applications in many different areas, such as databases, software engineering, formal semantics, etc etc There are two main uses of Petri nets for workflows: Specifications of workflows Formal foundation for workflows (semantics, analysis of properties) 5

Petri Nets: Definition
Petri Nets consist of places and transitions Places can be input/output of transitions Places represent states, transitions represent state changes Places are represented by circles, transitions by thick bars Formally a Petri net N is a triple (P, T, F) where P is a finite set of places T is a finite set of transitions F  (P x T  T x P) is the flow relation p  = {t  T | (p, t)  F},  p = {t  T | (t, p)  F}, etc 6

Petri nets: graphical symbols
place transition arc 7

Petri Net: Example t1 p1 p3 t2 p4 p2 t3 P = {p1, p2, p3, p4}
T = {t1, t2, t3} F = {(p1, t1), (p2, t1), (t1, p3), (p2, t2), (t2, p4), (p4, t3), (t3,p2)} t1  = {p3};  t1 = {p1, p2};  p2 = {t3};  p1 = ; p2  = {t1, t2} 8

Petri Nets: Example p1 p2 t1 t2 t3 p3 P = ... T = … F = ...
9

Markings Markings assign tokens (graphically represented as black dots) to places; they represent a state of the system. Formally, a marking M of a Petri net N = (P,T,F) is a function M: P -> NAT. The marking below is formally captured by {(p1,1),(p2,2),(p3,0)}. We will also denote this as p1+2p2. Within Petri net N = (P,T,F) and markings M and M′, M ≥ M′ iff for all p in P: M(p) ≥ M′(p). M > M′ iff M ≥ M′ and M ≠ M′. p1 p2 p3 10

Enabled Transitions Transitions may change a marking by firing.
Only enabled transitions may fire. Informally, a transition is enabled if each of its input places contains at least one token. Formally, a transition t is enabled in a marking M iff for each p, with p •t, M(p) > 0. (see definition 2.7 of [DE95]) 11

Firing Transitions In a marking, any enabled transition may fire, in which case a token is removed from each of its input places and a token is produced for each of its output places. Formally, the marking M′ resulting from firing enabled transition t in marking M, notation M t M′, is defined by: M′(p) = M(p) if p  •t  t• or p  •t  t• M′(p) = M(p) - 1 if p  •t and p  t• M′(p) = M(p) + 1 if p  t• and p  •t (see e.g. [DE95] definition 2.7) We write M  M′ iff M t M′ for some transition t. We write M  M′ iff M = M0 t0 M1 t1 M2 … Mn-1 tn-1 Mn = M′ and  = t0 t1… tn-1. Note that the transitions do not have to be different! If  does not matter we write M * M′. 12

Firing a Transition: Example
AFTER BEFORE 13

Firing Transitions: Further Examples
14

Petri nets: Concrete Example (source [DE95] p. 4)
ready for insertion candy storage insert coin refill dispense candy reject coin holding coin accept coin request for refill ready to dispense 15

Petri nets: Order Fulfillment Example
16

Petri net example: Elevator 1
Animation by Wil van der Aalst, Vincent Almering and Herman Wijbenga 17

Modelling Exercises Two traffic lights at an intersection. If one is red, the other should be green etc. (many discussions on modelling traffic lights through Petri nets can be found on the internet) A producer and a consumer producing and consuming (resp.) indefinitely. The consumer cannot consume more than the producer has produced thus far. How does your model change if the buffer between them is of limited size? (this is a well-known concurrency problem) Two parallel processes with two critical sections. If one of the two processes is in its critical section, the other process should not be able to enter its critical section and vice versa. (this is also a well-known concurrency problem) 20

Solution Traffic Lights

Reachable and Coverable Markings
For a Petri net an initial marking M0 needs to be specified. A marking M is reachable iff it results from firing a number of transitions in the initial marking, i.e., M0 * M (see e.g. Definition 2.8 in [DE95]). We will denote the fact that a marking M′ is reachable from a marking M as M * M′. A marking M is coverable iff a reachable marking M′ exists such that M′ ≥ M (see e.g. Definition 5 in [HAAR09]). Example: Given the Petri net and marking of the slide “Markings”, p1+p2+p3 is a reachable marking, while p1+p3 is a coverable marking (but not reachable). To decide whether a given marking M is reachable is a DSPACE(exp)-hard problem. Only in the early eighties was an algorithm found, settling the question whether the problem was decidable at all. 22

Properties A Petri net N with initial marking M0 is live iff for every reachable marking M and every transition t there exists a marking M’ reachable from M which enables t. (see definition of [DE95]) A Petri net N with initial marking M0 is deadlock free iff every reachable marking enables some transition (see definition 2.16 of [DE95]). In a workflow context this definition is usually adapted a bit (see later), as one would not like to consider the empty marking to be a deadlock. A Petri net N with initial marking M0 is k-bounded iff for every reachable marking M, M(p)  k (k is the minimal number for which this holds). (see definition 2.20 of [DE95]). A 1-bounded net is called safe. A net is bounded if a natural number k can be found such that the net is k-bounded. A Petri net N is strongly connected iff for every pair of nodes x and y there is a path from x to y and vice versa. 23

Exercise Is the vending machine live? Is it deadlock free?
Is it bounded? Can a marking be reached with tokens both in “ready for insertion” and “ready to dispense”? Give an example of a marking that is coverable but not reachable. 24

Free Choice Petri nets Many verification problems in Petri nets have a high complexity. Free Choice Petri nets are a subclass of Petri nets with a “nice” tradeoff between expressiveness and analyzability (see e.g. [DE95]). All elementary workflow concepts are essentially free choice. In a Free Choice Petri net “the result of the choice between two transitions can never be influenced by the rest of the system” [DE95] 25

Example of a Conflict 26

Free Choice Petri nets: Definition (see [DE95] p63-64)
In a Free Choice Petri net, every pair of transitions either share all their input places, or they share none. Formally, a Petri net N = (P,T,F) is free choice iff for all transitions t,t’: •t  •t’    •t = •t’ 27

Application of Petri nets: Analysis of elementary workflow concepts
Now that we understand the basics of Petri nets we can use them in order to understand the semantics of elementary modeling concepts. This will increase our understanding of control-flow concepts in workflows, both in terms of the semantics of the concepts and some fundamental expressiveness results. This work is all based on [KHA03]: B. Kiepuszewski, A.H.M. ter Hofstede and W.M.P. van der Aalst. Fundamentals of Control Flow in Workflows. Acta Informatica 39(3): , 2003. 28

Elementary Workflow Concepts
When it comes to control flow, almost all Workflow Management Systems (WFMSs) support elementary concepts such as sequence, and-split, or-split, and-join, and or-join. The Workflow Management Coalition (WfMC) has given definitions of these notions (see sources and references). However, due to the informal nature of these definitions, different interpretations are possible. In fact the extent to which various commercial workflow management systems have taken different interpretations of these basic control flow concepts is striking. We will examine the definitions of the WfMC and provide formal interpretations of some interpretations in terms of Petri nets. 29

Evaluation Strategies
Fundamentally different interpretations of the basic control flow concepts can be chosen. Corresponding evaluation strategies that can be observed in commercial WFMSs are: Standard (e.g. Forte Conductor, Verve Workflow) Safe (e.g. Staffware, I-Flow, HP Changengine) Synchronizing (e.g. MQ/Series Workflow, Inconcert) 30

Evaluation Strategies
Standard: true token propagation. Receipt of such a token implies that the corresponding activity needs to be executed. Safe: almost the same as standard, except new instances of an already executing activity will not be created Synchronizing: true/false token propagation. When a true token is received the corresponding activity is executed, while if a false token is received it is skipped. Tokens needs to be received from all incoming branches before tokens can be passed on. 31

Activities According to the WfMC [WfMC], an activity is “A description of a piece of work that forms a logical step within a process. An activity may be a manual activity, which does not support computer automation, or a workflow (automated) activity. A workflow activity requires human and/or machine resources(s) to support process execution; where human resource is required an activity is allocated to a workflow participant.” 32

Activity: Formal Semantics (source: [KHA03], p. 149 & 156)
Standard/Safe Synchronizing 33

Sequence (source: [KHA03], p. 149)
An activity has to await successful completion of another activity. The translation below is for standard/safe workflows, but can easily be adapted for synchronising workflows. 34

Initial/Final Activities (source: [KHA03], p. 149)
Initial activities have no incoming branches, while final activities have no outgoing branches. Below are the translations for standard/safe workflows; again, they can easily be adapted for synchronizing workflows. initial final 35

xor-split According to the WfMC [WfMC], an or-split is “A point within the workflow where a single thread of control makes a decision upon which branch to take when encountered with multiple alternative workflow branches.” Note that the exclusive nature of the choice, i.e. only one of the outgoing branches can be chosen, means that this concept is sometimes referred to as an xor-split 36

xor-split: Standard/Safe Workflows (source: [KHA03], p. 149)
37

xor-split: Synchronizing Workflows (source: [KHA03], p. 157)
38

and-split According to the WfMC [WfMC], an and-split is “A point within the workflow where a single thread of control splits into two or more threads which are executed in parallel within the workflow, allowing multiple activities to be executed simultaneously (see Parallel Routing).” The WfMC [WfMC] additionally states that “In certain workflow systems all the threads created at an And-Split must converge at a common And-Join point (Block Structure); in other systems convergence of a subset of the threads can occur at different And-Join points, potentially including other incoming threads created from other And-Split points (Free Graph Structure).” 39

and-split: Standard/Safe Workflows (source: [KHA03], p. 149)
40

and-split: Synchronizing Workflows (source: [KHA03], p. 149 & 157)
41

and-join According to the WfMC [WfMC], an and-join is “A point in the workflow where two or more parallel executing activities converge into a single common thread of control.” Question: What should happen when one or more of the incoming branches do not terminate? 42

and-join: Standard/Safe Workflows (source: [KHA03], p. 150)
43

and-join: Synchronizing Workflows (source: [KHA03], p. 158)
44

xor-join According to the WfMC [WfMC], an or-join is
“A point within the workflow where two or more alternative activity(s) workflow branches re-converge to a single common activity as the next step within the workflow. (As no parallel activity execution has occurred at the join point, no synchronisation is required.)” Last sentence in brackets: WfMC assumes workflows to be safe (though up to the designer to ensure that). We will prefer to refer to this type of or-join as an xor-join and reserve the term or-join for another synchronization construct. 45

xor-join: Standard/Safe Workflows (source: [KHA03], p. 150)
46

xor-join: Synchronizing Workflows (source: [KHA03], p. 158)
47

Exercise (source: [KHA03], p. 153)
Map the following Standard Workflow to a Petri net C A XOR AND AND XOR B D 48

A new class: structured workflows
We will study a fourth (abstract) class of workflows, the structured workflows. This class was investigated in [KHN00] and Bartek Kiepuszewski’s PhD thesis. We will present some fundamental results for this class. First we briefly look at the notion of equivalence in the context of process modelling. Then we define what a structured process model is. Thereafter we look at the relationship between unstructured and structured process models, specifically the question whether all unstructured process models can be converted to structured ones? We then conclude with considering the significance of the deferred choice. 49

Equivalence Considerations: Moment of Choice
XOR A B C XOR A B C versus In process algebra terms: a(b+c) ≠ ab + ac (see e.g. [BW90]) 50

Equivalence Considerations: Parallelism
XOR AND A B versus A B B A Did we loose something here? 51

What is a Structured Process Model?
Sequence Split/Join - C  {AND,XOR,OR} S1 S2 S1 Sn C Loop XOR S1 S2 52

Mapping Unstructured Process Models to Structured Process Models
Question: Why is this not the same as removing goto-statements in normal programming? Answer: due to the occurrence of parallelism and the required notion of equivalence (roughly: bisimulation) 53

Unstructured to Structured
Theorem 4.1 [KHB00] There are arbitrary well-behaved workflow models that cannot be modelled as structured workflow models B AND D A AND AND F C AND E 54

Unstructured to Structured
Theorem 4.2 [KHB00] Arbitrary loops add expressive power 55

Explicit Choice vs Deferred Choice
Is the choice by the system (based on available data) or by the environment (e.g. user, timer, message)? Moment of choice is fundamentally different. Observable behaviour is different (work lists!) Often overlooked in the past, modern approaches tend to recognise this difference though. We will look at these concepts again in the context of the workflow control-flow patterns. 56

Explicit Choice vs Deferred Choice (source: [KHA03], p. 149)
57

Workflow nets: Motivation and Definition
Wil van der Aalst has proposed the use of Petri nets for workflow modelling. In [Aalst96] three benefits are argued: Petri nets are formally defined; Petri nets support the notion of being “in between” performing tasks through the notion of place; Petri nets have associated analysis techniques. He proposes a particular subclass of Petri nets, called Workflow nets (WF-nets) for this purpose. Definition [AH02, p ] A Petri net PN = (P, T, F) is a WF-net (Workflow net) if and only if: There is one source place i  P such that •i =  There is one sink place o  P such that o• =  Every node x  P  T is on a path from i to o. 58

Workflow Net Constructs
59

Workflow Net Example 60

Workflow nets: Soundness
In [AH02] a number of so-called soundness criteria are formulated. The following definitions are adapted from Definition 12, p. 275: [Option to Complete] Given an initial marking i, from every marking M reachable from i, i * M, a marking M’ can be reached that covers o, i.e. M * M’ and M ≥ o. In practical terms this means that the net is free of deadlock and infinite loops. [Proper Completion] Any marking M reachable from i, M * i, that marks output place o, M ≥ o, marks no other place and only has one token in o, i.e. M = o. When the workflow terminates no other tasks are still running and termination is signalled only once. [No Dead Tasks] For every transition t a marking M reachable from i, i * M can be found that enables t. The workflow does not contain any superfluous parts that can never be activated. Exercise: Create seven WF-nets each violating a different combination of soundness conditions of WF-nets. 61

Workflow nets: How to decide soundness? (see [AH02] p276)
In [Aalst97] it was shown that soundness for a WF-net could be determined in terms of liveness and boundedness. In [AH02] p.276 this is explained as determining that a workflow net PN is sound is equivalent to determining to whether the net PN’ which is constructed through the addition of an extra transition t, where •t = {o} and t• = {i}, is live and bounded. As pointed out in [AH02] p.277, the computational complexity of determining whether a WF-net is sound may be quite high. Restrictions (e.g. requiring the net to be free choice) can be imposed to make this more tractable, see the discussion in [AH02] p At Eindhoven University of Technology the Workflow Analyzer (WOFLAN) was developed which is freely available for download. 62

Workflow Animation – Erroneous WF

Workflow Animation – Another Erroneous WF

Workflow Animation – Correct WF

Reset nets Reset nets extend Petri nets with a special type of arc, the reset arc. This directed arc connects a place to a transition. Multiple arcs may point at the same transition. When a transition fires all tokens (if any) are removed from these so-called reset places. Reset nets provide a natural semantics for YAWL as they can capture the notion of cancellation. Techniques from reset nets can be exploited for the purposes of analysing YAWL nets. They are also used in the formal definition of the OR-join. The reset arc extension comes at a price though: reachability is no longer decidable. Luckily coverability still is. Formal definitions are based on [DFS98, FRSB02, FS01].

Reset nets: formal definition
Syntactically a Reset net is a tuple (P, T, F, R) where (P, T, F) is a Petri net; R: T  2P is a function associating reset places with transitions. Let N = (P, T, F, R) be a Reset net and M a marking. A transition t  T is enabled iff •t ≤ M. An enabled transition t can fire thus changing the state to M’, denoted M t M’, with M’ = (M − •t)[P\R(t)] +t•. The definition of occurrence sequence extends naturally from Petri nets.

Reset nets place transition arc reset arc 68

Reset nets 69

Reset nets 70

Coloured Petri nets Higher level Petri nets extend Petri nets with:
Types for places Arc annotations Transition conditions Hierarchy Time They are Turing-complete. A notable example of High-level Petri nets is Coloured Petri nets (CPN) [JK09]. This notation has extensive tool support. The functional language ML is used for capturing types and transition conditions. CPN will be used to further explain the various control- flow patterns in order to reduce potential ambiguity. 71

Coloured Petri nets: simple example
INT x INT <5,6> <2,2> <x,y> <y,x,z+3> x+y>z <7,”hi”> <z,s> INT x INT x INT <concat(s,s)> INT x STRING STRING Is the transition enabled? If so, what is the result of firing it?

Sources and References
[Aalst96] Wil M. P. van der Aalst. Three Good Reasons for Using a Petri-net-based Workflow Management System. In S. Navathe and T. Wakayama, editors, Proceedings of the International Working Conference on Information and Process Integration in Enterprises (IPIC’96), pages , Cambridge, Massachusetts, November 1996. [Aalst97] Wil M.P. van der Aalst. Verification of Workflow Nets. In P. Azéma and G. Balbo, editors, Applications and Theory of Petri Nets 1997, volume 1248 of Lecture Notes in Computer Science, pp , Springer Verlag, 1997. [AH02] Wil M.P. van der Aalst and Kees M. van Hee. Workflow Management: Models, Methods, and Systems. The MIT Press, 2002. [JB96] S. Jablonski and C. Bussler. Workflow Management: Modeling Concepts, Architecture and Implementation. International Thomson Computer Press, 1996. [BW90] J. Baeten and W.P. Weijland. Process Algebra. Cambridge Tracts in Theoretical Computer Science 18, Cambridge University Press, [DE95] J. Desel and J. Esparza. Free Choice Petri Nets. Cambridge Tracts in Theoretical Computer Science 40, Cambridge University Press, [DFS98] C. Dufourd, A. Finkel, and P. Schnoebelen. Reset nets between decidability and undecidability. In K. Larsen, S. Skyum, and G. Winskel, editors, Proceedings of the 25th International Colloquium on Automata, Languages and Programming (ICALP’98), volume of Lecture Notes in Computer Science, pages 103–115, Aalborg, Denmark, July Springer. [FRSB02] A. Finkel, J.-F. Raskin, M. Samuelides, and L. van Begin. Monotonic extensions of petri nets: Forward and backward search revisited. Electronic Notes in Theoretical Computer Science, 68(6):1–22, 2002. [FS01] A. Finkel and Ph. Schnoebelen. Well-structured transition systems everywhere! Theoretical Computer Science, 256(1– 2):63–92, April 2001. [JK09] K. Jensen and L.M. Kristensen. Coloured Petri Nets: Modelling and Validation of Concurrent Systems, Springer 2009. [Peterson81] J.L.A. Peterson. Petri net theory and the modeling of systems. Prentice Hall, 1981. [HAAR09] A.H.M. ter Hofstede, W.M.P. van der Aalst, M. Adams, and N. Russell (editors). Modern Business Process Automation: YAWL and Its Support Environment. Springer, 2010. [WfMC] Workflow Management Coalition - Terminology & Glossary, Document number WFMC-TC-1011, Document Status 3.0, February Downloaded from (this document contains the quoted definitions) [KHA03] B. Kiepuszewski, A.H.M. ter Hofstede and W.M.P. van der Aalst. Fundamentals of Control Flow in Workflows. Acta Informatica 39(3): , 2003. [KHB00] 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. [Kie03] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003. (among others for the animations) 73

End of Part I 74

Chapter 2 The Language: Rationale and Fundamentals (Part II)

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

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. 77

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 78

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 79

     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      80

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

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 82

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 83

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 84

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

A B C D 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 86

BPMN: handling of concurrent execution threads
87

Staffware: handling of concurrent execution threads
88

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: 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 89

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 Exception P:s Exception handling in a process CAiSE’2006 N. Russell W. van der Aalst A. ter Hofstede Jun 2006 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 time These perspectives follow S. Jablonski and C. Bussler’s classification from: Workflow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, 1996 90

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 91

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

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, BPMN) Main patterns papers are all highly cited Education (used in teaching at 10+ Universities) Web site: 300+ visits on an average working day 93

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 94

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

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.) 96

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

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 98

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 99

Control-flow patterns overview
100

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. 101

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. 102

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. 103

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

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 105

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. 106

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 107

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 108

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 109

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 110

Deferred Choice - UML Solution in UML 2.0 AD 111

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

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 113

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 114

Synchronisation patterns: the differences
115

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. 116

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 117

Structured partial join
118

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 , BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2) 119

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 , BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2) 120

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 , BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2) 121

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 122

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 123

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 124

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 , BPMN 1.0, XPDL 2.0, EPC (as implemented in Aris toolset 6.2) 125

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 126

Structured synchronising merge
127

Structured synchronising merge: possible realisations I
128

Structured synchronising merge: possible realisations II
129

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 130

Local synchronising merge: CPN definition
131

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

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 133

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) 134

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. 135

General Synchronising Merge in CPN
136

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

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 138

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) 139

BPMN BPMN Several solutions for the most basic patterns 140

Basic control-flow patterns in UML2.0 AD
141

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 142

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 143

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. 144

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 145

MI patterns: variation points
146

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

MI without synchronisation in CPN
148

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

MI without Synchronization
Solution in UML 2.0 AD Solution in BPMN 150

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

MI with a priori runtime knowledge in CPN
152

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

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

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

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 156

MI without a Priori Run-Time Knowledge: Definition
157

MI without a Priori Run-Time Knowledge: Animation
158

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

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 160

Workaround in BPMN NB! In practice, a modeller has to implement this pattern. The solution requires advanced data manipulation and special attribute settings. 161

Dynamic partial join for MI: operation
162

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

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 164

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

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

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

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 168

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

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

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

Milestone in CPN 172

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 173

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 174

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) 175

Cancel region pattern 176

Cancel region: operation
177

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 178

UML activity diagram - 1 ActivityFinalNo de
What are the termination semantics? → explicit termination 179

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

UML activity diagram - 3 What are the termination semantics? 181

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

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

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

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. 185

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

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 187

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? 188

Identify the control-flow patterns in the following process model 189

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? 190

Illustrate how the cancel case pattern could be applied to a process model 191

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. 192

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 193

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? 194

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 195

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 , Queensland University of Technology, Brisbane, 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 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 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 Springer Verlag. 196

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): , 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, 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 , 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 , Hobart, Australia, ACS. 197

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 of LNCS, pp , 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 of LNCS, pp 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 , 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. 198

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

Chapter 2 The Language: Rationale and Fundamentals (Part III)

Control-flow Control-flow specification in YAWL Pattern (cont’d) Data (incl how realised in YAWL) Resources (incl how realised in YAWL) Syntax of YAWL (ORM and set theory) Example: Order fulfillment 201

Part III: Intro to YAWL What is YAWL? Rationale Control-flow concepts
Initial brief overview of data perspective 202

YAWL Overview Main publication Collaboration between TU/e and QUT
Based on Workflow Patterns Initiative YAWL: 2002 – newYAWL: 2007 System development Open source (currently LGPL) Governed by YAWL Foundation Industry collaboration first:utility Intercontinental Hotels Group (- 2007) GECKO Knexus Research Corporation / US Naval Research Laboratory Main publication W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language, Information Systems 30(4): , 2005 Citations: 600+ (Google Scholar); 170+ (Scopus); 140+ (Web of Science) URLs: (research) (system)

YAWL Highlights Based on the (old) control-flow and the resource patterns Extends workflow nets Formalisation Sophisticated verification support Transition invariants Reset net analysis Sophisticated flexibility support Exception handling Dynamic workflow Declarative workflow

YAWL vs Petri/workflow nets
Petri nets have difficulties capturing: The General Synchronising Merge Patterns involving Multiple Instances Cancellation of a certain part of a process For the Control Flow Perspective, YAWL takes some concepts from Petri/Workflow nets and adds constructs for: OR-join to deal with General Synchronising Merge Multiple Instance (MI) tasks Cancellation regions “Syntactic Sugar” (various splits/joins, direct connections between tasks)

YAWL notation Composite task Multiple Instance task

Multiple Instances Example I (source: [AH05])

Multiple Instances Example II (source: [AH05])

Multiple Instances Example III (source: [AH05])

General YAWL Example I (source: [AH05])

General YAWL Example II (source: [AH05])

General YAWL Example III

Cancellation in YAWL The concept of cancellation region generalises the cancel activity and cancel case patterns Syntactically, a cancellation region consists of a number of tasks and places (possibly including implicit ones!) part of the same composite task and attached to a so-called cancellation task (also part of the same composite task). Semantically, upon completion of the cancellation task all tokens in the cancellation region (or in decompositions of tasks in that region etc) are removed.

General YAWL Example IV

General YAWL Example VI (source: [AH05], p. 257)

General YAWL Example VII (source: [AH05], p. 257)

General YAWL Example VIII (source: [AH05], p. 257)

YAWL Example with Time (source: [AH05])
T represents a time-out task What are the disadvantages of using an external service for deadline notification?

New approach to time Tasks can have an associated timer
Timer can be based on variable, hence dynamic Timing can be On enablement On start

Exercise Consider a credit card application process. The process starts when an applicant submits an application (with the proposed amount). Upon receiving an application, a credit clerk checks whether it is complete. If not, the clerk requests additional information and waits until this information is received before proceeding. For a complete application, the clerk performs further checks to validate the applicant’s income and credit history. Different checks are performed depending on whether the requested loan is large (e.g. greater than $500) or small. The validated application is then passed on to a manager to decide whether to accept or reject the application. In the case of acceptance, the applicant is notified of the decision and a credit card is produced and delivered to the applicant. For a rejected application, the applicant is notified of the decision and the process ends. Model this process in YAWL. (credit: Moe Wynn and Chun Ouyang)

A Brief Overview of the Data Perspective in YAWL
The data patterns (discussed subsequently) were finalized after the initial data perspective for YAWL was developed Hence the data perspective in YAWL is not based on a comprehensive analysis of the data perspective The data perspective in YAWL relies on XML technology, in particular XML Schema, XPath and XQuery Specifying expressions in a correct manner can be non- trivial. Errors in XPath/XQuery expressions are a frequent source of errors In order for data to be accessible for a task the data item needs to be passed down the hierarchy When discussing the data patterns, the data perspective in YAWL will be explained in more detail

Native Use of XML The data inside of YAWL exists as many XML documents

Native Use of XML #2 The functionality of the YAWL business processing engine uses XML standards internally to perform the actions that one would expect of a Business Process System: Data Validation: XML Schema Transformations: XQuery Decision making: XPath

Native Use of XML #3: Strong Data Typing

Native Use of XML #4: Transformations in Data Passing

Native use of XML #5: System Decisions

Native Use of XML #6: Generation of XForms

Sources and References
[Aalst96] Wil M. P. van der Aalst. Three Good Reasons for Using a Petri-net-based Workflow Management System. In S. Navathe and T. Wakayama, editors, Proceedings of the International Working Conference on Information and Process Integration in Enterprises (IPIC’96), pages , Cambridge, Massachusetts, November 1996. [Aalst97] Wil M.P. van der Aalst. Verification of Workflow Nets. In P. Azéma and G. Balbo, editors, Applications and Theory of Petri Nets 1997, volume 1248 of Lecture Notes in Computer Science, pp , Springer Verlag, 1997. [AH02] Wil M.P. van der Aalst and Kees M. van Hee. Workflow Management: Models, Methods, and Systems. The MIT Press, 2002. [AH05] Wil M.P. and der Aalst and Arthur H.M. ter Hofstede. YAWL: Yet Another Workflow Language. Information Systems 30(4): , 2005. [JB96] S. Jablonski and C. Bussler. Workflow Management: Modeling Concepts, Architecture and Implementation. International Thomson Computer Press, 1996. [BW90] J. Baeten and W.P. Weijland. Process Algebra. Cambridge Tracts in Theoretical Computer Science 18, Cambridge University Press, 1990. [Peterson81] J.L.A. Peterson. Petri net theory and the modeling of systems. Prentice Hall, 1981. [DE95] J. Desel and J. Esparza. Free Choice Petri Nets. Cambridge Tracts in Theoretical Computer Science 40, Cambridge University Press, 1995. [HAAR09] A.H.M. ter Hofstede, W.M.P. van der Aalst, M. Adams, and N. Russell (editors). Modern Business Process Automation: YAWL and Its Support Environment. Springer, 2010. [WfMC] Workflow Management Coalition - Terminology & Glossary, Document number WFMC-TC-1011, Document Status 3.0, February Downloaded from (this document contains the quoted definitions) [KHA03] B. Kiepuszewski, A.H.M. ter Hofstede and W.M.P. van der Aalst. Fundamentals of Control Flow in Workflows. Acta Informatica 39(3): , 2003. [KHB00] 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. [Kie03] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003. (among others for the animations) 228

Chapter 2 The Language: Rationale and Fundamentals (Part IV)

Outline Part I Part II Part III Part IV Petri nets Workflow nets
Reset nets Part II Background – WfMS and PAIS Conceptual Foundations the Workflow Patterns Initiative Control-flow patterns Part III Control-flow in YAWL Part IV Data patterns Resource patterns 230

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 Exception P:s Exception handling in a process CAiSE’2006 N. Russell W. van der Aalst A. ter Hofstede Jun 2006 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 time These perspectives follow S. Jablonski and C. Bussler’s classification from: Workflow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, 1996 231

The Workflow Data Patterns
Workflow Patterns Framework The Workflow Data Patterns 232

Data Pattern Categories
Data Visibility: The extent and manner in which data elements can be viewed and utilised by workflow components. Internal Data Interaction: Data communication between active elements within a workflow. External Data Interaction: Data communication between active elements within a workflow and the external operating environment. Data Transfer: Data element transfer across the interface of a workflow component. Data Routing: The manner in which data elements can influence the operation of the workflow. 233

Data Visibility Patterns
The extent and manner in which data elements can be viewed by workflow components Task data Block data Scope data Multiple instance data Case data Folder data Workflow data Environment data 234

Data Visibility Scopes
Block Task Scope Case 235

Task Data Data visibility restricted to single task instance Staffware
+ WebSphere +/- FLOWer COSA YAWL BPMN BPEL UML 2.0 ADs 236

Block Data Data visibility restricted to tasks in single block or workflow net in a process instance Staffware + WebSphere FLOWer +/- COSA YAWL BPMN BPEL - UML 2.0 ADs 237

Scope Data Data visibility restricted to set of tasks in single process instance Staffware - WebSphere FLOWer +/- COSA YAWL BPMN BPEL + UML 2.0 ADs 238

Multiple Instance Data
Designated multiple instance task Shared implementation of decomposed tasks Multiply triggered task 239

Multiple Instance Data
Solutions UML 2.0 AD Supported + ExpansionKind + Loop + Shared decomp. BPMN Partially supported - MI + Loop + Shared decomp. 240

Case Data Data visibility restricted to all tasks in
single process instance Staffware +/- WebSphere + FLOWer COSA YAWL - BPMN BPEL UML 2.0 ADs 241

Folder Data A B C A B C A B C case-1 use(folder-A) Case data
repository A use(X) B use(X) C use(X) folder-A def var X case-2 use(folder-A) A use(X) B use(X) C use(X) folder-B def var Y case-3 use(folder-A, folder-B) A use(X,Y) B use(X,Y) C use(X,Y) 242

Task and Block Data in YAWL
task data task data block data 243

Data Interaction Patterns: Internal
Data communication between active elements within a workflow Data interaction between tasks Block task to sub-workflow decomposition Sub-workflow decomposition to block task To multiple instance task From multiple instance task Case to case 244

A B C Data Interaction between Tasks
Integrated Control and Data Channels A use(X,Y) B use(X) C use(Y) pass(X,Y) pass(Y) Single integrated control-flow and data channel Synchronous passing of control-flow and data between preceding and subsequent task(s) Data passing approach used by YAWL and BPEL 245

Data Interaction between Tasks Approach 1: Integrated Conrol and Data Channels
246

A B C Data Interaction between Tasks
Distinct Control and Data Channels A use(X,Y) B use(X) C use(Y) pass(X) pass(Y) Different control-flow and data channel Timing considerations in order to ensure both control-flow and data arrive at tasks at the required time Used by WebSphere where data passing is based on the notion of containers sent between tasks 247

Data Interaction between Tasks Approach 2: Distinct Control-Flow and Data Channels
248

A B C Data Interaction between Tasks No Explicit Data Passing use(X,Y)
Global Shared Data def var X def var Y A use(X,Y) B use(X) C use(Y) No explicit data passing Data elements held in global data store and used by tasks when required Data passing approach used by Staffware, FLOWer, COSA, BPMN, etc. 249

Data Interaction between Tasks Approach 3: Global Data Store
250

Task-to-Task Data Interaction in YAWL
via net variables 251

Data Interaction: Task to/from Subworkflow Approach 1: Implicit Data Passing
Data in the block task is accessible to all sub-tasks which make up the underlying implementation. i.e. the main block task and the corresponding subworkflow share the same address space No explicit data passing is necessary. Data passing approach used by FLOWer, COSA, BPMN 252

Data Interaction: Task to/from Subworkflow Approach 2: Explicit Data Passing using Parameters
Data elements in the block task must be specifically passed as parameters to the underlying subworkflow Mapping strategy required between block and subworkflow data elements Data passing approach used by YAWL, WebSphere MQ, BPMN, UML 2.0 ADs 253

Data Interaction: Task to/from Subworkflow Approach 3: Explicit Data Passing using Data Channels
Data elements in the block task are specifically passed via data channels to all tasks in the subworkflow that require access to them Data passing approach used by Staffware 254

Task to Subprocess Data Interaction in YAWL
255

Data Interaction – To/From Multiple Instance Tasks
Instance-Specific Data Passed by Value instances B3 use(m[3]) A use(M) B2 use(m[2]) C use(M) pass(M) pass(M) B1 use(m[1]) (not supported in UML 2.0, BPMN) multiple instance task 256

shared data storage Instance-Specific Data Passed by Reference array M: 1 2 3 4 .. instances B3 use(*m[3]) A use(&M) B2 use(*m[2]) C use(*M) pass(&M) pass(&M) B1 use(*m[1]) (not supported in BPMN) multiple instance task 257

shared data storage Shared Data Passed by Reference var M: instances B3 use(*m[3]) A use(&M) B2 use(*m[2]) C use(*M) pass(&M) pass(&M) B1 use(*m[1]) (not supported in UML 2.0, BPMN) multiple instance task 258

MI data in YAWL (source: YAWL User Manual)
Four XQueries are used to specify how data is passed to and from the instances of a multiple instances task. accessor query for manipulating the overall multiple instance data before the unique values are split out (to individual execution instances); splitter query for separating the unique values from the overall multiple instance data and passing a unique value to each instance; instance query for transforming the XML document returned on completion of an instance to a form that is suitable for aggregation; aggregate query for generating an overall result and passing the result to the higher level on completion of the multiple instance task. 259 259

MI data in YAWL 260

MI data in YAWL MI task task data 261

MI data in YAWL 262

Data Interaction Support: MI tasks
to MI task from MI task Staffware - WebSphere FLOWer + COSA YAWL BPMN BPEL UML 2.0 ADs 263 263

Data Interaction Patterns: External
Data communication between active elements within a workflow and the external operating environment. Task to Environment – Push-Oriented Environment to Task – Pull-Oriented Environment to Task – Push-Oriented Task to Environment – Pull-Oriented Case to Environment – Push-Oriented Environment to Case – Pull-Oriented Environment to Case – Push-Oriented Case to Environment – Pull-Oriented Workflow to Environment – Push-Oriented Environment to Workflow – Pull-Oriented Environment to Workflow – Push-Oriented Workflow to Environment – Pull-Oriented 264

Data Interaction - Task to/from Environment
external process case B pattern 14 pass(M) def var S def var T pattern 15 D def var M A request(T) pass(T) pattern 16 C E def var N pass(S) pattern 17 request(N) pass(N) 265

Data Interaction: Task – Environment - 1
Interaction initiated by task Environment receives data Interaction initiated by task Task receives data 266

Data Interaction: Task – Environment - 2
Interaction initiated by env. Task receives data Interaction initiated by env. Environment receives data 267

Data Interaction Support: Task - Environment
TE-Push ET-Pull ET-Push TE-Pull Staffware + +/- WebSphere FLOWer COSA YAWL - BPMN BPEL UML 2.0 ADs 268

Data Transfer Patterns
Focus on the means by which a data element is transferred across the interface of a workflow component. Data Transfer by Value – Incoming Data Transfer by Value – Outgoing Data Transfer – Copy In/Copy Out Data Transfer by Reference – Unlocked Data Transfer by Reference – Locked Data Transformation – Input Data Transformation – Output 269

Data Transfer by Value var G var H transient variable
use(R) par out ret R→G par in def var S:=G B use(S) par out ret S→H par in def var T:=H C use(T) 270

Data Transfer by Value Value Staffware - WebSphere + FLOWer COSA +/-
YAWL BPMN BPEL UML 2.0 ADs The ability of a workflow component to receive incoming data elements by value relieving it from the need to have shared names or common address space with the component(s) from which it receives them. 271

Data Transformation var G transient variable A B use(R) use(S) par out
return transform(R)→G par in def var S:= prepare(G) A use(R) B use(S) 272

Data Transformation Staffware +/- WebSphere - FLOWer COSA YAWL + BPMN
BPEL UML 2.0 ADs Ability to apply a transformation function to a data element during passing between workflow components. 273

Data Transfer and Transformation in YAWL
274

Data Routing Patterns Focus on the manner in which data elements can
influence the operation of the workflow Task Precondition - Data Existence Task Precondition - Data Value Task Postcondition – Data Existence Task Postcondition - Data Value Event-based Task Trigger Data-based Task Trigger Data-based Routing 275

Task Postcondition – Data Existence
not exists(R) par out return(R) postcondition exist(R) A use(R) par in def var S:=R B use(S) 276

Event-based Task Trigger
Start_A() Start_B() task task Start_C() task 277

Data-based Routing B A C D workflow repository workflow def var M 2.7
case repository def var N case B AB02 R > 10 par out ret R A C M > 3.1 N <> AB01 D 278

Data-based Routing Staffware +/- WebSphere + FLOWer COSA YAWL BPMN
BPEL UML 2.0 ADs The ability to alter the control flow within a workflow case as a consequence of the value of data-based expressions 279

Data-based Routing in YAWL
280

Data Perspective: Evaluation
1 – YAWL 2 – BPMN 3 – BPEL 281

Data Patterns: General Findings
Workflow data patterns generalise to all forms of PAIS All patterns observed in surveyed tools; Wide variations in support between tools. Data support for concurrent processes is limited: Lack of concurrency control; Minimal support for multiple instance tasks. Direct support for data patterns in current design tools is limited; and Current standards (e.g. XPDL, BPEL) do not provide useful guidance of data usage in workflow. 282

The Workflow Resource Patterns
Workflow Patterns Framework The Workflow Resource Patterns 283

Workflow Resource Patterns
Focus on the manner in which work is offered to, allocated to and managed by workflow participants Consider both the system and resource perspectives Assume the existence of a process model and related organisational model Take into account differing workflow paradigms: richness of process model (esp. allocation directives) autonomy of resources alternate routing mechanisms work management facilities 284

Resource Patterns Classes
Creation patterns: design-time work allocation directives Push patterns: workflow system proactively distributes work items Pull patterns: resources proactively identify and commit to work items Detour patterns: re-routing of work items Auto-start patterns: automated commencement Visibility patterns: observability of workflow activities Multiple resource patterns: work allocation involving multiple participants or resources 285

Work Item Lifecycle S:offer-s R:start-s R:allocate-s R:suspend
offered to a single resource suspended S:offer-s R:start-s R:allocate-s R:suspend R:resume S:create R:complete allocated to a single resource created S:allocate R:start started completed R:allocate-m R:fail R:start-m S:offer-m offered to multiple resources failed 286

Creation Patterns Design time considerations relating to which
resources may execute a work item at runtime Direct Allocation Role-Based Allocation Deferred Allocation Authorisation Separation of Duties Case Handling Retain Familiar Capability-Based Allocation History-Based Allocation Organisational Allocation Automatic Execution 287

Creation Patterns R:start-s S:offer-s R:allocate-s R:suspend R:resume
offered to a single resource suspended R:start-s S:offer-s R:allocate-s R:suspend R:resume S:create allocated to a single resource created started completed S:allocate R:start R:complete R:start-m R:fail S:offer-m R:allocate-m offered to multiple resources failed 288

Direct Allocation The ability to directly specify at design time the identity of the resource that will execute a task. Staffware + WebSphere FLOWer COSA YAWL BPMN Oracle BPEL UML 2.0 ADs 289

Direct Allocation in YAWL
290

Role-based Allocation
The ability to specify at design time that a task can only be executed by resources which correspond to a given role. Actual decision for distribution is deferred till runtime and can be influenced without changing workflow specification (thus providing more flexibility). Staffware + WebSphere FLOWer COSA YAWL BPMN Oracle BPEL UML 2.0 ADs 291

Role-based Allocation in YAWL
292

Deferred Allocation The ability to defer specifying the identity of the resource that will execute a task until runtime Takes deferral of resource allocation one step further Can be achieved through a variable that contains actual resource(s) to be used 293

Deferred Allocation 294

Separation of Duties The ability to specify that two tasks must be allocated to different resources in a given workflow case. Also referred to as the “4 eyes principle” Staffware - WebSphere + FLOWer COSA +/- YAWL BPMN Oracle BPEL UML 2.0 ADs 295

Separation of Duties in YAWL
296

Retain Familiar Where several resources are available to undertake a work item, the ability to allocate a work item within a given workflow case to the same resource that undertook a preceding work item. Staffware - WebSphere + FLOWer COSA YAWL BPMN Oracle BPEL UML 2.0 ADs 297

Retain Familiar in YAWL
298

Capability-based Allocation
The ability to offer or allocate instances of a task to resources based on specific capabilities that they possess. Staffware - WebSphere FLOWer + COSA YAWL BPMN Oracle BPEL UML 2.0 ADs 299

Capability-based Allocation in YAWL
300

Push Patterns Correspond to situations where newly created work items are proactively routed to resources by the workflow system Key dimensions: Offer or allocation Single or multiple resources Basis of allocation Timing of distribution vs enablement 301

Push Patterns R:start-s S:offer-s R:allocate-s R:suspend R:resume

Push Patterns Distribution by Offer - Single Resource
Distribution by Offer - Multiple Resources Distribution by Allocation - Single Resource Random Allocation Round Robin Allocation Shortest Queue Early Distribution Distribution on Enablement Late Distribution 303

Distribution by Offer – Single Resource
The ability to offer a work item to a selected resource Corresponds to the workflow analogy to the act of “asking for consideration" in real life – resource is advised of but not committed to undertaking the work item Staffware - WebSphere FLOWer COSA +/- YAWL + BPMN Oracle BPEL UML 2.0 ADs 304

Distribution by Offer in YAWL
305

Distribution by Offer – Multiple Resources
The ability to offer a work item to a group of selected resources. Offering a work item to multiple resources is the workflow analogy to the act of "calling for a volunteer" in real life. It provides a means of advising a suitably qualified group of resources that a work item exists but leaves the onus with them as to who actually commits to undertaking the activity. Can be realised through so-called work groups 306

Distribution by Offer – Multiple Resources
307

Distribution by Allocation – Single Resource
The ability to allocate a work item to a selected resource Corresponds to the workflow analogy to the act of "appointing an owner" in real life – the selected resource is committed to undertaking the work item Staffware + WebSphere FLOWer COSA YAWL BPMN Oracle BPEL UML 2.0 ADs 308

Shortest Queue The ability to allocate a work item to the resource that has the least number of work items allocated to it. Aims to expedite throughput Different definition of shortest queue possible Staffware - WebSphere FLOWer COSA + YAWL BPMN Oracle BPEL +/- UML 2.0 ADs 309

Distribution by Allocation in YAWL
310

Pull Patterns Correspond to situations where a resource proactively seeks information on available work and commits to undertaking specific work items Key dimensions Allocation vs execution Configurability of work basket Autonomy in selecting next work item 311

Pull Patterns R:start-s S:offer-s R:allocate-s R:suspend R:resume

Pull Patterns Resource-Initiated Allocation
Resource-Initiated Execution – Allocated Work Item Resource-Initiated Execution – Offered Work Item System-Determined Work List Management Resource-Determined Work List Management Selection Autonomy 313

Resource-Initiated Allocation
The ability for a resource to commit to undertake a work item without needing to commence working on it immediately. Allows a resource to signal its intention to execute a given work item at some point although it may not commence working on it immediately. The work item is considered to be allocated to the resource and it cannot be allocated to or executed by another resource. Staffware - WebSphere FLOWer + COSA +/- YAWL BPMN Oracle BPEL UML 2.0 ADs 314

Resource-Initiated Allocation in YAWL
315

Resource-Initiated Execution – Allocated Work Item
The ability for a resource to commence a work item previously allocated to them Staffware + WebSphere FLOWer COSA YAWL BPMN - Oracle BPEL UML 2.0 ADs 316

Resource-Initiated Execution in YAWL
317

Detour Patterns Correspond to unplanned variations in work item routing Key dimensions Initiator of re-routing action – system or resource Execution state of work item Recipient of re-routed work item 318

R:reallocation-no-state
Detour Patterns S:escalate-oo offered to a single resource R:escalate-so S:deallocate-so suspended R:deallocate-ao S:escalate-ao S:escalate-sm R:suspend R:resume R:reallocation- with-state R:delegate S:escalate-aa allocated to a single resource created started completed S:escalate-am R:deallocate-am R:reallocation-no-state S:escalate-sa S:skip R:fail offered to multiple resources R:deallocate-sm S:escalate-sm failed S:escalate-mm 319

Detour Patterns Delegation Escalation Deallocation
Stateful Reallocation Stateless Reallocation Suspension/Resumption Skip Redo Pre-Do 320

Delegation The ability for a resource to allocate a work item previously allocated to it to another resource. Delegation provides a resource with a means of re-routing work items that it is unable to execute. This may be because the resource is unavailable (e.g. on vacation) or because they do not wish to take on any more work. What happens where a work item is delegated to a user who is not authorised to execute it? This scenario is only a problem for workflow engines that support distinct task routing and authorisation mechanisms. COSA’s solution is to allow the new user to see the work item but not to be able to delegate it, they can then delegate themselves or acquire necessay rights 321

Delegation Staffware + WebSphere FLOWer - COSA YAWL BPMN Oracle BPEL
UML 2.0 ADs 322

Delegation in YAWL 323

Stateful Reallocation
The ability of a resource to allocate a work item to another resource without loss of state data. Provides a resource with the ability to offload both pending and currently executing work items to other resources whilst retaining work already performed. Centres on the ability to retain the current values of all data elements associated with the work item. Delegation also results in a work item being reassigned to another resource, but delegation only occurs for work items that have not yet been started Two main issues: Managing the transfer of state data. Ensuring the resource to which the work item is reallocated is entitled to execute it and access the associated state information. 324

Stateful Reallocation
Staffware +/- WebSphere + FLOWer - COSA YAWL BPMN Oracle BPEL UML 2.0 ADs 325

Stateful Reallocation in YAWL
326

Auto-start Patterns Relate to situations where execution of a work item is triggered by specific events in the lifecycle of a work item or related work items: e.g. Creation Allocation Completion of preceding tasks Completion of another instance of the same task 327

Auto-start Patterns R:start-s S:offer-s R:allocate-s R:suspend
offered to a single resource suspended R:start-s S:offer-s R:allocate-s R:suspend R:resume S:start-on-create S:create R:complete allocated to a single resource created started completed R:start S:allocate S:piled-execution S:chained-execution S:start-on-allocate R:fail S:offer-m R:allocate-m offered to multiple resources R:start-m failed 328

Auto-start Patterns Commence on Creation Commence on Allocation
The ability for a resource to commence execution on a work item as soon as it is created. Commence on Allocation The ability for a resource to commence execution on a work item as soon as it is allocated. Piled Execution The ability to initiated the next instance of a task (perhaps in a different case) once the previous one has completed with all associated work items being allocated to the same resource. Chained Execution The ability to automatically start the next work item in a case once the previous one has completed. The transition to Chained Execution mode is at the instigation of the resource. 329

Commencement on Creation
The ability for a resource to commence execution on a work item as soon as it is created Staffware - WebSphere FLOWer COSA YAWL + BPMN Oracle BPEL UML 2.0 ADs 330

Commencement on Creation in YAWL
331

Piled Execution The ability of the workflow system to initiate the next instance of a workflow task (perhaps in a different case) once the previous one has completed. Provides a means of optimising task execution by pipelining instances of the same task and allocating them to the same resource. The resource undertakes work items sequentially and once a work item is completed, if another work item of the same type is present in the work queue, it immediately commences work on it - in effect it attempts to work on piles of the same types of work items. The aim is to leverage of experience of a resource in performing a certain type of task. 332

Piled Execution Staffware - WebSphere FLOWer COSA YAWL + BPMN
Oracle BPEL UML 2.0 ADs 333

Piled Execution in YAWL
334

Chained Execution The ability of the workflow engine to automatically start the next work item in a case once the previous one has completed. Aims to expedite throughput Keeps a resource constantly busy in progressing a case 335

Chained Execution 336

Visibility & Multiple Resource Patterns
Visibility Patterns Relate to visibility of the existence and status of work items by workflow participants Configurable Unallocated Work Item Visibility Configurable Allocated Work Item Visibility Multiple Resource Patterns Relate to situations where work allocation involves multiple participants or resources Simultaneous Execution Additional Resource 337

Resource Patterns: Evaluation
1 – YAWL 2 – BPMN, 3 – Oracle BPEL PM (from [Mulyar 2005]) 338

Major findings: survey of resource patterns
Broad support for simple work distribution mechanisms Current offerings incorporate minimalistic organisational models. Little support for specifying user privileges and security restrictions. Limited granularity for varying method and timing of work distribution within a given process. Limited support for managing work items involving multiple participants. No support for optimising work item throughput by aligning work distribution with user worklist interaction. 339

Some Observations Virtually all patterns have been observed in at least one system/language Overall pattern support is generally limited, especially the resource perspective and exception handling Provide detailed insight into relative strengths and weaknesses of various approaches More research needed into relation between patterns and their suitability for specific types of applications 340

Further details Key papers Online references www.workflowpatterns.com
N. Russell, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Workflow Data Patterns: Identification, Representation and Tool Support. In L. Delcambre et al., editors, Proceedings of the 24th International Conference on Conceptual Modeling (ER 2005), volume 3716 of Lecture Notes in Computer Science, pages Springer-Verlag, Berlin, 2005. N. Russell, W.M.P. van der Aalst, A.H.M. ter Hofstede, and D. Edmond. Workflow Resource Patterns: Identification, Representation and Tool Support. In O. Pastor and J. Falcao e Cunha, editors, Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE'05), volume 3520 of Lecture Notes in Computer Science, pages Springer-Verlag, Berlin, 2005. Online references 341

Instruction question – 1
Evaluate the extent of support for the following patterns in Staffware, YAWL, core BPMN and Protos. Use a three point scale where + is full support, +/- indicates a partial solution or workaround and – corresponds to no support Synchronisation Multi-choice Deferred choice Multiple choice Local synchronising merge Milestone 342

For the YAWL model opposite, explain what configuration is required to pass the data elements shown in the pick order and print invoice tasks to the pack order task. Identify the data patterns used. What are the advantages and disadvantages of this data passing strategy? 343

For the YAWL process shown, determine the necessary data passing configuration to support the exclusive choice associated with the pack order task. Identify the data patterns used. NB: Assume the weight and value variables are defined for the pack order task. 344

For the YAWL process shown, determine the necessary data passing configuration to support (1) the passing of the custid and value data elements from the credit check task to the subprocess and (2) the configuration of the associated XOR-split. Identify the data patterns used. 345

The organisational model opposite corresponds to the YAWL process in Q2. Explain how the following task allocations are configured in YAWL: offer pick order to bart allocate pack order to the warehouse role offer pick order to bart and homer allocate print invoice to the admin role allocate print invoice to the admin role member with the shortest queue allocate pack order to milhouse in the started state allocate pack order to a member of the warehouse role that didn’t execute pick order for the same case Identify the patterns used in each case 346

In a workflow system such as YAWL, active work items can be in an offered, allocated or started state. The transition to each state can be initiated by the system or the resource. The triple (offered by, allocated by, started by) is termed the interaction sequence for a task. Explain the events associated with the following interaction sequences: SSR SRS SRR SSS RSS RSR RRS RRR How are each of them configured in YAWL? Which patterns do they correspond to? 347

Which patterns do the following approaches to work distribution correspond to? Offer the quote shipment task to john smith Allocate the batch rivet task to a manager Allocate the batch rivet task to the resource with the least work Offer the dangerous mission task to all junior soldiers Allocate the dangerous mission task to a soldier who serves in the marine or infantry division Allocate the dangerous mission task to a soldier with one or more bravery citations Allocate the batch rivet task to the resource who has not executed the earlier prepare solder task Allocate the count cash task to a resource who has undertaken the prepare reconciliation task for more than 2 weeks Distribute the coordinate journey task to the least busy colonel in the marine corps 348

Instruction question - 8
With the aid of a task lifecycle diagram, explain the difference between the delegation and stateful reallocation patterns How are each of them configured in YAWL? What user interactions are associated with each of them? 349

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

Chapter 2 The Language: Rationale and Fundamentals (Part V)

Control-flow Control-flow specification in YAWL Pattern (cont’d) Data (incl how realised in YAWL) Resources (incl how realised in YAWL) Syntax of YAWL (set theory) 352

Part V: Formal Syntax of YAWL
Abstract Syntax in Set Theory 353

YAWL specification A YAWL specification is a set of YAWL nets which form a rooted graph structure. Each YAWL net is composed of a series of tasks. Definition 12. (YAWL Specification) A YAWL specification is a tuple = (NetID, ProcessID, TaskID, MITaskID, VarID, ParamID, TNmap, NYmap, VarName, Data-Type, VName, DType, VarType, VNmap, VTmap, VMmap) such that: (* global objects *) • NetID is the set of net identifiers (i.e. the top-level process together with all sub processes); • ProcessID ∈ NetID is the process identifier (i.e. the top-level net); • TaskID is the set of task identifiers in nets; • MITaskID ⊆ TaskID is the set of identifiers of multiple instance tasks; • VarID is the set of variable identifiers used in nets; • ParamID is the set of parameter identifiers used in nets;

YAWL specification (cont’d)
Definition 12. (YAWL Specification) (* decomposition *) • TNmap: TaskID / NetID defines the mapping between composite tasks and their corresponding sub-process decompositions which are specified in the form of a YAWL net, such that for all t, TNmap(t) yields the NetID of the corresponding YAWL-net, if it exists; • NYmap: NetID → YAWLnets, i.e. each net has a complete description of its contents such that for all n ∈ NetID, NYmap(n) is governed by Definition 13 where the notation Tn denotes the set of tasks that appear in a net n. Tasks are not shared between nets hence ∀m,n∈NetID[Tm ∩ Tn ≠ ∅ ⇒ m = n]. TaskID is the set of tasks used in all nets and is defined as TaskID = n∈NetID Tn; • In the directed graph defined by G = (NetID,{(x,y) ∈ NetID×NetID | ∃t∈Tx [t ∈ dom(TNmap) ∧ TNmap(t) = y]}) there is a path from ProcessID to any node n ∈ NetID;

YAWL specification (cont’d)
Definition 12. (YAWL Specification) (* variables *) • VarName is the set of variable names used in all nets; • DataType is the set of data types; • VName: VarID → VarName identiﬁes the name for a given variable; • DType: VarID → DataType identiﬁes the underlying data type for a variable; • VarType: VarID → {Net,Task,MI} describes the various variable scopings that are supported. The notation VarIDx = {v ∈ VarID | VarType(v) = x} identifies variables of a given type; • VNmap: VarIDNet → NetID identifies the specific net to which each net variable corresponds, such that dom(VNmap) = VarIDNet; • VTmap: VarIDTask → TaskID identifies the specific task to which a task variable corresponds, such that dom(VTmap) = VarIDTask; • VMmap: VarIDMI → MITaskID identifies the specific task to which each multiple instance variable corresponds, such that dom(VMmap) = VarIDMI.

YAWL net Definition 13. (YAWL net)
A YAWL net is a tuple (nid, C, i, o, T, TA, TC, M, F, Split, Join, Default,<XOR, Rem, Nofi, ArcCond) such that: (* basic control-flow elements *) • nid ∈ NetID is the identity of the YAWL net; • C is a set of conditions; • i ∈ C is the input condition; • o ∈ C is the output condition; • T is the set of tasks; • TA ⊆ T is the set of atomic tasks; • TC ⊆ T is the set of composite tasks; • TA and TC form a partition over T ; • M ⊆ T is the set of multiple instance tasks; • F ⊆ (C \ {o}×T )∪(T ×C \ {i})∪(T ×T ) is the flow relation, such that every node in the graph (C ∪ T,F) is on a directed path from i to o;

YAWL net (cont’d) Definition 13. (YAWL net)
• Split : T / {AND,XOR,OR} specifies the split behavior of each task; • Join : T / {AND,XOR,OR} specifies the join behavior of each task; • Default ⊆ F, Default : dom(Split ► {OR}) → T ∪C denotes the default arc for each OR-split. If none of the outgoing arc expressions evaluate to true, the default arc indicated by Default(t) is selected, thus ensuring that at least one outgoing arc is enabled; • <XOR ⊆ {t ∈ T | Split(t) = XOR} × Ƥ((T ∪C) × (T ∪C)) describes the evaluation sequence of outgoing arcs from an XOR-split such that for any (t, V ) ∈<XOR we write <t XOR = V and V is a strict total order over t• = {x ∈ T ∪C |(t, x) ∈ F}. Link conditions associated with each arc are evaluated in this sequence until the ﬁrst evaluates to true. If none evaluate to true, the minimum element (which corresponds to the default path and is denoted as ⊥t ) is selected;

YAWL net (cont’d) Definition 13. (YAWL net)
• Rem : T / Ƥ+(T ∪C\{i,o}) specifies the additional tokens to be removed by emptying a part of the net and tasks that should be canceled as a consequence of an instance of this task completing execution; • Nofi: M → N×Ninf ×Ninf ×{dynamic,static} specifies the multiplicity of each task – in particular the lower and upper bound of instances to be created at task initiation, the threshold for continuation indicating how many instances must complete for the thread of control to be passed to subsequent tasks and whether additional instances can be created “on the fly” once the task has commenced; (* conditions on arcs *) • ArcCond : F ∩ (dom(Split ► {XOR,OR}) × (T ∪C)) → BoolExpr identifies the specific condition associated with each branch of an OR or XOR split.

Data Passing Deﬁnition 14. (Data passing model)
Within the context of a YAWL net nid, there is a data passing model (ParamVar, InPar, OutPar, Accessor, Splitter, Instance, Aggregate) with the following components: (* parameter variable definition *) • ParamVar: ParamID → VarID × VarID is a function identifying the source and target variables for a given parameter; (* data passing to/from atomic tasks *) • InPar: ParamID × T → Expr is a function identifying the input parameter mappings to a task at initiation; • OutPar: ParamID × T → Expr is a function identifying the output parameter mappings from a task at completion;

Data Passing (cont’d) Deﬁnition 14. (Data passing model)
(* data passing to/from multiple instance tasks *) • Accessor : TM → RecExpr is a function identifying the accessor query for a multiple instance task; • Splitter : TM → Expr is a function identifying the splitter query for a multiple instance task; • Instance: TM → Expr is a function identifying the instance query for a multiple • Aggregate: TM → RecExpr is a function identifying the aggregate query for a multiple instance task.

Organizational Model Definition 15. (Organizational model)
Within the context of a YAWL speciﬁcation ProcessID, there is an organizational model described by the tuple (UserID, RoleID, CapabilityID, OrgGroupID, PositionID, CapVal, RoleUser, OrgGroupType, GroupType, PositionGroup, OrgStruct, Superior, UserQual, UserPosition) as follows: (* basic definitions *) • UserID is the set of all individuals to whom work items can be distributed; • RoleID is the set of designated groupings of those users; • CapabilityID is the set of qualities that a user may possess that are useful when making work distribution decisions; • OrgGroupID is the set of groups within the organization; • PositionID is the set of all positions within the organization; • CapVal is the set of values that a capability can have;

Organizational Model (cont’d)
Definition 15. (Organizational model) (* organizational definition *) • RoleUser : RoleID → Ƥ(RoleUser) indicates the set of users in a given role; • OrgGroupType = {team,group,department,branch,division,organization} identifies the type of a given organizational group; • GroupType: OrgGroupID → OrgGroupType; • PositionGroup: PositionID → OrgGroupID indicates which group a position belongs to; • OrgStruct: OrgGroupID /→ OrgGroupID forms an acyclic intransitive graph with a unique root which identiﬁes a composition hierarchy for groups; • Superior: PositionID /→ PositionID forms an acyclic intransitive graph which identifies the reporting lines between positions;

Organizational Model (cont’d)
Definition 15. (Organizational model) (* user definition *) • UserQual: UserID × CapabilityID → CapVal ∪ {Undefined} identifies the capabilities that a user possesses; • UserPosition: UserID → Ƥ(PositionID) maps a user to the positions that they hold.

Work Distribution Model
Definition 16. (Work distribution model) Within the context of a YAWL net nid, it is possible to describe the manner in which work items are distributed to users for execution. A work distribution model is a tuple (ResourceVarID, Auto, TM, Initiator, DistUser, DistRole, DistVar, OrgDist, CapDist, SameUser, FourEyes, UserSel, UserPriv, UserTaskPriv) as follows: (* work allocation *) • ResourceVarID ⊆ VarID is the set of variables which identify resources or roles; • Auto ⊆ TA is the set of tasks which execute automatically without user intervention, where TA is the set of atomic tasks; • TM ⊆ TA\Auto is the set of atomic tasks that must be allocated to users for execution;

Work Distribution Model (cont’d)
Definition 16. (Work distribution model) • Initiator: TM → {system,resource} × {system,resource} × {system,resource} indicates who initiates the offer, allocate and commence actions; • DistUser: TM /→ Ƥ(User) identifies the users to whom a task should potentially be distributed; • DistRole: TM /→ Ƥ(Role) identifies the roles to whom a task should potentially • DistVar: TM /→ Ƥ(ResourceVarID) identiﬁes a set of variables holding either user or roles to whom a task should potentially be distributed; • dom(DistUser), dom(DistRole) and dom(DistVar) form a partition over TM;

Work Distribution Model (cont’d)
Definition 16. (Work distribution model) • OrgDist: TM /→ OrgExpr identifies the organizational criterion that users that execute the task must satisfy; • CapDist: TM /→ CapExpr identifies the capability that users that execute the task must possess; • SameUser: TM /→ TM is an irreflexive function that identifies that a task should be executed by one of the same users that undertook another speciﬁed task in the same case; • FourEyes: TM /→ TM is an irreflexive function that identifies a task that should be executed by a different user to the one(s) that executed another speciﬁed task in the same case; • UserSel: TM /→ {random, round-robin-time, round-robin-freq, round-robin-exp, shortest-queue} indicates how a specific user who will execute a task should be selected from a group of possible users;

Work Distribution Model
Definition 16. (Work distribution model) (* user privilege definition *) • UserPriv: UserID → Ƥ(UserAuthKind) indicates the privileges that an individual user possesses, where UserAuthKind = {choose, concurrent, reorder, viewitem, viewgroup, chainedexec, managecase}; • UserTaskPriv: UserID × TaskID → Ƥ(UserTaskAuthKind) indicates the privileges that an individual user possesses in relation to a speciﬁc task, where UserTaskAuthKind = {suspend, start, reallocate, reallocate state, deallocate, piledexec, delegate, skip}.

The Language: Rationale and Fundamentals (Part I)

Similar presentations

Presentation on theme: "The Language: Rationale and Fundamentals (Part I)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Language: Rationale and Fundamentals (Part I)

Similar presentations

Presentation on theme: "The Language: Rationale and Fundamentals (Part I)"— Presentation transcript:

Similar presentations

About project

Feedback