Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec C -- By Mathias Weske

Multiple Merge

A multiple merge or multi-merge is a point in a process model where two or
more concurrent threads join without synchronization. The activity following
the merge is started for every activation of every incoming branch.
The multi-merge is functionally equivalent with the exclusive or join; the
only difference is that the latter assumes that only one of its incoming branches
gets activated. This assumption is not in place for the multi-merge pattern.
A process model with activity models B, C, and D, and a gateway G
such that E  {(B,G), (C,G), (G,D)} and type(G) = MultiMerge.
For each terminating activity instance b and c, one activity
instance associated with activity model D is started. This means that for each
termination event ti 2 Ep, where i 2 {b, c}, there is an enable event ed that
occurs after the respective termination event, i.e., ti < ed, i 2 {b, c}.
The multiple merge pattern spawns off new threads of control. These
threads need to be identified so that future joins can be realized properly.
These aspects are illustrated in an example shown in Figure 4.11, where a
process model with an and split followed by a multi-merge is shown. As a
result, any of the threads induced by the and split will survive the multiple
merge and spawn a new instance for activity model D and of the activity
models following D in the process model.
Each of the threads of control spawned off by the multi-merge is subject
to the and split/and join shown in the process model. The and join requires
information on the identity of the threads that come in; otherwise, situations
could arise in which activity instances that belong to different threads of
control are synchronized. These issues can be illustrated by the event diagram This diagram can be considered an abstract form of an
event diagram in which the lifetime of each activity instance is shown as a line
with borders marking the enabling and terminating of the activity instance.
The process starts with activity instance a, followed by the concurrent
execution of b and c. Assuming b terminates before c does, the multi-merge
spawns off a new thread of control, called thread The first
activity instance of this thread is d1.
While d1 is still running, c terminates, and the multi-merge spawns off
thread 2, starting with d2. When d1 completes, the and split occurs, and
concurrent threads are created, realized by activity instances e1 and f1.
After d2 terminates, e2 and f2 are created. Assuming that f1 and e2 terminate,
the and join faces a situation in which there are termination events of
activity instances on its incoming edges. Knowing that these belong to different
threads of control (f1 belongs to thread 1, while e2 belongs to thread 2),
the and join can “decide” that these threads cannot be synchronized, although
they belong to the same process instances.