A Process can also be started via 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 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.

13.5.2 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. For catch Message Intermediate Events, the Message correlation behavior is the same as for Receive Tasks (see sub clause 13.3.3).

13.5.3 Intermediate Boundary Events

For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event. For boundary Message Intermediate Events, the Message correlation behavior is the same as for Receive Tasks (see sub clause 13.3.3).

13.5.4 Event Sub-Processes

Event Sub-Processes allow to handle an Event within the context of a given Sub-Processes or Process. An

Event Sub-Process always begins with a Start Event, followed by Sequence Flows. Event Sub-Processes are a special kind of Sub-Process: they create a scope and are instantiated like a Sub-Process, but they are not instantiated by normal control flow but only when the associated Start Event is triggered. Event Sub-Processes are self-contained and MUST not be connected to the rest of the Sequence Flows in the Sub-Processes; also they cannot have attached boundary Events. They run in the context of the Sub-Process, and thus have access to its context.

An Event Sub-Process cancels execution of the enclosing Sub-Process, if the isInterrupting attribute of its Start Event is set; for a multi-instance Activity this cancels only the affected instance. If the isInterrupting attribute is not set (not possible for Error Event Sub-Processes), execution of the enclosing Sub-Process continues in parallel to the Event Sub-Process.

An Event Sub-Process can optionally re-trigger the Event through which it was triggered, to cause its continuation outside the boundary of the associated Sub-Process. In that case the Event Sub-Process is performed when the Event occurs; then control passes to the boundary Event, possibly canceling the Sub-Process (including running handlers).

Operational semantics

An Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The Event Handler MAY only be initiated after the parent Activity is Running.

440

Business Process Model and Notation (BPMN), v2.0.2