A.7. Event Types

Events are triggers, which when occur, impact a business process. Events are classified as start events, end events, and intermediate events. A start event indicates the beginning of a business process. An end event indicates the completion of a business process. And intermediate events drive the flow of a business process. Every event has an event ID and a name. You can implement triggers for each of these event types to identify the conditions under which an event is triggered. If the conditions of the triggers are not met, the events are not initialized, and hence the process flow does not complete.

A.7.1. Start Event

A Start Event is a modeling element that indicates where a particular Process workflow starts. Every Process must have at least one Start Event. Every Start Event has no incoming and exactly one outgoing Flow. When the parent Process is instantiated and started, the Start Event is executed and the node's outgoing Flow is taken.
Multiple Start Event types are supported:
  • None Start Event
  • Signal Start Event
  • Timer Start Event
  • Conditional Start Event
  • Message Start Event
  • Compensation Start Event
All but the None Start Event, must define a certain trigger type: when a Process instance is started, the trigger needs to be fulfilled before the outgoing flow can be taken. If no Start Event can be triggered, the Process is never instantiated.

A.7.1.1. Start Event types

A.7.1.1.1. None Start Event
The None Start Event is a Start Event without a trigger condition.
A Process or Sub-Process can contain at most one None Start Event, which is triggered on Process or Sub-Process start by default and the outgoing flow is taken immediately.
When used in a Sub-Process, the execution is transferred from the parent Process into the Sub-Process and the None Start Event is triggered (the token is taken from the parent Sub-Process Activity and the None Start Event of the Sub-Process generates a token).
A.7.1.1.2. Message Start Event
A Process or an Event Sub-Process can contain multiple Message Start Events, which are triggered when triggered by a particular Message. The Process instance with a Message Start Event only starts its execution from this event after it has received the respective Message: The Process is instantiated and its Message Start Event is executed immediately (its outgoing Flow is taken).
As a Message can be consumed by an arbitrary number of Processes and Process elements, including no Elements, one Message can trigger multiple Message Start Events and therefore instantiate multiple Processes.
Attributes
Message
ID of the expected Message object
A.7.1.1.3. Timer Start Event
The Timer Start Event is a Start Event with a Timing definition (for details on Timing see Section A.5, “Timing”).
A Process can contain at multiple Timer Start Events, which is triggered on Process start by default and then the Timing is applied.
When used in a Sub-Process, the execution is transferred from the parent Process into the Sub-Process and the Timer Start Event is triggered: the token is taken from the parent Sub-Process Activity and the Timer Start Event of the Sub-Process is triggered and waits for the Timing to be fulfilled. Once the time defined by the Timing definition has been reached, the outgoing Flow is taken.
Attributes
Timer
Timing definition
A.7.1.1.4. Escalation Start Event
The Escalation Start Event is a Start Event that is triggered by an Escalation with a particular Escalation code (see Section A.3.2, “Escalation”).
Process can contain multiple Escalation Start Events. The Process instance with an Escalation Start Event only starts its execution from this event after it has received the respective Escalation object: The Process is instantiated and its Escalation Start Event is executed immediately (its outgoing Flow is taken).
Attributes
Escalation Code
Expected Escalation Code
A.7.1.1.5. Conditional Start Event
The Conditional Start Event is a Start Event with a Boolean condition definition. The Process execution with such a Start Event continues only if the condition is evaluated to true after the Start Event has been instantiated.
The execution is triggered always when the condition is evaluated to false and then to true.
A Process can contain at multiple Conditional Start Events.
Attributes
Condition
Boolean condition
A.7.1.1.6. Error Start Event
An Error Start Event can be used to start a Process or Sub-Process. These can contain multiple Error Start Events, which are triggered when an Error object with a particular ErrorRef is received. The Error object can be produced by an Error End Event and signalizes an incorrect Process ending. The Process instance with the Error Start Event starts execution after it has received the respective Error object so as to handle such incorrect ending: The Error Start Event is executed immediately (its outgoing Flow is taken).
Attributes
ErrorCode
code of the expected Error object
A.7.1.1.7. Compensation Start Event
A Compensation Start Event is used to start an Compensation Event Sub-Process when using a Sub-Process as the target Activity of a Compensation Intermediate Event.
A.7.1.1.8. Signal Start Event
The Signal Start Event is a Start Event that is triggered by a Signal with a particular Signal Code (see Section A.3.3, “Signals”).
Process can contain multiple Signal Start Events. The Signal Start Event only starts its execution within the Process instance after the instance has received the respective Signal: on Signal receving, the Signal Start Event is executed immediately (its outgoing Flow is taken).
Attributes
SignalCode
Expected Signal Code

