On the Expressive Power of (Petri-net-based) Workflow Languages 16 april 2017 Workflow Patterns On the Expressive Power of (Petri-net-based) Workflow Languages Wil van der Aalst Eindhoven University of Technology Department of Information and Technology P.O. Box 513, 5600 MB Eindhoven The Netherlands w.m.p.v.d.aalst@tm.tue.nl

Outline Workflow management systems 16 april 2017 Outline Workflow management systems Limitations of contemporary systems Workflow patterns Limitations of (colored) Petri nets Patterns involving multiple instances Advanced synchronization patterns Cancellation patterns YAWL: Yet Another Workflow Language Examples Conclusion

Workflow management systems

Reference model of the Workflow Management Coalition What? When? Who?

Limitations of existing workflow management systems: The three most serious problems

1. No support for analysis 4 runs (8 sequences) are possible: Only one is correct.

Improved process

2. Lack of flexibility Etc. Staffware FLOWer Etc. COSA MQSeries Vectus InConcert Ensemble Notes Exchange

3. Limited expressive power workflow patterns

Workflow patterns Joint work with Arthur ter Hofstede (QUT), Bartek Kiepuszewski (QUT), Alistair Barros (DSTC), Oscar Ommert (EUT), Ton Pijpers (ATOS), et al.

Workflow patterns The academic response A quest for the basic requirements 20 basic patterns 16 systems Joint work with QUT, ATOS, etc.

Categories of patterns Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Structural Patterns Pattern 10 (Arbitrary Cycles) Pattern 11 (Implicit Termination) State-based Patterns Pattern 16 (Deferred Choice) Pattern 17 (Interleaved Parallel Routing) Pattern 18 (Milestone) Patterns involving Multiple Instances Pattern 12 (Multiple Instances Without Synchronization) Pattern 13 (Multiple Instances With a Priori Design Time Knowledge) Pattern 14 (Multiple Instances With a Priori Runtime Knowledge) Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge) Cancellation Patterns Pattern 19 (Cancel Activity) Pattern 20 (Cancel Case)

Pattern 4: Exclusive choice Pattern 2: Parallel split Pattern 3: Synchronization

State-based patterns Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Structural Patterns Pattern 10 (Arbitrary Cycles) Pattern 11 (Implicit Termination) State-based Patterns Pattern 16 (Deferred Choice) Pattern 17 (Interleaved Parallel Routing) Pattern 18 (Milestone) Patterns involving Multiple Instances Pattern 12 (Multiple Instances Without Synchronization) Pattern 13 (Multiple Instances With a Priori Design Time Knowledge) Pattern 14 (Multiple Instances With a Priori Runtime Knowledge) Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge) Cancellation Patterns Pattern 19 (Cancel Activity) Pattern 20 (Cancel Case)

Example process: Complaints handling process_form send_form c1 c5 archive c3 time-out evaluate start register ready c7 c2 c6 c4 check_proc process_complaint

Workflow pattern 16: Deferred Choice process_form send_form c1 c5 archive c3 time-out evaluate start register ready c7 c2 c6 c4 check_proc process_complaint

Workflow pattern 18: Milestone process_form send_form c1 c5 archive c3 time-out evaluate start register ready c7 c2 c6 c4 check_proc process_complaint

The process can be handled by COSA …. But not by many others …

basic adv. synch. struct. mult. inst. state cancel pattern product Staffware COSA InConcert Eastman FLOWer Domino Meteor Mobile 1 (seq) + 2 (par-spl) 3 (synch) 4 (ex-ch) +/- 5 (simple-m) 6 (m-choice) - 7 (sync-m) 8 (multi-m) 9 (disc) 10 (arb-c) 11 (impl-t) 12 (mi-no-s) 13 (mi-dt) 14 (mi-rt) 15 (mi-no) 16 (def-c) 17 (int-par) 18 (milest) 19 (can-a) 20 (can-c) basic adv. synch. struct. mult. inst. state cancel

basic adv. synch. struct. mult. inst. state cancel pattern product MQSeries Forté Verve Vis. WF Changeng. I-Flow SAP/R3 1 (seq) + 2 (par-spl) 3 (synch) 4 (ex-ch) 5 (simple-m) 6 (m-choice) 7 (sync-m) - 8 (multi-m) 9 (disc) 10 (arb-c) +/- 11 (impl-t) 12 (mi-no-s) 13 (mi-dt) 14 (mi-rt) 15 (mi-no) 16 (def-c) 17 (int-par) 18 (milest) 19 (can-a) 20 (can-c) basic adv. synch. struct. mult. inst. state cancel

Practical impact http://www.tm.tue.nl/it/research/patterns                                                                                                                                                                                                                                           http://www.tm.tue.nl/it/research/patterns +/- 50 pageviews per w-day (>11.000 in total) Publications in Computable, Automatisering Gids, Business Process Magazine, VIP, Scope, etc.

Practical impact (2) Patterns are used in several selection processes (e.g., at this point in time by UWV – handling all job related insurances in the Netherlands) Role of vendors has been opportunistic “The fastest way to succeed is to look as if you're playing by somebody else's rules, while quietly playing by your own.” Michael Konda

Limitations of (colored) Petri nets

Strengths and weaknesses Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Structural Patterns Pattern 10 (Arbitrary Cycles) Pattern 11 (Implicit Termination) State-based Patterns Pattern 16 (Deferred Choice) Pattern 17 (Interleaved Parallel Routing) Pattern 18 (Milestone) Patterns involving Multiple Instances Pattern 12 (Multiple Instances Without Synchronization) Pattern 13 (Multiple Instances With a Priori Design Time Knowledge) Pattern 14 (Multiple Instances With a Priori Runtime Knowledge) Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge) Cancellation Patterns Pattern 19 (Cancel Activity) Pattern 20 (Cancel Case)

