Workflow Patterns On the Expressive Power of (Petri- net-based) Workflow Languages Wil van der Aalst Eindhoven University of Technology Department of Information

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

[email protected]

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

Workflow management systems

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


WorkflowEngine(s)

WorkflowEngine(s)

InvokedApplications

What?When?Who?

Process Definition Tools


Tools

Interface 1





WorkflowClient

Applications


WorkflowEngine(s)

WorkflowEngine(s)

InvokedApplications



Tools

Interface 1





WorkflowClient

Applications


WorkflowEngine(s)

WorkflowEngine(s)

InvokedApplications



Tools

Interface 1





WorkflowClient

Applications


WorkflowEngine(s)

WorkflowEngine(s)

InvokedApplications

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

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

ad-hocworkflow

groupwareproductionworkflow

casehandling

low

high

3. Limited expressive power

workflowpatterns

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)

Pattern 2: Parallel split

Pattern 3: Synchronization

Pattern 4: Exclusive choice

Basic Control Flow Patterns• Pattern 1 (Sequence)• Pattern 2 (Parallel Split)• Pattern 3 (Synchronization)• Pattern 4 (Exclusive Choice)• Pattern 5 (Simple Merge)











Choice)





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

The process can be handled by COSA ….

But not by many others …

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

Limitations of (colored) Petri nets

Basic Control Flow Patterns• Pattern 1 (Sequence)• Pattern 2 (Parallel Split)• Pattern 3 (Synchronization)• Pattern 4 (Exclusive Choice)• Pattern 5 (Simple Merge)



Strengths and weaknesses









Choice)





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


• 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


• Timeout mechanism.

• Problems:– Overhead for designer – Incorrect mapping

A

B

C

D???OR


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

YAWL Yet Another Workflow Language

Joint work with Arthur ter Hofstede (QUT)

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

Removing tokens from selected parts

... remove tokens

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)

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


statements

[1,inf,inf,dynamic]

Example (6)

register_witnesses


statements

[1,10,3,static]

A workflow processing between 1 and 10 witness statements witha threshold of 3 witnesses (extension of Pattern 9).

Example (7)

Cancel activity (Pattern 19).

cancel_activity

activity

Example (8)

Cancel case (Pattern 20).

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 ONBUSINESS 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

Documents

Workflow Patterns On the Expressive Power of (Petri- net-based) Workflow Languages Wil van der Aalst Eindhoven University of Technology Department of Information