Adding Boundary Events

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:

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:

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.

Catch and Catch All Boundary Events and Compensate Compensate Scope and Rethrow

There are some BPEL activities that cannot be used as the target of a catch or catch all boundary event.

You cannot add a compensate, compensate scope, or rethrow activity as a linked target of a catch or catch all. The catch and catch all events are interrupting events, triggered by the termination of the scope they are attached to. As such, they get executed outside of the scope. The work of the compensate, compensate scope, and rethrow activities is to execute within a scope. These activities must be added inside a scope's catch or catch all handler.

Using a Variable from a Catch or Interrupting OnEvent Boundary Event

An interrupting onEvent boundary event as well as a catch boundary event are Process Developer extensions. As such, the variable handling for these events differs from normal BPEL fault and event handling.

Catch Boundary Event Variable Handling

If you want to define a variable for a catch boundary event, you must select an existing process variable or create a new process variable in the Fault Variable picklist.

This differs from defining a variable in a normal scope catch handler, where you can type in a special fault variable name.

This difference arises because in a normal catch handler, the fault variable is used within an activity that is enclosed by the scope. In an interrupting boundary event, there is no activity within the event handler. Instead, the boundary event links to an activity in the process or another scope.

Behind the scenes, Process Developer generates the activities needed in order to use boundary event variables. Process Developer creates an implicit parameters variable for the catch that is available only within a hidden scope containing the catch boundary event. Therefore, to define a variable for use in another part of the process, such as a reply with fault, you must select a process variable or create a new process variable. Process Developer maps the implicit parameters variable to the process variable. See the example below.

Interrupting OnEvent Boundary Event

The variable handling is essentially the same as for a catch boundary event. In the Properties view of an interrupting OnEvent boundary event, you can select an existing process variable or create a new variable in the Variable drop-down.

The following illustration shows the Properties for an interrupting OnEvent boundary event.

In the BPEL source code, notice that a scope with an assign is added. The assign copies the implicit scope variable, parameters, to the process variable, customerComplaint.

<bpel:eventHandlers>
<bpel:onEvent aei:boundaryEvent="interrupting" element="ns6:customerComplaint"
ext1:handleIMAInEnclosingScope="true"
operation="getComplaint"
partnerLink="RepairServices"
variable="parameters">
<bpel:scope>
<bpel:assign ext1:mutexTransitions="yes">
<bpel:sources>
<bpel:source linkName="L5"/>
</bpel:sources>
<bpel:copy>
<bpel:from variable="parameters"/>
<bpel:to variable="customerComplaint"/>
</bpel:copy>
</bpel:assign>
</bpel:scope>
</bpel:onEvent>
</bpel:eventHandlers>