Workflow Patterns

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

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

3. Workflow management systems

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

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

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

11. Improved process

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

14. 3. Limited expressive power workflowpatterns

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

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

17. Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) Categories of patterns • 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)

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

19. Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) State-based patterns • 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)

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

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

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

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

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

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

26. Practical impact • 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.

27. “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 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

28. Limitations of (colored) Petri nets

29. Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Advanced Branching and Synchronization Patterns Pattern 6 (Multi-choice) Pattern 7 (Synchronizing Merge) Pattern 8 (Multi-merge) Pattern 9 (Discriminator) Strengths and weaknesses • 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)

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

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

32. Intermezzo: Many ways to join A C join 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.

33. 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) ?

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

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

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

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

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

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

40. Problem (1)Multiple instances parent • 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, … child

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

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

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

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

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

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

47. Multiple instances • Four attributes: • Minimum • Maximum • Threshold • Static/dynamic

48. Removing tokens from selected parts Can be nested.

49. Syntactic sugaring

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