Within these three types, Events come in two flavors:

1.Events that catch a trigger. All Start Events and some Intermediate Events are catching Events.

2.Events that throw a Result. All End Events and some Intermediate Events are throwing Events that MAY eventually be caught by another Event. Typically the trigger carries information out of the scope where the throw Event occurred into the scope of the catching Events. The throwing of a trigger MAY be either implicit as defined by this standard or an extension to it or explicit by a throw Event.

Figure 10.69 – The Event Class Diagram

10.5.1 Concepts

Depending on the type of the Event there are different strategies to forward the trigger to catching Events: publication, direct resolution, propagation, cancellations, and compensations.

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

233

With publication a trigger MAY be received by any catching Events in any scope of the system where the trigger is published. Events for which publication is used are grouped to Conversations. Published Events MAY participate in several Conversations. Messages are triggers, which are generated outside of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance. Signals are triggers generated in the Pool they are published. They are typically used for broadcast communication within and across Processes, across Pools, and between Process diagrams.

Timer and Conditional triggers are implicitly thrown. When they are activated they wait for a time based or status based condition respectively to trigger the catch Event.

A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger. Error triggers are critical and suspend execution at the location of throwing. Escalations are non critical and execution continues at the location of throwing. If no catching Event is found for an error or escalation trigger, this trigger is unresolved. Termination, compensation, and cancellation are directed towards a Process or a specific Activity instance. Termination indicates that all Activities in the Process or Activity should be immediately ended. This includes all instances of multi-instances. It is ended without compensation or Event handling.

Compensation of a successfully completed Activity triggers its compensation handler. The compensation handler is either user defined or implicit. The implicit compensation handler of a Sub Process calls all compensation handlers of its enclosed Activities in the reverse order of Sequence Flow dependencies. If compensation is invoked for an Activity that has not yet completed, or has not completed successfully, nothing happens (in particular, no error is raised).

Cancellation will terminate all running Activities and compensate all successfully completed Activities in the SubProcess it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back.

Data Modeling and Events

Some Events (like the Message, Escalation, Error, Signal, and Multiple Event) have the capability to carry data. Data Association is used to push data from a Catch Event to a data element. For such Events, the following constraints apply:

If the Event is associated with multiple EventDefinitions, there MUST be one Data Input (in the case of throw Events) or one Data Output (in the case of catch Events) for each EventDefinition. The order of the EventDefinitions and the order of the Data Inputs/Outputs determine which Data Input/Output corresponds with which EventDefinition.

For each EventDefinition and Data Input/Output pair, if the Data Input/Output is present, it MUST have an ItemDefinition equivalent to the one defined by the Message, Escalation, Error, or Signal on the associated EventDefinition. In the case of a throw Event, if the Data Input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a catch Event, if the Data Output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the Event and into the Process.

The execution behavior is then as follows:

For throw Events: When the Event is activated, the data in the Data Input is assigned automatically to the Message, Escalation, Error, or Signal referenced by the corresponding EventDefinition.

For catch Events: When the trigger of the Event occurs (for example, the Message is received), the data is assigned automatically to the Data Output that corresponds to the EventDefinition that described that trigger.

234

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

Common Event attributes

The Event element inherits the attributes and model associations of FlowElement (see Table 8.44). Table 10.81 presents the additional model associations of the Event element.

Table 10.81 – Event model associations

Attribute Name

Description/Usage

 

 

properties: Property [0..*]

Modeler-defined properties MAY be added to an Event. These

 

properties are contained within the Event.

Common Catch Event attributes

The CatchEvent element inherits the attributes and model associations of Event element (see Table 10.81). Table 10.82 presents the additional attributes and model associations of the CatchEvent element.

Table 10.82 – CatchEvent attributes and model associations

Attribute Name

Description/Usage

 

 

eventDefinitionRefs: EventDefinition [0..*]

References the reusable EventDefinitions that are triggers

 

expected for a catch Event. Reusable EventDefinitions are

 

defined as top-level elements. These EventDefinitions can be

 

shared by different catch and throw Events.

 

If there is no EventDefinition defined, then this is

 

considered a catch None Event and the Event will not have

 

an internal marker (see Figure 10.91).

 

If there is more than one EventDefinition defined, this is

 

considered a Catch Multiple Event and the Event will have

 

the pentagon internal marker (see Figure 10.90).

 

This is an ordered set.

 

 

eventDefinitions: EventDefinition [0..*]

Defines the event EventDefinitions that are triggers expected

 

for a catch Event. These EventDefinitions are only valid inside

 

the current Event.

 

If there is no EventDefinition defined, then this is

 

considered a catch None Event and the Event will not have an

 

internal marker (see Figure 10.91).

 

If there is more than one EventDefinition defined, this is

 

considered a catch Multiple Event and the Event will have the

 

pentagon internal marker (see Figure 10.90).

 

This is an ordered set.

 

 

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

235

Table 10.82 – CatchEvent attributes and model associations

dataOutputAssociations: Data

The Data Associations of the catch Event.

OutputAssociation [0..*]

The dataOutputAssociation of a catch Event is used to assign

 

data from the Event to a data element that is in the scope of the

 

Event.

 

For a catch Multiple Event, multiple Data Associations might be

 

REQUIRED, depending on the individual triggers of the Event.

 

 

dataOutputs: DataOutput [0..*]

The Data Outputs for the catch Event. This is an ordered set.

 

 

outputSet: OutputSet [0..1]

The OutputSet for the catch Event.

 

parallelMultiple: boolean = false

This attribute is only relevant when the catch Event has more

 

than EventDefinition (Multiple).

 

If this value is true, then all of the types of triggers that are

 

listed in the catch Event MUST be triggered before the Process

 

is instantiated.

 

 

Common Throw Event Attributes

The ThrowEvent element inherits the attributes and model associations of Event element (see Table 10.81). Table 10.83 presents the additional attributes and model associations of the ThrowEvent element.

Table 10.83 – ThrowEvent attributes and model associations

Attribute Name

Description/Usage

 

 

eventDefinitionRefs: EventDefinition [0..*]

References the reusable EventDefinitions that are results

 

expected for a throw Event. Reusable EventDefinitions are

 

defined as top-level elements. These EventDefinitions can be

 

shared by different catch and throw Events.

 

• If there is no EventDefinition defined, then this is considered a

 

throw None Event and the Event will not have an internal marker

 

(see Figure 10.91 ).

 

• If there is more than one EventDefinition defined, this is

 

considered a throw Multiple Event and the Event will have the

 

pentagon internal marker (see Figure 10.90 ).

 

This is an ordered set.

 

 

236

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