View
234
Download
2
Tags:
Embed Size (px)
Citation preview
Workflow PatternsOn the Expressive Power of (Petri-net-based) Workflow
Languages Wil van der Aalst
Eindhoven University of TechnologyDepartment of Information and Technology
P.O. Box 513, 5600 MB EindhovenThe Netherlands
Outline
1. Workflow management systems2. Limitations of contemporary systems3. Workflow patterns4. Limitations of (colored) Petri nets
• Patterns involving multiple instances• Advanced synchronization patterns• Cancellation patterns
5. YAWL: Yet Another Workflow Language6. Examples7. Conclusion
Reference model of the Workflow Management Coalition Process
Definition Tools
Administration & Monitoring
Tools
Interface 1
Interface 4Interface 5
Workflow Enactment Service
Workflow API and Interchange formats
Other WorkflowEnactment Service(s)
WorkflowClient
Applications
Interface 3Interface 2
WorkflowEngine(s)
WorkflowEngine(s)
InvokedApplications
What?When?Who?
Process Definition Tools
Administration & Monitoring
Tools
Interface 1
Interface 4Interface 5
Workflow Enactment Service
Workflow API and Interchange formats
Other WorkflowEnactment Service(s)
WorkflowClient
Applications
Interface 3Interface 2
WorkflowEngine(s)
WorkflowEngine(s)
InvokedApplications
Process Definition Tools
Administration & Monitoring
Tools
Interface 1
Interface 4Interface 5
Workflow Enactment Service
Workflow API and Interchange formats
Other WorkflowEnactment Service(s)
WorkflowClient
Applications
Interface 3Interface 2
WorkflowEngine(s)
WorkflowEngine(s)
InvokedApplications
Process Definition Tools
Administration & Monitoring
Tools
Interface 1
Interface 4Interface 5
Workflow Enactment Service
Workflow API and Interchange formats
Other WorkflowEnactment Service(s)
WorkflowClient
Applications
Interface 3Interface 2
WorkflowEngine(s)
WorkflowEngine(s)
InvokedApplications
2. Lack of flexibility
explicitlystructured
implicitlystructured
ad-hocstructured
unstructured
data-driven process-driven
ad-hoc workflow
groupware
productionworkflow
case handling
Staffware
COSA
MQSeries
FLOWer
Vectus
InConcert
Ensemble
Etc.
Etc.
Exchange
Notes
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.
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)
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)
State-based Patterns• Pattern 16 (Deferred
Choice)
• Pattern 17 (Interleaved Parallel Routing)
• Pattern 18 (Milestone)
Cancellation Patterns• Pattern 19 (Cancel Activity)
• Pattern 20 (Cancel Case)
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)
Structural Patterns • Pattern 10 (Arbitrary Cycles)
• Pattern 11 (Implicit Termination)
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)
State-based Patterns• Pattern 16 (Deferred
Choice)
• Pattern 17 (Interleaved Parallel Routing)
• Pattern 18 (Milestone)
Cancellation Patterns• Pattern 19 (Cancel Activity)
• Pattern 20 (Cancel Case)
State-based patterns
Example process: Complaints handling
start register
send_form
evaluate
process_complaint
check_proc
process_form
time-outarchive
ready
c1
c2
c3
c4
c5
c6
c7
start register
send_form
evaluate
process_complaint
check_proc
process_form
time-outarchive
ready
c1
c2
c3
c4
c5
c6
c7
Workflow pattern 16: Deferred Choice
Workflow pattern 18: Milestone
start register
send_form
evaluate
process_complaint
check_proc
process_form
time-outarchive
ready
c1
c2
c3
c4
c5
c6
c7
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.
mult.inst.
state
cancel
struct.
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.
mult.inst.
state
cancel
struct.
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.
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
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)
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)
State-based Patterns• Pattern 16 (Deferred
Choice)
• Pattern 17 (Interleaved Parallel Routing)
• Pattern 18 (Milestone)
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.
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.
A
B
C
D???OR
(cf. MQSeries Workflow/EPCs)
Intermezzo: Many ways to join
• 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.
A
join
B
C
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. )
A
B
C
D???OR
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
A
B
C
D???OR
Mapping onto colored Petri nets (3)
• Timeout mechanism.
• Problems:– Overhead for designer – Incorrect mapping
A
B
C
D???OR
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
A
B
C
D???OR
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.
registerwitnesses
archivestatements
interviewwitness
makereport
handlewitnesses
Problem (1)
Multiple instances
• 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, …
registerwitnesses
archivestatements
interviewwitness
makereport
handlewitnessesparent
child
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).
registerwitnesses
archivestatements
interviewwitness
makereport
handlewitnesses
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).
A
B
C
D???OR
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.
Standard constructs
Condition
Input condition
Output condition
Atomic task
Composite task
Notation and concepts borrowed from Petri nets with case identifiers.
AND/XOR/OR-splits/joins
AND-split task
XOR-split task
OR-split task
AND-join task
XOR-join task
OR-join task
OR-join cannot be mapped on colored nets directly because it has the “Wait for all to come” semantics.
Multiple instances
Multiple instancesof an atomic task
Multiple instancesof a composite task
Four attributes:
1. Minimum
2. Maximum
3. Threshold
4. Static/dynamic
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.
Example (1)
register
Task pay is executed only once, i.e., when all started tasks havecompleted (Pattern 7).
flight
hotel
car
pay
Example (2)
register
Task pay is executed each time one of the three preceding taskcompletes (Pattern 8).
flight
hotel
car
pay
Example (3)
register
Task pay is executed only once, i.e., when the first task hascompleted (Pattern 9).
flight
hotel
car
pay
Example (4)
register_witnesses
archiveprocess_witness_
statements
[1,10,inf,static]
A workflow processing between 1 and 10 witness statements withoutthe possibility to add witnesses after registration (Pattern 14).
Example (5)
A workflow processing an arbitrary number of witnesses with thepossibility to add new batches of witnesses (Pattern 15).
register_witnesses
archiveprocess_witness_
statements
[1,inf,inf,dynamic]
Example (6)
register_witnesses
archiveprocess_witness_
statements
[1,10,3,static]
A workflow processing between 1 and 10 witness statements witha threshold of 3 witnesses (extension of Pattern 9).
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).