The partner link associated with the WS-BPEL onEvent is derived from the interface referenced by the operation of the boundary Message Event.

The same mapping applies to a non-interrupting boundary Timer Event, using a WS-BPEL onAlarm handler instead.

Error Boundary Events

A BPMN Activity with a boundary Error Event according to the following pattern is mapped as shown.

<flow>

<links>

<link name="[l1]"/>

...

<link name ="[l4]"/> </links>

<scope>

<sources><source linkName="[l1]"/></sources>

<faultHandlers>

[G1] </flow>

<flow>

<targets><target linkName="[l3]"/></targets>

<sources><source linkName="[l4]"/></sources> [G2]

</flow>

<empty>

<sources><source linkName="[l2]"/>

<source linkName="[l4]"/></sources> </empty>

</flow>

Note that the case where the error handling path doesn’t join the main control flow again, is still mapped using this pattern, by applying the following model equivalence.

Compensation Boundary Events

A BPMN Activity with a boundary Compensation Event is similarly mapped as shown.

Multiple Boundary Events, and Boundary Events with Loops

If there are multiple boundary Events for an Activity, their WS-BPEL mappings are super-imposed on the single WSBPEL scope wrapping the mapping of the Activity.

When the Activity is a standard loop or a multi-instance and has one or more boundary Events, the WS-BPEL loop resulting from mapping the BPMN loop is nested inside the WS-BPEL scope resulting from mapping the BPMN boundary Events.

The following example shows that mapping for a Sub-Process with a nested Event Sub-Process that has a standard loop with TestTime=“Before,” a boundary Error Intermediate Event, and a boundary Compensation Intermediate Event.