If the inline Event Sub-Process completes without “re-throwing” the Event, the Activity is considered to have completed and normal Sequence Flow resumes. In other terms, the Event Sub-Process “absorbs” the

Event.

Interrupting Event Handlers (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)

Interrupting Event Handlers are those that have the cancelActivity attribute is set to true. Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is interrupted. If an inline error handler is specified (in case of a Sub-Process), it is run within the context of that Sub-Process. If a boundary Error Event is present, Sequence Flows from that boundary Event are then followed. The parent Activity is canceled after either the error handler completes or Sequence Flow from the boundary Event is followed.

In the example above, the “Booking” Sub-Process has an Error handler that defines what should happen in case a “Booking” Error occurs within the Sub-Process, namely, the already performed bookings are canceled using compensation. The Error handler is then continued outside the Sub-Process through a boundary Error Event.

Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)

Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.

For Event Sub-Processes, whenever the Event occurs it is consumed and the associated Event Sub-Process is performed. If there are several Events that happen in parallel, then they are handled concurrently, i.e., several Event Sub-Process instances are created concurrently. The non-interrupting Start Event indicates that the Event SubProcess instance runs concurrently to the Sub-Process proper.

For boundary Events, whenever the Event occurs the handler runs concurrently to the Activity. If an Event SubProcess is also specified for that Event (in case of a Sub-Process), it is run within the context of that Sub-Process. Then, Sequence Flows from the boundary Event are followed. 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.

In the example above, an Event Handler allows to update the credit card information during the “Booking” SubProcess. It is triggered by a credit card information Message: such a Message can be received whenever the control flow is within the main body of the Sub-Process. Once such a Message is received, the Activities within the corresponding Event Handler run concurrently with the Activities within the body of the Sub-Process.

See “Intermediate Events” on page 440 for the exact semantics of boundary Intermediate Events and “Event SubProcesses” on page 440 for the operational semantics of non-interrupting Event Sub-Processes.

Handling End Events

For a Terminate End Event, all remaining active Activities within the Process are terminated.

A Cancel End Event is only allowed in the context of a Transaction Sub-Process and, as such, cancels the SubProcess and aborts an associated Transaction of the Sub-Process.

For all other End Events, the behavior associated with the EventDefinition is performed. When there are no further active Activities, then the Sub-Process or Process instance is completed. See page 443 for exact semantics.