A.7.2. Intermediate Events

A.7.2.1. Intermediate Events

“... the Intermediate Event indicates where something happens (an Event) somewhere between the start and end of a Process. It will affect the flow of the Process, but will not start or (directly) terminate the Process.[3]”
Intermediate Event handles a particular situation that occurs during Process execution. The situation is the trigger of the Intermediate Event.
In a Process, Intermediate Events can be placed as follows:
in a Process workflow with one optional incoming and one outgoing Flow:
The event is executed as part of the workflow. If the Event has no incoming Flow, its execution is triggered always when the respective trigger occurs during the entire Process instance execution. If the Event has an incoming Flow it is executed as part of the Process workflow. Once triggered, the Event's outgoing Flow is taken only after the respective Event has occurred.
on an Activity boundary with one outgoing Flow:
If the Event occurs while the Activity is being executed, the Event triggers its execution to the outgoing Flow. One Activity may have multiple boundary Intermediate Events. Note that depending on the behavior you require from the Activity with the boundary Intermediate Event, you can use either of the following Intermediate Event type:
  • interrupting: the Activity execution is interrupted and the execution of the Intermediate Event is triggered.
  • non-interrupting: the Intermediate Event is triggered and the Activity execution continues.
Based on the type of Event cause the execution of the Intermediate Event (triggers), the following Intermediate Events are distinguished:
Timer Intermediate Event
delays the execution of the outgoing Flow.
Conditional Intermediate Event
is triggered when its condition evaluates to true.
Error Intermediate Event
is triggered by an Error object with the given Error Code.
Escalation Intermediate Event
has two subtypes: Catching Escalation Intermediate Event that is triggered by a Escalation and Throwing Escalation Intermediate Event that produces an Escalation when executed.
Signal Intermediate Event
has two subtypes: Catching Signal Intermediate Event that is triggered by a Signal and Throwing Signal Intermediate Event that produces a Signal when executed.
Message Intermediate Event
has two subtypes: Catching Message Intermediate Event that is triggered by a Message and Throwing Message Intermediate Event that produces a Message when executed.

A.7.2.2. Intermediate Event types

A.7.2.2.1. None Intermediate Event
None Intermediate Event is an abstract Intermediate Event and displays all possible Intermediate Event properties.
A.7.2.2.2. Timer Intermediate Event
A Timer Intermediate Event allows you to delay further workflow execution or to trigger the workflow execution periodically. It represents a timer that can trigger one or multiple times after a given period of time: always when triggered the timer condition (the defined time) is checked and once the time event occurs, the outgoing Flow is taken.
The Event defines the Timer delay and Timer period properties, that use the Timing mechanism as described in Section A.5, “Timing”. When placed in the Process workflow, a Timer Intermediate Event has one incoming Flow and one outgoing Flow and its execution starts when the incoming Flow transfers to the Event. When placed on an Activity boundary, the execution is trigger at the same time as the Activity execution.
The timer is canceled if the timer element is canceled, for example, by completing or aborting the enclosing process instance).
Attributes
Message
ID of the expected Message object
Timer delay
Time delay before the Event triggers its outgoing Flow for the first time
Timer period
Period between two subsequent triggers
If set to 0, the Event execution is not repeated.
A.7.2.2.3. Conditional Intermediate Event
A Conditional Intermediate Event is an Intermediate Event with a boolean condition as its trigger. The Event triggers further workflow execution when the condition evaluates to true and its outgoing Flow is taken.
The Event must define its boolean Conditional. When placed in the Process workflow, a Conditional Intermediate Event has one incoming Flow and one outgoing Flow and its execution starts when the incoming Flow transfers to the Event. When placed on an Activity boundary, the execution is triggered at the same time as the Activity execution. Note, that if the Event is non-interrupting, the Event triggers continuously while the condition is true.
Attributes
Condition
Boolean condition that must be evaluated to true for the execution to continue
A.7.2.2.4. Message Intermediate Event
A Message Intermediate Event is an Intermediate Event that allows you to produce or consume a Message object. Depending on the action the event element is to perform, you need to use either of the following:
  • Throwing Message Intermediate Event produces a Message object based on the defined properties
  • Catching Message Intermediate Event listens for a Message object with the defined properties
