Chapter 4 "Process Orchestrations"

11

Click here to load reader

Transcript of Chapter 4 "Process Orchestrations"

Page 1: Chapter 4 "Process Orchestrations"

3/26/2013

1

Business Process MethodologyChapter 4- Process Orchestrations

Prepared by:Rao Majid Shamshad

University of Education, Lahoreemail: [email protected]

http://www.bpm-ue.blogspot.com

CHAPTER OUTLINE

• Section 4.1 introduces control flow patterns, ayardstick in process control flow structures. Thepatterns will be described both textually and moreformally using the event-based approach introduced inthe previous chapter.

• Section 4.2 provides a compact introduction to Petrinets. Different Petri net classes are introduced,including condition event nets, predicate transitionnets and, colored Petri nets.

• An informal perspective on business process modellingis taken in Section 4.3, where event-driven processchains are discussed. This approach is widely used inthe business domain to model business processes froma pragmatic, application-oriented point of view.

4.1 CONTROL FLOW PATTERNS

• Control flow patterns provide a yardstick forexpressing process orchestrations. Controlflow patterns are independent of concreteprocess languages, so that each pattern canbe expressed in different process languages.Control flow patterns can also be used tocompare the expressiveness of processlanguages.

• Basic control flow patterns include:

– sequence,

– and split,

– and join,

– exclusive or split

– exclusive or join.

• These control flow patterns are supported byvirtually any process meta-model. Control flowpatterns are defined at the process model level.Their execution semantics, however, applies toprocess instances.

4

Page 2: Chapter 4 "Process Orchestrations"

3/26/2013

2

• Activity models are denoted by capital letters,A,B,C, . . .,

• while the associated activity instances aredenoted by small letters, i.e. a, b, c, . . ..

• Gateways are typically denoted by G, and g isan instance of a gateway

• Let P be a process model and p a processinstance based on this model with an eventset Ɛᵨ.

5

SEQUENCE• The sequence pattern defines that an activity

instance b in a process instance p is enabledafter the completion of activity instance a in p,with process model

• P = (N,E, type) containing activity models A, B,and a gateway model G such that A,B Є NA,G Є NG, E Ͻ {(A,G), (G,B)}, andtype(G)=Sequence

6

• The application of the sequence pattern inA→B induces an event ordering between thetermination event of a (and the activityinstance of activity model A) and b, such thatb can only be enabled after a has terminated.This approach relates the control flowpatterns directly to the state transitions ofactivity instances.

• In particular, the state transition from init to enabled of an activity instance b can only be done after the state transition from running of a to terminated of a has occurred.

7 8

Page 3: Chapter 4 "Process Orchestrations"

3/26/2013

3

9

And Split

• An and split or parallel split is a point in aprocess model where a single thread ofcontrol splits into multiple threads of controlwhich are executed concurrently.

• An and split determines that for eachtermination of an activity instance a there areenable events of activity instances b and c,and these events occur after the terminationevent of a.

10

11

And Join

• An and join is a point in a process modelwhere multiple concurrent threads convergeinto one single thread of control. It is anassumption of this pattern that each incomingbranch is executed exactly once.

• For each enable event of an activity instanced, there are termination events of activityinstances b and c, such that the terminationevents occur before the enable event.

12

Page 4: Chapter 4 "Process Orchestrations"

3/26/2013

4

13

Xor Split

• An Xor split or exclusive or split is a point in aprocess model where one of several branchesis chosen.

• The execution semantics of an exclusive orsplit determines that for each termination ofan activity instance a associated with activitymodel A there is either an enable event ofactivity instance b or an enable event of anactivity instance c, but not both:

14

15

Xor Join• An xor join or exclusive or join is a point in a

process model where two or more alternativethreads come together without synchronization.It is an assumption of this pattern that exactlyone of the alternative branches is executed.

• For each termination event of an activity instanceb or c there is one and only one enable event ofan activity instance d.

• While it is an assumption of this pattern that thebranches are alternative and none of them areever executed in parallel, the branches can bepart of a loop. But even in this case, for eachiteration of a loop, the branches are alternativeand have exclusive or semantics.

16

Page 5: Chapter 4 "Process Orchestrations"

3/26/2013

5

17

Or Split

• An or split is a point in a process model where anumber of branches are chosen. Selection of anynonempty subset of branches is a properbehavior of an or split.

• An or split restricts the events of related activityinstances as follows: for each termination eventof a there is a subset of enable events of b and c.In general, for each termination event of a therecan be enable events for any subset of activityinstances on the outgoing branches of the split.

18

19

Or Join

• An or join is a point in a process model wheremultiple threads of control converge into onesingle thread. It is an assumption of thispattern that a branch that has already beenactivated cannot be activated again while themerge is still waiting for other branches tocomplete.