Three patterns difficult for (colored) Petri nets One pattern for each of the following categories: Patterns involving multiple instances (Pattern 7) Advanced synchronization patterns (Pattern 15) Cancellation patterns (Pattern 20) We are not interested in expressive power in the formal sense, instead we focus on practical limitations of using (colored) Petri nets as a workflow language.

(cf. MQSeries Workflow/EPCs) Pattern 7 (Synchronizing Merge)     Description A point in the workflow process where multiple paths converge into one single thread. If more than one path is taken, synchronization of the active threads needs to take place. (cf. MQSeries Workflow/EPCs)

Intermezzo: Many ways to join C B COSA (Ley): Places have capacity 1. MQSeries Workflow (IBM): True and false tokens. InConcert (TIBCO): Marked graph with conditional tasks. Enterprise Workflow (Eastman)/Domino Workflow (Lotus/IBM): “Wait as long as something may arrive.” Etc.

AND/XOR/OR-join The AND-join synchronizes each incoming connection. (Transition) The XOR-join never synchronizes. (Place) The OR-join has many interpretations: Wait for all to come (Synchronizing merge, Pattern 7) Wait for first to come and ignore others (Discriminator, Pattern 9) Wait for first to come and execute every time (Multi-merge, Pattern 8) Wait for N to come (N-out-of-M join, generalization of Pattern 9) ?

Mapping onto colored Petri nets (1) Passing information from the split to the join. Problems: Assumption: one-to-one correspondence split and join Overhead for designer (introducing counters, separating cases/instances, etc. )

Mapping onto colored Petri nets (2) Passing true and false tokens. Problems: Overhead for designer (introducing color sets, separating cases/instances, etc. ) Not possible when having loops

Mapping onto colored Petri nets (3) Timeout mechanism. Problems: Overhead for designer Incorrect mapping

Mapping onto colored Petri nets (4) Build new scheduler which explores progress condition. Problems: Overhead for designer Process structure not in model structure but in data

Pattern 15 (Multiple Instances Without a Priori Runtime Knowledge)     Description For one case an activity is enabled multiple times. The number of instances of a given activity for a given case is not known during design time, nor is it known at any stage during runtime, before the instances of that activity have to be created. Once all instances are completed some other activity needs to be started. The difference with Pattern 14 is that even while some of the instances are being executed or already completed, new ones can be created.

Example Within an insurance claim there may be multiple witnesses, i.e., multiple instances of a subprocess within a case. The number of instances may change dynamically (e.g., one witness pointing out a new witness). It is important not to mix up instances of different cases or different iterations (in loops) and to synchronize properly.

Problem (1) Multiple instances parent child When mapping onto colored nets quite some bookkeeping is needed the separate instances and to keep track of parent-child relations. Instances may be nested (e.g., one witness making several statements). Therefore, a color set like a sequence of natural numbers is needed, e.g., 1, 1.1, 1.2, 1.1.1, 1.1.2, 1.2.1, 1.2.2, 1.2.3, …

Problem (2) Synchronization Child instances having the same parent need to be synchronized. The number of instances is variable and instances are nested. The burden of keeping track of the number of active and completed instances per parent instance is left to the designer when using colored Petri nets (cf. Synchronizing merge).

Pattern 20 (Cancel Case) Description A case, i. e Pattern 20 (Cancel Case)     Description A case, i.e. workflow instance, is removed completely (i.e., even if parts of the process are instantiated multiple times, all descendants are removed). if C

Problems when mapping cancellation patterns onto (colored) Petri nets. Firing rule is local. A vacuum cleaner is needed to remove tokens selectively (case/instance). All tasks need to be connected to some central node.

YAWL Yet Another Workflow Language Joint work with Arthur ter Hofstede (QUT)

Standard constructs Notation and concepts borrowed from Petri nets with case identifiers.

AND/XOR/OR-splits/joins OR-join cannot be mapped on colored nets directly because it has the “Wait for all to come” semantics.

Multiple instances Four attributes: Minimum Maximum Threshold Static/dynamic

Removing tokens from selected parts Can be nested.

Syntactic sugaring

YAWL Semantics of YAWL is not mapped onto (colored) Petri nets but directly onto transition systems. Behavioral properties such as soundness have been defined. YAWL supports all patterns except Implicit termination (Pattern 11). Superior to existing languages.

Examples

Example (1)

Example (2)

Example (3)

Example (4)

Example (5)

Example (6)

Example (7)

Example (8)

Conclusion Patterns turned out to be useful for: Capturing requirements/selecting systems Supporting design efforts Training workflow designers (Colored) Petri nets are superior compared to existing workflow languages. Three problem areas have been identified: Patterns involving multiple instances Advanced synchronization patterns Cancellation patterns A new language has been proposed to overcome these problems: YAWL (Ongoing work).

More information http://www.tm.tue.nl/it/research/patterns http://www.tm.tue.nl/it/staff/wvdaalst

BPM 2003 INTERNATIONAL CONFERENCE ON BUSINESS PROCESS MANAGEMENT On the Application of Formal Methods to “Process-Aware” Information Systems Eindhoven, The Netherlands, June 26-27, 2003 http://www.tm.tue.nl/it/bpm2003