The Business Process Model and Notation (BPMN) 2.0 specification includes the concept of a boundary event. In Process Developer, a BPMN
boundary event
is a BPEL scope handler (event, fault, or compensation) that is dropped onto the boundary of a bordered activity. You can use a boundary event as a shortcut to creating a scope and its interior scope handler, providing a cleaner-appearing design. The event handling is shown at the same level as the main activity. Behind the scenes, Process Developer creates the BPEL code to wrap the activity in a scope for valid execution.
The following illustration shows a normal event handler compared to a boundary event on a scope.
You can add a boundary event to any bordered activity. The following example shows an invoke with an
onEvent
handler that escalates a repair request from Standard to Premium.
The properties of a boundary event are:
Must be one of
onEvent
,
onAlarm
,
Catch
,
Catch All
, or
Compensation.
Must be dropped only onto the boundary (border) of any rounded border activity, such as a scope or invoke.
Must use outbound links to activities that have not yet executed (downstream activities) or are not already dead path (branches of an if container).
Outbound links cannot have conditions.
Can be defined as interrupting or non-interrupting (discussed below).
Interrupting boundary event is a Process Developer extension to BPEL.
Only available in the BPMN editor, not the Classic editor.
Here are some examples of boundary events.
Non-interrupting onAlarm or onEvent
In the following illustration, the collapsed scope displays an
onAlarm
handler on its boundary. The handler can execute in parallel with the activities in the scope. A boundary event does not have a container like the
onAlarm
or
onEvent
handler that is dropped into a scope. Rather, the boundary event links to one or more activities to execute. The links cannot have conditions.
In the example above, the
onAlarm
boundary event behaves exactly like a scope
onAlarm
handler. The same processing rule applies: activities in the main scope execute in parallel with the
onAlarm
activity, if the alarm is triggered. This makes the boundary event non-interrupting. The linked activity (the reply in the above example) cannot be not part of the main process.
The Interrupting Boundary Event property is disabled by default, as the illustration shows:
Interrupting onAlarm or onEvent
If desired, you can add a new processing rule to an
onAlarm
or
onEvent
by enabling the Interrupting property, shown above. In this case, the main scope terminates when the event is triggered.
Some use cases for an interrupting boundary event are as follows:
onEvent
: cancel an order
onAlarm
: request is no longer relevant, don't bother
An interrupting boundary event can be connected back to a downstream activity in the main process. Note that this behavior is an extension to WS-BPEL 2.0. Process Developer uses the Mutually Exclusive Transitions extension to execute an interrupting boundary event.
In the following illustration, the collapsed scope contains an interrupting
onAlarm
that, when triggered, terminates the main scope. Only one path is executed.
Note the difference in icon appearance for non-interrupting and interrupting boundary events.
You can also add a boundary event for a fault or compensation handler. There are some minor exceptions as described in
Catch and Catch All Boundary Events and Compensate, Compensate Scope and Rethrow
.
See also:
Adding a Fault Handler for a Scope
Adding a Fault Handler as a Boundary Event for an Invoke Activity
Adding a Compensation Handler to a Scope
Compensating an Invoke Activity
Using a Variable from a Catch or Interrupting OnEvent Boundary Event