BPMN non-interrupting exception flow

Question

While working on a BPMN model, we encountered an issue concerning exception flows. Whenever an exception flow was needed, we gave it its own end event. Although BPMN recommend using gateways to merge normal flow with exception flow. I can see no advantage in doing so, only some additional complications.

However, consider the case in which we have a subprocess with an activity X and an attached-to-boundary non-interrupting event. When triggered, a parallel token will be created and put on the branch of the exception flow. After running through exception flow, an end event consumes this token.

I assume this consumption doesn't trigger the upper-level flow(the one containing this particular subprocess) to continue, as there still is a token left in activity X. As this activity is ended and normal flow is executed , this token is consumed as well and the subprocess doesn't contain any token. This will trigger the upper-level flow to continue. As this is the case, I can't think of any case where the merger of exception flow and normal flow should be necessary. (Except for the one where activities after activity x have to be run in exception flow as well, causing them to be executed multiple times).

Answer 1

I assume this consumption doesn't trigger the upper-level flow(the one containing this particular subprocess) to continue, as there still is a token left in activity X.

This is an accurate statement; the following models have identical semantics (the non-interrupting multiple event trigger is used as a placeholder):

The governing section in the BPMN specification is Section 10.5.3, which requires that "all the tokens that were generated within the process MUST be consumed by an End Event before the Process has been completed."

As this is the case, I can't think of any case where the merger of exception flow and normal flow should be necessary.

One case where the merger may be necessary occurs when the two flows must be merged before a task later in the process can commence. As a simple example, take the following models:

In the model at top, Activity Y may commence as soon as Activity X completes, regardless of whether there are instances of Exceptional activity running in parallel. In the model at bottom, Activity Y cannot start until all instances (if any) of Exceptional activity have completed. If the semantics of the second example are wanted, then a merger of the normal and exception flows are needed.

Answer 2

The last diagram is not inaccurate and, effectively, invalid.

By definition, the exceptional flow cannot form part of the smooth flow. By definition, the exceptional flow cannot be evaluated using IF.

The final diagram (erroneously) introduces a gateway which will, eventually receive two tokens and (erroneously) trigger activity Y, twice.

I would suggest that the language is wrong - IF the exceptional flow must be complete before Y triggers, the author has described an INTERRUPTING BOUNDARY EVENT. Depicting that event solves the modelling problem introduced by poor grammar. Only one token is produced and activity Y is triggered, only once.