A.7.2.2.5. Compensation Intermediate Event
A Compensation Intermediate Event is a boundary event that is attached to a Activity in a transaction Sub-Process that may finish with a Compensation End Event or a Cancel End Event. The Compensation Intermediate Event must have one outgoing Association Flow that connects to an Activity that defines the compensation action needed to compensate for the action performed by the Activity.
On runtime, if the transaction Sub-Process finishes with the Compensation End Event, the Activity associated with the boundary Compensation Intermediate Event is executed and the execution continues with the respective Flow leaving the transaction Sub-Process.
A.7.2.2.6. Message Intermediate Event types
A.7.2.2.6.1. Throwing Message Intermediate Event
When reached on execution, a Throwing Message Intermediate Event produces a Message and the excecution continues to its outgoing Flow.
Attributes
CancelActivity
if the Event is place on the boundary of an Activity and the Cancel Activity property is set to true, the Activity execution is cancelled immediately when the Event receives its Escalation object.
MessageRef
ID of the produced Message object
A.7.2.2.6.2. Catching Message Intermediate Event
When reached on execution, a Catching Message Intermediate Event awaits a Message defined in its properties. Once the Message is received, the Event triggers execution of its outgoing Flow.
Attributes
MessageRef
ID of the expected Message object
A.7.2.2.7. Escalation Intermediate Event
An Escalation Intermediate Event is an Intermediate Event that allows you to produce or consume an Escalation object. Depending on the action the event element is to perform, you need to use either of the following:
  • Throwing Escalation Intermediate Event produces an Escalation object based on the defined properties
  • Catching Escalation Intermediate Event listens for an Escalation object with the defined properties
A.7.2.2.8. Escalation Intermediate Event types
A.7.2.2.8.1. Throwing Escalation Intermediate Event
When reached on execution, a Throwing Escalation Intermediate Event produces an Escalation object and the excecution continues to its outgoing Flow.
Attributes
EscalationCode
ID of the produced Escalation object
A.7.2.2.8.2. Catching Escalation Intermediate Event
When reached on execution, a Catching Escalation Intermediate Event awaits an Escalation object defined in its properties. Once the object is received, the Event triggers execution of its outgoing Flow.
Attributes
EscalationCode
code of the expected Escalation object
CancelActivity
if the Event is place on the boundary of an Activity and the Cancel Activity property is set to true, the Activity execution is cancelled immediately when the Event receives its Escalation object.
A.7.2.2.9. Error Intermediate Event
An Error Intermediate Event is an Intermediate Event that can be used only on an Activity boundary. It allows the Process to react to an Error End Event in the respective Activity. The Activity must not be atomic. When the Activity finishes with an Error End Event that produces an Error with the respective ErrorCode, the Error Intermediate Event catches the Error object and execution continues to the outgoing Flow of the Error Intermediate Event.
Attributes
ErrorRef
reference number of the Error object the Event is listening for
A.7.2.2.10. Error Intermediate Event types
A.7.2.2.10.1. Throwing Error Intermediate Event
When reached on execution, a Throwing Error Intermediate Event produces an Error object and the excecution continues to its outgoing Flow.
Attributes
ErrorRef
reference number of the produced Error object
A.7.2.2.10.2. Catching Error Intermediate Event
When reached on execution, a Catching Error Intermediate Event awaits an Error object defined in its properties. Once the object is received, the Event triggers execution of its outgoing Flow.
Attributes
ErrorRef
reference number of the expected Error object
CancelActivity
if the Event is place on the boundary of an Activity and the Cancel Activity property is set to true, the Activity execution is cancelled immediately when the Event receives its Escalation object.
A.7.2.2.11. Signal Intermediate Event
A Signal Intermediate Event is an Intermediate Event that allows you to produce or consume a Signal object. Depending on the action the event element is to perform, you need to use either of the following:
  • Throwing Signal Intermediate Event produces a Signal object based on the defined properties
  • Catching Signal Intermediate Event listens for a Signal object with the defined properties
