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

and that “The performers determine when activities will start, when they will end, what the next
activity will be, and so on”. The classification into sequential and parallel adHocOrder seems to
disappear in this interpretation, in which any behavior one can imagine could be inserted. We
have difficulties to believe that such a completely non-deterministic understanding is intended as
BPMN standard conform. To clarify what the issue is about, we rewrite the transition rule for adhoc
processes by explicitly stating that as long as AdHocCompletionCond is not yet true, repeatedly a
multi-set of inner activities can be chosen and executed until completion. The fact that the choice
happens in a non-deterministic manner, which will only be defined by the implementation or at
runtime, is made explicit by using the choose construct for ASMs (see Sect. 10 for an explanation).
We use A ⊆ multi B to denote that A is a multi-set of elements from B.
UnconstrainedAdHocTransition(node) = [if Enabled(in) then]
let t = firingToken(in)
[Consume(t, in)]
[let i = select InputSets (SomeAvail(inputSets(node)))
currInput(node) := i]
while not AdHocCompletionCond(node, t)
choose A ⊆ multi innerAct(node)
forall a ∈ A do a[inputs(i)]
seq LoopExit(node, t)
where Completed(node, t) = AdHocCompletionCond(node, t)
Many issues remain open with such an interpretation. For example, can an activity within an
ad hod embedded subprocess be transactional? Can it be an iteration? What happens if during
one execution round for a chosen subset A of embedded activities one of these throws an exception
that cannot be caught within the embedded activity itself? Can ad hod subprocesses be nested?
If yes, how are exceptions and transactional requirements combined with nesting? Etc.
6.3 Subprocess Nodes
The main role of subprocesses is to represent modularization techniques. Their role in creating an
EventContext for exception handling, cancellation and compensation has already been described
above when formalizing the behavior of intermediate events that are placed on the boundary of
an activity. Their role in showing parallel activities has been dealt with by the description of iterative
(in particular adhoc) processes. The normal sequence flow of their inner activities is already
formalized by the preceding description of the behavior of tasks, events and gateways, using that
subprocess activities in BPMN have the same sequence flow connections as task activities. What
remains to be described is their role when calling an activity, which may involve an instantiation
and passing data from caller to callee, and when coming back from an activity.
For the discussion of calling and returning from subprocesses we can start from the BPMN Best
Practice Normal Form assumption as made for tasks, namely that there is (at most) one incoming
and (at most) one outgoing arc. For calling a subprocess we can assume that when an arc incoming
a subprocess is enabled, the start event of the process if triggered. This stipulation comes up to
be part of the definition of the Triggered predicate for such start events, where we assume for
the token model that the event type is Link and that startToken con veys the token information
related to this link to the the token created when the subprocess starts. If there is no incoming
arc, then the standard stipulation is that the subprocess (if it is not a compensation) is enabled
when its parent process is enabled. We can include this into the description of the previous case
by considering that there is a special virtual arc in our graph representation that leads from the
parent process to each of its (parallel) subprocesses. We have dealt in a similar way with returning
from a subprocess via end events, which bring the sequence flow back to the parent process (see the
definition of EmitResult for end events in Sect. 5). This is in accordance with the illustrations
in [15, Fig.10.14-16 p.108-110] for dealing with start/end events that are attached to the boundary
of an expanded subprocess (see also the characteristic example in [15, Fig.10.48 p.127]).
30