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

N-out-of-M Join

The N-out-of-M join has M incoming branches, and the follow-up activity
is triggered once N branches have completed. This behaviour can in part be
expressed in YAWL by multiple instances, as shown in Figure 4.67. The idea
is to start M instances and to define a threshold of N instances, so once N
instances have completed, the multiple instances task completes.
While multiple instances can be used to represent an N-out-of-M join
with identical activities, this approach falls short of representing concurrent
branches comprised of different activities. Therefore, only a very specific type
of N-out-of-M join can be realized in YAWL using multiple instances. Hence,
the N-out-of-M join is not completely expressed, since it should be able to
synchronize different branches of a process and not only multiple instances of
a given task.

Multiple Instances Tasks

Yet Another Workflow Language is tailored towards supporting multiple instances
patterns. The multiple instances without synchronization pattern is
shown in Figure 4.68. In this example, A spawns two concurrent branches,
consisting of multiple instances of task B and a single instance of task C.
The multiple instances of task B are not synchronized, which means that
B cannot have outgoing edges, because outgoing edges would indicate that
the follow-up activity can only be started if the task instances of task B have
completed.
The multiple instances with design time knowledge is shown in Figure 4.69.
In this pattern, the number of instances of task B is known at design time.
Therefore, the multiple instances attributes of task B can be set accordingly.
By setting the minimum number of instances, the maximum number of
instances, and the threshold to n, where n is the number of required instances
of task B, this pattern can be realized. The control flow edge from B to C
indicates that C can only start when all instances of task B have completed.
If the number of instances is known only at run time, but before the first instance
of B starts, a function is required to determine the number of instances
of B, as shown in Figure 4.70. This difference with the previous pattern is reflected
by using q for the number of instances, where q is determined at run time of the process instance, but before the start of multiple instances task
B. For example, the number of line items in an order can be determined at
run time. In the example, q reflects this number, so that exactly q instances
of task B are performed.
Figure 4.71 shows multiple instances without a priori run time knowledge.
In this pattern, the number of instances of B becomes available only while
instances of task B run. This means that new instances of B need to be
created dynamically. Parameters q1 and q2, and also the threshold value, can
be subject to change while task instances run, providing maximum flexibility
in determining the number of instances of a multiple instances task.

Discussion
Yet Another Workflow Language has a number of advantages, but also some
drawbacks. The graphical representation of process models is closely related to workflow nets, so that people familiar with workflow nets can use YAWL
immediately.
The execution semantics of YAWL is well-specified by state transition
systems. The representation of executing tasks by state transition systems
combines state transition diagrams—to describe the dynamic behaviour of
process activities, as shown in Figure 3.10—with Petri net markings.
One of the conceptual issues when representing business process activities
by Petri nets is the timeliness of the transition firing. Business process activities
take time, they have a start, they are active for a time interval, before
they complete. In contrast to Petri nets, the durations of process activities
are well captured by state transition systems in YAWL. At the same time,
process instances are represented by tokens, similar to markings in Petri nets.
YAWL has excellent support for multiple instances patterns. The specification
of multiple instances actually goes one step ahead of the control flow
patterns in that it allows us to define a threshold of completed task instances.
The construct to model multiple instances tasks in YAWL is very useful and
has many applications in real-world business processes.
The semantics of multiple instances tasks is handled very well by state
transition systems in YAWL. The add transition allows the dynamic creation
of new task instances while task instances are active; the exit transition can
realize the threshold semantics by cancelling all remaining task instances when
the threshold number of completed instances has been reached.
The state transition systems also capture in a very elegant way composite
tasks. By recursively applying the concept, subprocesses can easily be attached
to composite tasks. The multiple-instances property is orthogonal to
tasks being composite, so that any composite task can at the same time have
multiple instances.
The remove function rem associated to tasks allows us defining regions
of the workflow specification from where to withdraw tokens when the task
completes. Conceptually it is rather simple to “remove tokens” from process
instances to cancel tasks. It becomes much harder, however, when we look at
the concrete realization of these tasks.
In real-world business processes, many tasks are realized by software systems.
Removing a token from a task means to cancel the invocation of the
system. If the software system has transactional capabilities then the transaction
can be aborted, rolling back the software system to a consistent state.
Not all software systems used in business processes are, however, are transactional. In this case, the software might have already performed its work
partially at the time, the token is removed. In such situations, it is unclear,
how the business process management system should behave. In many cases,
human involvement is required to solve the resulting problems manually.
We have already discussed in some detail the weaknesses of YAWL in
representing some advanced control flow patterns, including the discriminator
and the M-out-of-N join. Despite these drawbacks, YAWL is a well-designed
process modelling language that also comes with prototypical implementations
for modelling and enactment, as referenced in the bibliographical notes.