10.5.6 Handling Events

BPMN provides advanced constructs for dealing with Events that occur during the execution of a Process (i.e., the “catching” of an Event). Furthermore, BPMN supports the explicit creation of an Event in the Process (i.e., the “throwing” of an Event). Both catching and throwing of an Event as well as the resulting Process behavior is referred to as Event handling. There are three types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, and those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process.

Handling Start Events

There are multiple ways in which a Process can be started. For single Start Events, handling consists of starting a new Process instance each time the Event occurs. Sequence Flows leaving the Event are then followed as usual. For multiple Start Events, BPMN supports several modeling scenarios that can be applied depending on the scenario.

Exclusive start: the most common scenario for starting a Process is its instantiation by exactly one out of many possible Start Events. Each occurrence of one of these Events will lead to the creation of a new Process instance. The following example shows two Events connected to a single Activity (see Figure 10.97). At runtime, each occurrence of one of the Events will lead to the creation of a new instance of the Process instance and activation of the Activity. Note that a single Multiple Start Event that contains the Message Event Definitions would behave in the same way.

Message 1

Activity

Message 2

Figure 10.97 – Exclusive start of a Process

A Process can also be started via an Event-Based Gateway, as in the following example (Figure 10.98).

P a rs e E -M a il

H a n d le S M S

Figure 10.98 – A Process initiated by an Event-Based Gateway

In that case, the first matching Event will create a new instance of the Process, and waiting for the other Events originating from the same decision stops, following the usual semantics of the Event-Based Exclusive Gateway. Note that this is the only scenario where a Gateway can exist without an incoming Sequence Flows.

It is possible to have multiple groups of Event-Based Gateways starting a Process, provided they participate in the same Conversation and hence share the same correlation information. In that case, one Event out of each group needs to arrive; the first one creates a new Process instance, while the subsequent ones are routed to the existing instance, which is identified through its correlation information.

Event synchronization: if the modeler requires several disjoint Start Events to be merged into a single Process instance, then the following notation MUST be applied (Figure 10.99).

Activity

Figure 10.99 – Event synchronization at Process start

The Parallel Start Event MAY group several disjoint Start Events each of which MUST occur once in order for an instance of the Process to be created. Sequence Flows leaving the Event are then followed as usual.

See page 440 for the execution semantics for the Event Handling of Start Events.

Handling Events within normal Sequence Flow (Intermediate Events)

For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flows leaving the Event are followed as usual.

Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes)

For boundary Events, handling consists of consuming the Event occurrence and either canceling the Activity the Event is attached to, followed by normal Sequence Flows leaving that Activity, or by running an Event Handler without canceling the Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).

An interrupting boundary Event is defined by a true value of its cancelActivity attribute. Whenever the Event occurs, the associated Activity is terminated. A downstream token is then generated, which activates the next element of the Process (connected to the Event by an unconditional Sequence Flow called an exception flow).

For non-interrupting boundary Events, the cancelActivity attribute is set to false. Whenever the Event occurs, the associated Activity continues to be active. As a token is generated for the Sequence Flow from the boundary Event in parallel to the continuing execution of the Activity, care MUST be taken when this flow is merged into the main flow of the Process – typically it should be ended with its own End Event.

The following example shows a fragment (see Figure 10.100) from a trip booking Process. It contains a Sub-Process that consists of a main part, and three Event Sub-Processes to deal with Events within the same context: an error

Event Sub-Process that cancels the Sub-Process, a Message Event Sub-Process that updates the state of the Sub-Process while allowing it to continue, and a Compensation Event Sub-Process.

Figure 10.100 – Example of inline Event Handling via Event Sub-Processes

The following example (see Figure 10.101) shows the same fragment of that Process, using boundary Event handlers rather than inline Event Sub-Processes. Note that in this example, the handlers do not have access to the context of the “Booking” Sub-Process, as they run outside of it. Therefore, the actually compensation logic is shown as a black box.

Figure 10.101 – Example of boundary Event Handling

Note that there is a distinction between interrupting and non-interrupting Events and the handling of these Events, which is described in the sub clauses below. For an interrupting Event (Error, Escalation, Message, Signal, Timer,

Conditional, Multiple, and Parallel Multiple), only one Event Sub-Process for the same Event Declaration MUST be modeled. This excludes any further non-interrupting handlers for that Event Declaration.

The reason for this restriction lies in the nature of interrupting Event Sub-Processes and boundary Events. They interrupt normal execution of the parent Activity and after their completion, the parent Activity is immediately terminated. This implies that only one such handler can be executed at a time. However, this does not restrict the modeler in specifying several interrupting handlers, if each handler refers to a different Event Declaration.

For non-interrupting Events (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple), an unlimited number of Event Sub-Processes for the same Event Declaration can be modeled and executed in parallel. At runtime, they will be invoked in a non-deterministic order. The same restrictions apply for boundary Events. During execution of a non-interrupting Event Sub-Process, execution of the parent Activity continues as normal.

If for a given Sub-Process, both an inline Event Sub-Process and a boundary Event handler are modeled that Process the same EventDefinition, the following semantics apply:

If the inline Event Sub-Process “re-throws” the Event after completion, the boundary Event is triggered.