BPMN and Beyond Business process modelling notation, workflow ...

elow, an instance of WorkflowTransition(node) where data and control conditions and data
operations are set to empty since they are unrelated to how start events are defined in BPMN.
By trigger(node) we indicate the set of types of (possibly multiple) event triggers that may
be associated to node, each single one of which can be one of the following: a message, a timer, a
condition (in the BPMN document termed a rule), a link or none. The BPMN standard document
leaves it open how to choose a single one out of a multiple event associated to a node in case two
or more events are triggered there simultaneously. This means that the non-deterministic choice
behavior is not furthermore constrained, so that we use the ASM choose operator to select a single
event trigger and thereby a rule StartEventTransition(node, e) for execution, each of which
is parameterized by a particular event e ∈ trigger(node). 19 This reflects the standard requirement
that “Each Start Event is an independent event. That is, a Process Instance SHALL be generated
when the Start Event is triggered.” [15, p.36] 20
StartEventTransition(node) =
choose e ∈ trigger(node) StartEventTransition(node, e)
By the best practice normal form we can assume that there is exactly one outgoing arc out,
namely after replacing possibly multiple outgoing arcs by one outging arc, which enters an andsplit
gateway with multiple outgoing arcs. This captures that by the BPMN standard document
“Multiple Sequence Flow MAY originate from a Start Event. For each Sequence Flow that has
the Start Event as a source, a new parallel path SHALL be generated . . . Each path will have a
separate unique Token that will traverse the Sequence Flow.” [15, Sect.9.3.2 p.38-39] Therefore a
StartEventTransition(node, e) rule fires when the EventCond(node) is true that e is Triggered.
It yields as event EventOp(node, e) to ConsumEvent(e) and
StartEventTransition(node, e) rule yields as CtlOp(node) to Produce a startToken on
out. The produced token is supposed to contain the information needed for “tracking the path(s) of
the Token through the Process” [15, p.35]. Since this information is not furthermore specified by the
standard document, in our model it is kept abstract in terms of an abstract function startToken(e).
Traditionally it is supposed to contain at least an identifier for the just startede process instance.
StartEventTransition(node, e) =
if Triggered(e) then Produce(startToken(e), out)
ConsumEvent(e)
Remark to event consumption in the start rule. If the intention of the standard document
is that not only the chosen triggered event but all triggered events are consumed, it suffices to
replace ConsumEvent(e) by the following rule:
forall e ′ ∈ trigger(node) if Triggered(e ′ ) then ConsumEvent(e ′ )
.
The definition of Triggered(e) is given by Table 9.4 in [15].
The submachine ConsumEvent(e) is defined depending on the type of event e. Messages and
timers represent (values of) monitored locations with a predetermined consumption procedure.
The standard document leaves it open whether upon firing a transition triggered by an incoming
message, that message is consumed or not. 21 Similarly it is not specified whether a timer event is
automatically consumed once its time has passed (precisely or with some delay). Therefore for the
BPMN 1.0 standard, for these two cases the submachine ConsumEvent remains abstract, it has
to be specified by the intended consumption discipline of each system instance.
The same holds for events of type None or Rule.
19 An alternative would be to use a (possibly local and dynamic) selection function select Event which each
time chooses an event out of the set trigger(node).
20 See also the remark below.
21 This is an important issue to clarify, since a same message may be incoming to different events in a
diagram.
16