---
title: "14.2 Basic BPMN-BPEL Mapping"
chapter: "14 Mapping BPMN Models to WS-BPEL"
source: "OMG BPMN 2.0.2 — formal/2013-12-09"
pages: "446-469"
---
> 14 Mapping BPMN Models to WS-BPEL · páginas 446-469 · [índice](../README.md)
## 14.2 Basic BPMN-BPEL Mapping
*Ilustração (p. 447)*
This sub clause introduces a partial mapping function from **BPMN** orchestration **Process** models to WS-BPEL executable **Process** models by recursively defining the mapping for elementary **BPMN** constructs such as **Tasks** and **Events**, and for blocks following the patterns described here. Mapping a **BPMN** block to WS-BPEL includes mapping all of its associated attributes. The observable behavior of a WS-BPEL process resulting from a BPEL mapping is the same as that of the original **BPMN** orchestration **Process**. We use the notation [**BPMN** construct] to denote the WS-BPEL construct resulting from mapping the **BPMN** construct. Examples are [ServiceTask] = Invoke Activity which says that a **BPMN Service Task** is mapped to a WS-BPEL Invoke Activity, or which says that the data-based exclusive choice controlled by the two predicates p1 and p2, containing the three **BPMN** blocks G1, G2, and G3 is mapped to the WS-BPEL on the right hand side, which recursively uses the mappings of those predicates and those sub-graphs. Note that we use the “waved rectangle” symbol throughout this sub clause to denote **BPMN** blocks.
### 14.2.1 Process
*Ilustração (p. 447)*
The following figure describes the mapping of a **Process**, represented by its defining **Collaboration**, to WS-BPEL. The process itself is described by a contained graph G of flow elements to WS-BPEL. The **Process** interacts with *Participants* Q1... Qn via **Conversations** C1... Cm:
The partner links of the corresponding WS-BPEL process are derived from the set of interfaces associated with each participant. Each interface of the *Participant* containing the **Process** P itself is mapped to a WS-BPEL partner link with a “myRole” specification, each interface of each other *Participant* Qi is mapped to a WS-BPEL partner link with a “partnerRole” specification.
The variables of the corresponding WS-BPEL process are derived from the set “{dataObjects}” of all **Data Objects** occurring within G, united with the set “{properties}” of all properties occurring within G, without **Data Objects** or properties contained in nested **Sub-Processes**. See “Handling Data” on page 465 for more details of this mapping. The correlation sets of the corresponding WS-BPEL process are derived from the CorrelationKeys of the set of **Conversations** C1... Cn (see page 452 for more details of this mapping).
### 14.2.2 Activities
#### Common Activity Mappings
The following table displays a set of mappings of general **BPMN Activity** attributes to WS-BPEL activity attributes.
**Table 14.1 – Common Activity Mappings to WS-BPEL**
| Activity | Mapping to WS-BPEL |
| --- | --- |
| name | The name attribute of a BPMN activity is mapped to the name attribute of a WS-BPEL activity by removing all characters not allowed in an XML NCName, and ensuring uniqueness by adding an appropriate suffix. In the subsequent diagrams, this mapping is represented as [name]. |
#### Task Mappings
The following sub clauses contain the mappings of the variations of a **Task** to WS-BPEL.
#### Service Task
*Ilustração (p. 448)*
The following figure shows the mapping of a **Service Task** to WS-BPEL.
The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the **Service Task** is connected to by **Message Flows**, and from the interface referenced by the operation of the **Service Task**.
#### Receive Task
The following figure shows the mapping of a **Receive Task** to WS-BPEL.
*Ilustração (p. 449)*
Receive partnerLink="[Task-operatio n-interface]" Task portType="[Task-operation-interface ]"
The partner link associated with the WS-BPEL receive is derived from the interface referenced by the operation of the
#### Send Task
*Ilustração (p. 449)*
The following figure shows the mapping of a **Send Task** to WS-BPEL.
The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the **Send Task** is connected to by a **Message Flow**, and from the interface referenced by the operation of the **Send Task**.
#### Abstract Task
*Ilustração (p. 449)*
The following figure shows the mapping of an **Abstract Task** to WS-BPEL.
#### Service Package
#### Message
For **Messages** with a scalar data item definition typed by an XML schema definition, the following figure shows the mapping to WS-BPEL, using WSDL 1.1.
*Ilustração (p. 450)*
The top-level child elements of the XML schema defining the structure of the **BPMN Message** are mapped to the WSDL’s message’s parts.
#### Interface and Operation
*Ilustração (p. 450)*
The following figure shows the mapping of a **BPMN** interface with its operations to WS-BPEL, using WSDL 1.1.
#### Conversations and Correlation
For those **BPMN** nodes sending or receiving **Messages** (i.e., **Message Events**, **Service**, send or **Receive Tasks**) that have an associated key-based Correlation Key, the mapping of that key-based Correlation Key is as follows.
*Ilustração (p. 451)*
*Ilustração (p. 451)*
The messageType of the BPEL property alias is appropriately derived from the itemDefinition of the **Message** referenced by the **BPMN Message** key Expression. The name of the **Message** part is derived from the **Message** key Expression. The **Message** key Expression itself is transformed into an Expression relative to that part. The mapping of **Activities** with an associated key-based Correlation Key is extended to reference the above BPEL correlation set in the corresponding BPEL correlations element. The following figure shows that mapping in the case of a **Service Task** with an associated key-based Correlation Key.
The initiate attribute of the BPEL correlation element is set depending on whether or not the associated **Message Flow** initiates the associated **Conversations**, or participates in an already existing **Conversation**. If there are multiple CorrelationKeys associated with the **Conversation**, multiple *correlation* elements are used.
#### Sub-Process Mappings
The following table displays the mapping of an embedded **Sub-Process** with Adhoc=”*False*” to a WS-BPEL scope. (This extends the mappings that are defined for all **Activities**--see page 448). The following figure shows the mapping of a **BPMN Sub-Process** without an **Event Sub-Process**.
*Ilustração (p. 452)*
The following figure shows the mapping of a **BPMN Sub-Process** with an **Event Sub-Process**. (**Event Sub*-Processes** could also be added to a top-level **Process**, in which case their mapping extends correspondingly.)
Note that in case of multiple **Event Sub-Processes**, there would be multiple WS-BPEL handlers.
#### Mapping of Event Sub-Processes
*Ilustração (p. 452)*
Note that if a **Sub-Process** contains multiple **Event Sub-Processes**, all become handlers of the associated WS- BPEL scope, ordered and grouped as specified by WS-BPEL. Non-interrupting **Message Event Sub-Processes** are mapped to WS-BPEL event handlers as follows.
*Ilustração (p. 452)*
Timer **Event Sub-Processes** are mapped to WS-BPEL event handlers as follows.
*Ilustração (p. 452)*
Error **Event Sub-Processes** are mapped to WS-BPEL fault handlers as follows.
*Ilustração (p. 453)*
A **Compensation Event Sub-Process** is mapped to a WS-BPEL compensation handler as follows.
#### Activity Loop Mapping
Standard *loops* with a testTime attribute “Before” or “After” execution of the **Activity** map to WS-BPEL while and repeatUntil activities in a straight-forward manner. When the LoopMaximum attribute is used, additional activities are used to maintain a *loop* counter. *Multi-instance* **Activities** map to WS-BPEL forEach activities in a straight-forward manner.
#### Standard Loops
*Ilustração (p. 453)*
The mappings for standard *loops* to WS-BPEL are described in the following. A standard *loop* with testTime= “Before” maps to WS-BPEL as follows, where *p* denotes the *loop* condition.
*Ilustração (p. 453)*
A standard *loop* with testTime= “After” maps as follows, where *p* denotes the *loop* condition.
#### Dealing with LoopMaximum
When the LoopMaximum attribute is specified for an **Activity**, the *loop* requires additional set up for maintaining a counter.
*Ilustração (p. 454)*
A standard *loop* with testTime=“Before” and a LoopMaximum attribute maps to WS-BPEL as follows (again, *p* denotes
*Ilustração (p. 454)*
(The notation [counter] denotes the unique name of a variable used to hold the counter value; the actual name is immaterial.) A standard *loop* with testTime=“After” and a LoopMaximum attribute maps as follows:
(The notation [counter] denotes the unique name of a variable used to hold the counter value; the actual name is immaterial.)
#### Multi-Instance Activities
*Ilustração (p. 455)*
A **BPMN Multi-Instance Task** with a multiInstanceFlowCondition of “All” is mapped to WS-BPEL as follows.
(The notation [counter] denotes the unique name of a variable used to hold the counter value; the actual name is immaterial.)
### 14.2.3 Events
#### Start Event Mappings
The following sub clauses detail the mapping of **Start Events** to WS-BPEL.
#### Message Start Events
*Ilustração (p. 455)*
A **Message Start Event** is mapped to WS-BPEL as shown in the following figure.
The partner link associated with the WS-BPEL receive is derived from the interface referenced by the operation of the
#### Error Start Events
An **Error Start Event** can only occur in **Event Sub-Processes**. This mapping is described on page 455.
#### Compensation Start Events
A **Compensation Start Event** can only occur in **Event Sub-Processes**. This mapping is described on page 455.
#### Intermediate Event Mappings (Non-boundary)
The following sub clauses detail the mapping of intermediate non-boundary **Events** to WS-BPEL.
#### Message Intermediate Events (Non-boundary)
*Ilustração (p. 456)*
A **Message Intermediate Event** can either be used in normal control flow, similar to a **Send** or **Receive Task** (for *throw* or *catch* **Message Intermediate Events**, respectively), or it can be used in an **Event Gateway**. The latter is described in more detail in “Gateways and Sequence Flows” on page 461. The following figure describes the mapping of **Message Intermediate Events** to WS-BPEL.
The partner link associated with the WS-BPEL receive is derived from the interface referenced by the operation of the **Message Intermediate Event**.
#### Timer Intermediate Events (Non-boundary)
*Ilustração (p. 456)*
A **Timer Intermediate Event** can either be used in normal control flow, or it can be used in an **Event Gateway**. The latter is described in more detail in “Gateways and Sequence Flows” on page 461. The following figure describes the mapping of a **Timer Intermediate Event** to WS-BPEL – note that one o the mappings shown is chosen depending on whether the **Timer Event’s** TimeCycle or TimeDate attribute is used.
#### Compensation Intermediate Events (Non-boundary)
A **Compensation Intermediate Event** with its waitForCompletion property set to *true*, that is used within an **Event Sub-Process** triggered through an *error* or through *compensation*, is mapped to WS-BPEL as follows.
*Ilustração (p. 457)*
The first mapping is used if the **Compensation Event** does not reference an **Activity**, the second mapping is used otherwise.
#### End Event Mappings
The following sub clauses detail the mapping of **End Events** to WS-BPEL.
#### None End Events
*Ilustração (p. 457)*
A “none” **End Event** marking the end of a **Process** is mapped to WS-BPEL as shown in the following figure.
#### Message End Events
*Ilustração (p. 457)*
A **Message Start Event** is mapped to WS-BPEL as shown in the following figure.
The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the **Message Intermediate Event** is connected to by a **Message Flow**, and from the interface referenced by the operation of the **Message Intermediate Event**.
#### Error End Events
An **Error End Event** is mapped to WS-BPEL as shown in the following figure.
*Ilustração (p. 458)*
#### Compensation End Events
*Ilustração (p. 458)*
A **Compensation End Event** with its waitForCompletion property set to *true*, that is used within an **Event Sub- Process** triggered through an *error* or through *compensation*, is mapped to WS-BPEL as follows.
The first mapping is used if the **Compensation Event** does not reference an **Activity**, the second mapping is used otherwise.
#### Terminate End Events
*Ilustração (p. 458)*
A **Terminate End Event** is mapped to WS-BPEL as shown in the following figure.
#### Boundary Intermediate Events
#### Message Boundary Events
A **BPMN Activity** with a non-interrupting **Message** boundary **Event** is mapped to a WS-BPEL scope with an event handler as follows.
*Ilustração (p. 459)*
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
*Ilustração (p. 459)*
A **BPMN Activity** with a boundary **Error Event** according to the following pattern is mapped as shown.
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
*Ilustração (p. 460)*
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 WS- BPEL 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**
*Ilustração (p. 461)*
### 14.2.4 Gateways and Sequence Flows
The mapping of **BPMN Gateways** and **Sequence Flows** is described using **BPMN** blocks following particular patterns.
#### Exclusive (Data-based) Decision Pattern
An exclusive data-based decision is mapped as follows.
*Ilustração (p. 462)*
While this figure shows three branches, the pattern is generalized to *n* branches in an obvious manner.
#### Exclusive (Event-based) Decision Pattern
*Ilustração (p. 462)*
An **Event Gateway** is mapped as follows.
While this figure shows three branches with one **Message Intermediate Event**, one **Receive Task** and one **Timer Intermediate Event**, the pattern is generalized to *n* branches with any combination of the former in an obvious manner. The handling of *Participants* (BPEL partnerLinks), **Event** (operation) and timer details is as specified for **Message Intermediate Events**, **Receive Tasks**, and **Timer Intermediate Events**, respectively. The data flow and associated variables (not shown) are handled as for **Receive Tasks/Message Intermediate Events**.
#### Inclusive Decision Pattern
An inclusive decision pattern without an otherwise gate is mapped as follows:
*Ilustração (p. 463)*
While this figure shows three branches, the pattern is generalized to *n* branches in an obvious manner. Note that link names in WS-BPEL MUST follow the rules of an XML NCName. Thus, the mapping of the **BPMN Sequence Flow** name attribute MUST appropriately canonicalize that name, possibly ensuring uniqueness, e.g., by appending a unique suffix. This is capture by the [linkName] notation.
#### Parallel Pattern
*Ilustração (p. 464)*
A parallel fork-join pattern is mapped as follows.
#### Sequence Pattern
*Ilustração (p. 464)*
A **BPMN** block consisting of a series of **Activities** connected via (unconditional) **Sequence Flows** is mapped to a WS-BPEL sequence:
#### Structured Loop Patterns
*Ilustração (p. 464)*
A **BPMN** block consisting of a structured *loop* of the following pattern is mapped to a WS-BPEL while.
A **BPMN** block consisting of a structured *loop* of the following pattern is mapped to a WS-BPEL repeatUntil.
*Ilustração (p. 465)*
#### Handling Loops in Sequence Flows
*Ilustração (p. 465)*
*Loops* are created when the flow of the **Process** moves from a downstream object to an upstream object. There are two types of *loops* that are WS-BPEL mappable: while *loops* and repeat *loops*. A while *loop* has the following structure in **BPMN** and is mapped as shown.
*Ilustração (p. 465)*
A repeat *loop* has the following structure in **BPMN** and is mapped as shown.
### 14.2.5 Handling Data
#### Data Objects
**BPMN Data Objects** are mapped to WS-BPEL variables. The itemDefinition of the **Data Object** determines the XSD type of that variable. **Data Objects** occur in the context of a **Process** or **Sub-Process**. For the associated WS-BPEL process or WS- BPEL scope, a variable is added for each **Data Object** in the corresponding WS-BPEL variables sub clause, as follows:
*Ilustração (p. 466)*
#### Properties
*Ilustração (p. 466)*
**BPMN** properties can be contained in a **Process**, **Activity**, or an **Event**, here named the “container” of the property. A **BPMN** property is mapped to a WS-BPEL variable. Its name is derived from the name of its container and the name of the property. Note that in the case of different containers with the same name and a contained property of the same name, the mapping to WS-BPEL ensures the names of the associated WS-BPEL variables are unique. The itemDefinition of the property determines the XSD type of that variable. A **BPMN Process** property is mapped to a WS-BPEL global variable. A **BPMN Event** property is mapped to a WS- BPEL variable contained in the WS-BPEL scope representing the immediately enclosing **Sub-Process** of the **Event** (or a global variable in case the **Event** is an immediate child of the **Process**). For a **BPMN Activity** property, two cases are distinguished: In case of a **Sub-Process**, the WS-BPEL variable is contained in the WS-BPEL scope representing the **Sub-Process**. For all other **BPMN Activity** properties, the WS-BPEL variable is contained in the WS-BPEL scope representing the immediately enclosing **Sub-Process** of the **Activity** (or a global variable in case the **Activity** is an immediate child of the **Process**).
structureRef="P1-structure Definition"/> typ e="[P1-structureDefinition]"/>
#### Input and Output Sets
For a **Send Task** and a **Service Task**, the single input set is mapped to a WSDL message defining the input of the associated WS-BPEL activity. The inputs map to the message parts of the WSDL message. For a **Receive Task** and a **Service Task**, the single output set is mapped to a WSDL message defining the output of the associated WS-BPEL activity. The outputs map to the message parts of the WSDL message. The structure of the WSDL message is defined by the itemDefinitions of the data inputs of the input set.
*Ilustração (p. 467)*
*Ilustração (p. 467)*
For the data outputs of the output set, the WSDL message looks as follows.
#### Data Associations
*Ilustração (p. 467)*
In this sub clause, we assume that the input set of the **Service Task** has the same structure as its referenced input **Message**, and the output set of the **Service Task** has the same structure as its reference output **Message**. If this is not the case, assignments are needed, and the mapping is as described in the next sub clause. Data associations to and from a **Service Task** are mapped as follows.
Data associations from a **Receive Task** are mapped as follows.
*Ilustração (p. 468)*
*Ilustração (p. 468)*
Data associations to a **Send Task** are mapped as follows.
#### Expressions
**BPMN** Expressions specified using XPath (e.g., a condition Expression of a **Sequence Flow**, or a timer cycle Expression of a **Timer Intermediate Event**) are used as specified in **BPMN**, rewriting access to **BPMN** context to refer to the mapped BPEL context. The **BPMN** XPath functions for accessing context from the perspective of the current **Process** are mapped to BPEL XPath functions for context access as shown in the following table. This is possible because the arguments MUST be literal strings.
**Table 14.2 – Expressions mapping to WS-BPEL**
| BPMN context access | BPEL context access |
| --- | --- |
| getDataobject(dataObjectName) | $[dataObjectName] |
| getProcessProperty(propertyName) | $[{processName}.propertyName] where the right pro-cessName is statistically derived. |
| getActivityProperty(activityName, propertyName) | $[activityName.propertyName] |
| getEventProperty(eventName, propertyName) | $[eventName.propertyName] |
#### Assignments
For a **Service Task** with assignments, the WS-BPEL mapping results in a sequence of an assign activity, an invoke activity and another assign activity. The first assign deals with creating the service request **Message** from the data inputs of the **Task**, the second assign deals with creating the data outputs of the **Task** from the service response **Message**.