A.7.2.2.12. Signal Intermediate Event types
A.7.2.2.12.1. Throwing Signal Intermediate Event
When reached on execution, a Throwing Signal Intermediate Event produces a Signal object and the execution continues to its outgoing Flow.
Attributes
SignalRef
The Signal code that is to be sent or consumed
CancelActivity
if the Event is place on the boundary of an Activity and the Cancel Activity property is set to true, the Activity execution is cancelled immediately when the Event receives its Escalation object.
A.7.2.2.12.2. Catching Signal Intermediate Event
When reached on execution, a Catching Signal Intermediate Event awaits a Signal object defined in its properties. Once the object is received, the Event triggers execution of its outgoing Flow.
Attributes
SignalRef
reference code of the expected Signal object

A.7.3. End Events

An End Event is a node that ends a particular workflow. It has one or more incoming Sequence Flows and no outgoing Flow.
A Process must contain at least one End Event.
During runtime, an End Event finishes the Process workflow. It might finish only the workflow that reached the End Event or all workflows in the Process instance depending on its type.

A.7.3.1. End Event types

A.7.3.1.1. Simple End Event
The Simple End Event finishes the incoming workflow (consumes the incoming token). Any other running workflows in the Process or Sub-Process remain uninfluenced.

Important

In JBoss BPM Suite, the Simple End Event has the Terminate property in its Property tab. This is a boolean property, which turns a Simple End Event into a Terminate End Event when set to true.
A.7.3.1.2. Message End Event
When a Flow enters a Message End Event, the Flow finishes and the Event produces a Message as defined in its properties.
A.7.3.1.3. Escalation End Event
The Escalation End Event finishes the incoming workflow (consumes the incoming token) and produces an Escalation signal as defined in its properties, trigerring the escalation process.
A.7.3.1.4. Terminate End Event
The Terminate End Event finishes all execution flows in the given Process instance, that is, at the moment, one execution flow enters the end event, all execution flows in the Process instance are termninated and the Process instance becomes completed: if there are activities being executed, they are instantly cancelled. If a Terminate End Event is reached in a Sub-Process, the entire Process instance is terminated.

Note

If you are designing your Process in the Process Designer and you want to create a Terminate End Event, create a Simple End Event and define the Terminate property in the Property tab of the Simple End Event as true.
A.7.3.1.5. Throwing Error End Event
The Throwing Error End Event finishes the incoming workflow (consumes the incoming token). Any other running workflows in the Process or Sub-Process remain uninfluenced.
Attributes
ErrorRef
reference code of the produced Error object
A.7.3.1.6. Cancel End Event
If a Process or Sub-Process finishes with a Cancel End Event, any compensations defined for the namespace are executed, and the Process or Sub-Process finishes as CANCELLED.
A.7.3.1.7. Compensation End Event
A Compensation End Event is used to finish a transaction Sub-Process and trigger the compensation defined by the Compensation Intermediate Event attached to the boundary of the Sub-Process activities.
A.7.3.1.8. Signal End Event
A Thowing Signal End Event is used to finish a Process or Sub-Process flow. When the execution flow enters the element, the execution flow finishes and a Signal identified by its SignalRef property value.

A.7.4. Scope of Events

An event can send signals globally or be limited to a single process instance. You can use the scope attribute for events to define if a signal is to be considered internal (only for one process instance) or external (for all process instances that are waiting). The scope attribute called Signal Scope on the Properties panel of the process designer allows you to change the scope of the signal throw intermediate/end events.
The Scope data input is an optional property implemented to provide the following scope of throw events:
  • default: The throw event is set to default scope when no scope is selected. In this case, the signal is given a ksession and it signals only the elements known to that ksession. The signal behavior depends on the strategy used:
    • Singleton: In this case, the event signals all instances available for this ksession.
    • Per request: In this case, the event signals only currently processed process instance and those with start signal events.
    • Per process instance: In this case, similar to the per request strategy, the event signals only currently processed process instance and those with start signal events.
  • processInstance: This indicates that the scope of the signal remains within the same process instance that the signal is thrown from.
  • project/runtime manager: This indicates that either the scope of the signal is bound to runtime manager or that it signals runtime manager that the instance is bound to.
  • external scope: This indicates that the scope of the signal can be both project scope and cross deployments. For the signal to have a cross deployment scope, it requires to have a process variable called SignalDeploymentId. The SignalDeploymentId process variable provides information about which deployment/project must be the target of the signal.

[3] Business Process Model and Notation (BPMN). Version 2.0, OMG Document Number: formal/2011-01-03 http://www.omg.org/spec/BPMN/2.0