• The or join is a problematic control flowpattern. The problem is that the join cannotlocally decide how long to wait for itsactivation.

20

Page 6: Chapter 4 "Process Orchestrations"

3/26/2013

6

• Even from the simple process model fragment shownin Figure 4.9, this problem can be explained: once oneincoming branch is triggered, for instance, bytermination of b, how should the or join react? Thereare two options:– Wait: The or join waits before the activity instance d is

triggered, because the other incoming path—whichcompletes in activity instance c—can still be executed.

– Trigger : The or join triggers d immediately after thetermination of b.

• The problem is that we cannot decide which of thesealternatives the correct one is. After the first incomingbranch has terminated, how long should the or joinwait for the other branch to complete? If no additionalknowledge is available, there is no way of decidingwhether c will eventually terminate for the particularprocess instance. Since there is

21 22

Multiple Merge

• A multiple merge or multi-merge is a point in aprocess model where two or more concurrentthreads join without synchronization. The activityfollowing the merge is started for every activationof every incoming branch.

• The multi-merge is functionally equivalent withthe exclusive or join; the only difference is thatthe latter assumes that only one of its incomingbranches gets activated. This assumption is not inplace for the multi-merge pattern.

23 24

Page 7: Chapter 4 "Process Orchestrations"

3/26/2013

7

• The multiple merge pattern spawns off new threads ofcontrol. These threads need to be identified so thatfuture joins can be realized properly. These aspects areillustrated in an example shown in Figure 4.11, where aprocess model with an and split followed by a multi-merge is shown. As a result, any of the threads inducedby the and split will survive the multiple merge andspawn a new instance for activity model D and of theactivity models following D in the process model.

• Each of the threads of control spawned off by themulti-merge is subject to the and split/and join shownin the process model. The and join requiresinformation on the identity of the threads that comein; otherwise, situations could arise in which activityinstances that belong to different threads of control aresynchronized. These issues can be illustrated by theevent diagram

25 26

Discriminator

• The discriminator is a point in a process modelthat waits for one of the incoming branches tocomplete before activating the subsequentactivity. From that moment on it waits for allremaining branches to complete and “ignores”them. Once all incoming branches have beentriggered, it resets itself so that it can betriggered again. This allows a discriminator tobe used in the context of a loop.

27 28

Page 8: Chapter 4 "Process Orchestrations"

3/26/2013

8

• An example involving the discriminator pattern isshown in Figure 4.14. The process starts withactivity instance a before an and split occurs thatspawns activity instances b1 and c1. Assuming b1terminates first, the discriminator fires andenables d1. When d1 terminates, assuming a newiteration of the loop is required, new activityinstances based on B and C are created.

29

These activity instances are b2 and c2. What is remarkablein this example is that there are two instances of activitymodel C active concurrently, assuming c1 has not yetterminated. Even if c2 terminates before c1, the semanticsof the discriminator makes sure that it can only fire andenable d2 after the first iteration has completed, i.e., onlyafter the remaining activity instance c1 has terminated. Ifthis I the case, the discriminator can fire a second time, toenable d2. The event diagram of this process instance isshown in Figur 4.15.

30

Arbitrary Cycles• An arbitrary cycle is a point in a process model

where one or more activities can be executedrepeatedly.

• An arbitrary cycle is graphically depicted in Figure4.17. In this example, a sequence consisting ofactivity models A, B, and C is iterated. Theiteration is represented by an exclusive or splitthat decides whether to iterate the cycle orwhether to leave it and continue with activityinstance d, associated with activity model D. Incase the loop is iterated, the exclusive or jointriggers another instance associated with activitymodel A.

31

A more complex example of a cycle involving the multi-merge pattern I shown in Figure 4.18. The problem inthis example is that the cycle enter one of twoconcurrent branches of an and split whose branchesare joined b a multi-merge

32

Page 9: Chapter 4 "Process Orchestrations"

3/26/2013

9

33

Deferred Choice

• Deferred choice is a state-based pattern.State-based patterns capture the implicitbehaviour of processes that is based not onthe current case but rather on theenvironment or other parts of the process.Some of the following patterns require theexistence of an external process thatrepresents the environment. This process isused as a source for external events.

34

• A deferred choice is a point in a process modelwhere one of several branches is chosen. Incontrast to the exclusive or split, the choice isnot made explicitly—for example, based ondata values or a user decision—but severalalternatives are offered to the environment.

• The environment activates one of thealternatives, and the other branches are thenwithdrawn. Because the choice is delayeduntil one of the alternative branches hasactually been started, the moment of choice isdeferred to a point in time that is as late aspossible

35 36

Page 10: Chapter 4 "Process Orchestrations"

3/26/2013

10

4.7 BUSINESS PROCESS MODELING NOTATION

37 38

39 40

Page 11: Chapter 4 "Process Orchestrations"

3/26/2013

11

41 42

43 44