Page 361 -

13 The Business Process Modeling Notation 359
This way of mapping events works well for intermediate message/timer events
and for final message/timer events. But it does not work for start events. Start mes-
sage/timer events in BPMN have the effect of creating new process instances. For
example, a start message event in BPMN means that a new instance of a process
is created every time a message (of the designated type) is received. This feature
is called implicit instantiation – because a process instance is created when a given
type of event happens. Meanwhile, YAWL supports explicit instantiation, mean-
ing that to create an instance of a YAWL net, an external application needs to send a
“create instance” message to the process engine with the corresponding net identifier
and the required input data.
From an application development perspective, the above difference is rather
minor. It mainly implies that in YAWL, one has to follow a strict separation between
the instantiation of a net and the net itself. For example, if we wanted to create
an instance of a YAWL net every time an invoice is received, or every Saturday
at 2 am, we would need to develop an application that receives the invoice mes-
sage or that is triggered every Saturday at 2 am. This application would then send a
“create instance” message to the Engine to start the execution of the corresponding
YAWL net.
A BPMN diagram may have multiple start events, in which case at least one of
these events must have a trigger (e.g., message/timer) event. This situation cannot
be captured directly in YAWL because YAWL supports only plain start events (i.e.,
explicit instantiation). As there is only one way of creating an instance of a YAWL
net, it is natural that YAWL nets only have one start (input) condition.
Similarly, a BPMN diagram may have multiple end events, while a YAWL net
always has a single final (output) condition. Also, the termination policy of end
events in YAWL is such that when a token reaches the output condition, the pro-
cess instance immediately completes, even if there are still active or enabled tasks.
Meanwhile, if the execution of a branch in a BPMN diagram reaches an end event,
but there are other enabled or active tasks, the process instance does not termi-
nate immediately (implicit termination policy). For BPMN diagrams that are 1-safe,
meaning that no two tokens can accumulate in the same flow, this is not a limita-
tion. Such models can be translated into YAWL by mapping all the final flows to
YAWL arcs that lead to a single empty task with an OR-join. This empty task with
an OR-join is then connected to the single output condition in YAWL. The OR-join
waits for at least one token in each branch (except for branches that need not wait
for tokens) before producing one token in the output condition. This transformation
is illustrated in Fig. 13.11.

Multiple Instance Tasks

As shown in Fig. 13.9, a multiple instance task in BPMN is mapped into a multiple
instance task in YAWL – and similarly, a multiple instance subprocess invocation
in BPMN is mapped to a multiple instance composite task in YAWL. In BPMN,
any number of instances of a multiple instance activity may be started (without