Adding Boundary Events

ActiveVOS Designer User’s Guide

Adding Boundary Events

The Business Process Model and Notation (BPMN) 2.0 specification includes the concept of a boundary event. In ActiveVOS, 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, ActiveVOS creates the BPEL code to wrap the activity in a scope for valid execution.

The following illustration shows a normal event handler vs. a boundary event on a scope.

normal event handler of scope vs. boundary event

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.

Boundary event example on an invoke

The properties of a boundary event are:

Must be one of onEvent, onAlarm, Catch, Catch All, Compensation
Must be dropped only onto the boundary (border) of any rounded border activity, such as a scope or invoke
Must use outbound link(s) to activities that have not yet executed (downstream activities) or are not already deadpath (branches of an if container)
Outbound links cannot have conditions
Can be defined as interrupting or non-interrupting (discussed below)
Interrupting boundary event is an ActiveVOS extension to BPEL
Only available in the BPMN editor, not the Classic editor

Let’s look at 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.

boundary event example

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:

boundary event example

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
See also Tips and Tricks - BPMN Design for a comparison between an interrupting boundary vs. internal scope handlers

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. ActiveVOS 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 will be executed.

boundary event interrupting

Note the difference in icon appearance for non-interrupting and interrupting boundary events.

boundary event interrupting and non-interrupting icons

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.