No results found

Your search did not match any results.

We suggest you try the following to help find what you’re looking for:

  • Check the spelling of your keyword search.
  • Use synonyms for the keyword you typed, for example, try “application” instead of “software.”
  • Try one of the popular searches shown below.
  • Start a new search.
Trending Questions

Transforming BPMN into BPEL: Why and How

When transforming a BPMN model into an executable BPEL process, it's important to keep the semantic differences between BPMN and BPEL in mind.
By Lonneke Dikmans
Published September 2008

Architect: SOA

With the acquisition of BEA, several new products have joined the pre-existing Oracle Business Process Analysis Suite in Oracle's Business Process Management (BPM) portfolio. These new tools form what is collectively now called Oracle Business Process Management Suite (including Oracle Business Process Management Studio, formerly BEA AquaLogic Business Process Management Studio), which is an option to Oracle WebLogic Suite.

Oracle Business Process Analysis Suite, which is complementary to the new Oracle Business Process Management Suite, can be used to model the business architecture of an organization formally using Business Process Modeling Notation (BPMN). One of the advantages of using Oracle Business Process Analysis Suite to model business processes is that you can reuse these descriptions as blueprints for your executable Business Process Execution Language (BPEL) processes.

However, there are some differences between BPMN and BPEL that you need to be aware of. First of all, BPMN is used in a different stage in the life cycle of BPM than BPEL. BPMN is used when designing and improving the business process, whereas BPEL is used when implementing it. Different requirements exist in different phases. Second, BPMN is used by business analysts, and BPEL is used by technical analysts and programmers. They use different paradigms and focus on separate issues when modeling a process.

In this article, BPMN and BPEL and the differences between the languages are further explained and illustrated with an example.


  • Oracle Business Process Analysis Suite or later
  • Oracle JDeveloper or later

Business Process Management Lifecycle

BPM is a notation based on flowcharting for business process modeling; it became an OMG final adopted standard in February 2006. It covers activities performed by organizations to manage and, if necessary, to improve their business processes. Oracle has different tools that support the activities in the BPM lifecycle:

  • Designing or capturing the business processes . Oracle Business Process Architect, a component of the Oracle Business Process Analysis Suite, can be used for this task It enables company wide modeling and design of business processes, IT systems, landscapes and organization structures. Business analysts can model the business process using BPMN or the proprietary ARIS modeling language event-driven process chain (EPC). Oracle Business Process Management Studio can be used for this purpose as well; although it is not commonly used for formal companywide modeling and business architecture design, it can be used in agile projects where the sole purpose is to capture the business process itself.
  • Model or simulate the business process. Using Oracle Business Process Analysis suite, business processes can be simulated using the simulation component. This component allows business analysts to analyze processes by running simulations based on different scenarios.
  • Process execution . As part of Oracle SOA Suite, Oracle offers the BPEL Process Manager engine and Oracle JDeveloper to create BPEL applications. Another option is to execute the process in Oracle Business Process Management Studio. (This is outside the scope of this article however.)
  • Process monitoring . Oracle offers both a Business Activity Monitoring tool and several business intelligence (BI) solutions.
  • Process improvement . The output from process monitoring is input for improvements in the process. These can be designed, simulated, and executed using the same tools.

So why can’t we just design our processes using BPEL? Well, BPEL is an execution language, which makes it too detailed and technical to be used by business analysts to capture or design business processes. With this fact in mind, the BPMN specification committee tried to achieve two goals with BPMN:

  • Design a notation that could be used by business analysts as well as technical analysts
  • Develop a notation that can be transformed to executable languages like BPEL

Overall they succeeded with both goals. Business analysts pick up BPMN fairly easily, and there is a lot of software on the market that transforms BPMN into BPEL. However, there are some issues when transforming a BPMN process to BPEL. These issues have different causes. In the next section I’ll briefly describe the two modeling languages, and emphasize the differences between the two.

Understanding BPMN

In BPMN, a business process diagram (BPD) consists of flow objectsconnecting objects, swimlanes, and artifacts. The specification defines the notation and semantics of a BPD. Oracle Business Process Analysis Suite is not 100-percent compliant with the BPMN standard. In this section, I will describe the elements in more detail and discuss how this process can be modeled with Oracle Business Process Analysis Suite..

Flow Objects

There are three types of flow objects: activities, events, and gateways.


An activity is work that is performed in the business process. There are three types of activities: Tasks, looped activities, and subprocesses. Subprocesses don’t show up in Oracle Business Process Analysis Suite as the specification describes, but they can be modeled in it by editing the BPMN attributes. The same is true for looped activities.

Within a BPMN tool, vendors can add markers or icons to tasks, as long as this does not affect the footprint of the diagram. In Oracle Business Process Analysis Suite, tasks are represented by the following objects: function, automated activity, notification , human task, and business rule function.


An event is something that happens during the business process. It is usually triggered by something and/or has a result. The type of event depends on the place in the business process. There are three types of events: start event, intermediate event, and end event. In BPMN, the trigger and result can be modeled by using the attributes dialog box.


Gateways is the last category of flow objects. There are different types of gateways. They all merge and split the flow. If the flow does not need to be controlled, a gateway is not needed. In Oracle Business Process Analysis Suite, you can model XOR (exclusive or)gateways (data based and event based), OR, AND, and complex gateways.

Connecting Objects

The connecting objects can be sequence flows (a connector that connects two activities), message flows, or association flows.


In BPMN, there are two types of swimlanes: pools and lanes. Pools are used to mark the boundaries of an organization. Interactions between pools are through message flows. Sequence flows are not allowed to cross a pool boundary. This means that a process is always fully contained within a pool. Lanes can be used to divide a pool—for example, to mark different organizational roles within an organization. Sequence flows can cross lanes.


The last category of objects in BPMN is artifacts. There are three types of artifacts: data objects, groups, and annotations. Annotations and groups are not supported in Oracle Business Process Analysis Suite. Data objects consist of a group of different types: person type function, data cluster, and so on.

BMPN Example

Now that we know what objects can appear on a BPD, we can start with an example. In this example, we will model part of the process of publishing an article for Oracle Technology Network (OTN).

The process starts when the abstract is approved. This is modeled as a start event, with a message. The marker shows up, when you choose Message in the BPMN attribute Trigger/Result.

The article is written and submitted to the editors. The artifact article is used to depict the information carrier. Then the writer waits for review results. When the article with revisions is received, the writer reviews it. Depending on the result, the process ends or the article is edited and submitted to the editors again. This is modeled by the 'exclusive-or-data' gateway and a sequence flow going backto 'edit article'. The process ends with the publishing of the article.

As you can see, there are three events here: a start event, an intermediate event, and an end event. There is one gateway of the type ‘exclusive or’. There are three activities, all tasks. All flow objects are connected using sequence flows. There are two artifacts: one article that is sent to OTN and one revision that is sent to the writer. These are connected to the tasks using associations.
In this diagram, we could have added two pools: one for the writer and one for OTN. You won’t do this in this case, to keep the example simple.

It is common practice to identify different levels of abstraction in the process models. The most-detailed processes contain information that links the process to IT systems; the more-abstract models don’t.

The goal of these process models is to visualize the business process in an organization. These models can be used for different goals: to automate processes with IT services to support and improve the process, to write instructions for employees, to show compliance to auditors, and to create insight into the business. In this article, you will use the model to automate and monitor the process. To accomplish this, you need to transform it into an executable language, BPEL. Before you do that, you will create a variant of the process with specific implementation details needed to transform the task. You make human tasks of the ‘write article’ and ‘review revision’ activities. This way, we can monitor the deadlines and keep track of the state. ‘Submit article’ is transformed into a notification.


BPEL comprises basic and structured activities, variables, partner links and handlers. It uses XML to describe these things. Oracle SOA Suite supports BPEL4WS 1.1. In addition, Oracle has added extensions that are not in the specification. The latest specification is the final BPEL 2.0 specification; it can be found at the OASIS site.


There are two types of activities in BPEL: basic and structured. Basic activities that are available in Oracle SOA Suite 10g include invoke, receive, reply, assign, throw, wait, terminate, and transform. Structured activities are used to combine basic activities. The following activities are supported in Oracle SOA Suite 10 g: sequence, flow, flowN, switch, while, and pick.


Variables are used to store messages that are exchanged and to store the state of the process. There are three types of variables:

  • Simple type. This type of variable holds an XML Schema simple type (such as string, date, and so on).
  • Message type. This type holds a WSDL message.
  • Element. This type holds an XML Schema element.

Variables can be declared at the beginning of the process (global variables) or within a scope.

Partner links

Links to parties that the BPEL process interacts with what are called partner links. A partner can invoke the BPEL process, can be invoked by the BPEL process, or can have both roles.


Handlers are used when an error occurs (fault handlers), to react to events, and to execute compensation.

BPEL Example

In the sample directory of Oracle SOA Suite, there is a very simple example that shows some of the concepts we just talked about:

 <!-- HelloWorld BPEL Process --> 
 <process name="HelloWorld" 
 <!-- List of services participating in this BPEL process --> 
 The 'client' role represents the requester of this service. It is used for callback. 
 The location and correlation information associated with the 
 client role are automatically set using WS-Addressing. 
 <partnerLink name="client" 
 <!-- List of messages and XML documents used as part of this BPEL process --> 
 <!-- Reference to the message passed as input during initiation --> 
 <variable name="input"
 <!-- Reference to the message that will be sent back to the requestor during callback --> 
 <variable name="output" 
 <!-- Orchestration Logic --> 
 <!-- Receive input from requestor. 
 Note: This maps to operation defined in HelloWorld.wsdl 
 <receive name="receiveInput" partnerLink="client" 
 operation="initiate" variable="input" 
 <!-- Generate content of output message based on the content of the input message. -->
 <from expression="concat('Hello ',bpws:getVariableData('input', 'payload','/tns:name'))"/> 
 <to variable="output" part="payload" query="/tns:result"/> 
 <!-- Asynchronous callback to the requester. 
 Note: the callback location and correlation id is transparently handled using WS-addressing. --> 
 <invoke name="replyOutput" 

As you can see, this is an asynchronous BPEL process that receives a message stored in the variable “input”. The process then assigns the result of the concatenation “Hello” and the payload of the message to the variable “output”. This is then returned to the requester by an invoke activity.

There is one partner link in this example: the same client that invokes the process receives the answer.
The goal here is not to model any process but to actually execute it. There are basically two situations where BPEL is very useful: to execute a long-running business process or to create a composite service.

BPEL Has No Goto

Now that we’ve discussed both languages, let’s focus on the translation from BPMN to BPEL.

In general, the following mapping is used by Oracle Business Process Analysis Suite when generating a BPEL process from a BPMN diagram:

  • All activities (automated, function, notification, and so on) are mapped to a scope. The corresponding services are generated as well. For example: a notification service is generated, and the BPEL artifacts that invoke this service.
  • Start events are transformed to receive activities except when there is no trigger defined. If a trigger of the type 'multiple' is defined, a pick activity is generated. A timer message will be tranformed to a separate process that calls the generated receive message.
  • End events are transformed to an invoke activity, a reply activity, a throw activity, a compensation element, a terminate activity, and so on. The type of activity depends on the result type. If no result type is modeled, no activity is generated in BPEL.
  • Gateways are transformed to switch, pick, or flow depending on the type of gateway and the type of flow object that follows the gateway.
  • Swimlanes are not mapped to BPEL.
  • Connecting objects are generally not mapped to BPEL. (See the specification for some exceptions—such as when flow is used.)
  • Business data is mapped to variables.
  • Subprocesses are not mapped to a BPEL scope; they are mapped to an invoke activity.

The BPMN specification explains the mapping in detail in Annex A. This mapping is not complete, so don’t be surprised if different tools result in different transformation rules.

Sample Application

To test this with Oracle JDeveloper and Oracle Business Process Analysis Suite, we will first import the SOA profiles into Oracle Business Process Analysis Suite and then transform the BPMN diagram to BPEL. Then we move to Oracle JDeveloper, install the Oracle Business Process Analysis Suite plug-in for Oracle JDeveloper, and start a project based on a blueprint. We will use the process example from the previous paragraphs. First we will add some detail to the process. Once you decide to implement the process, you need to decide which activities are going to be automated activities, which are human tasks, what messages are exchanged, and so on.

  1. Import the database from this example.
    1. Go to the Explorer view by clicking the explorer icon
    2. Right-click LOCAL and select Restore…
    3. Browse to OTN.adb (see sample code zip) and click OK
  2. Import the SOA profiles.
    1. Create a new group in the OTN database in the location where you want to import the SOA profiles and name it “SOA profiles”.
    2. Right-click SOA Profiles and select SOA and then Import SOA profiles.... (see Figure)
    3. Answer Yes when asked whether you want to use the currently selected group. You will be notified when the profiles are successfully imported.
  3. Generate the BPEL process.
    1. Navigate to the process we created earlier (WriteAndReviewArticle).
    2. Right-click the claims process and select SOA and then Transform business process into BPEL process....
    3. Click Yes to validate the business process.
    4. Accept all the defaults, and click Finish.
  4. View the generated BPEL.
    1. Right-click the process.
    2. Choose Go to BPEL process.

    Now that we have created the skeleton or blueprint, we need to import it into Oracle JDeveloper, so we can make it an executable process and enter the details.

  5. Install the Oracle Business Process Analysis Suite plug-in in Oracle JDeveloper.
    1. Unzip the into the <JDev _Home> folder.
    2. Restart Oracle JDeveloper.
  6. Create a connection to the Oracle Business Process Analysis Suite server.
    1. Navigate to the Connections Navigator.
    2. Right-click Oracle BPA Server and select New BPA Server Connection....
    3. Enter the settings (in this case, we use the local Oracle Lite server with default username/password system/manager).
    4. Test the connection on the Test tab.
  7. Create a new BPEL project based on a blueprint.
    1. Select New... and then BPEL Process project.
    2. Select Existing Blueprint in the wizard.
    3. Select the blueprint from the list by clicking on the Browse BPA Server icon.
    4. Select the WriteAndEditArticle blueprint
    5. Click Next.
    6. Leave the default input and output elements and select Finish.

Now you have the skeleton BPEL process in Oracle JDeveloper. The developer adds implementation details to this process. The model structure is protected: a developer can add new scopes between existing scopes but can’t delete any existing scopes. New versions of the BPMN model can be imported from Oracle JDeveloper.

Changes in the process from Oracle JDeveloper are visible in Oracle Business Process Analysis Suite as improvement proposals, after you upload them from Oracle JDeveloper. You can find these when you are in the explorer view of Oracle Business Process Analysis Suite.

Handling Incompatible Processes

One common problem occurs when you are trying to transform a valid BPMN model into a BPEL process and errors are generated. This typically happens when you have two or more activities flowing back to a previous activity. This stems from the fact that BPMN supports arbitrary cycles and BPEL only supports structured cycles, with one entry point and one exit point (while).

Suppose you expand our example because a change occurred in the process: if you submit an article that has no edits, then it is published right away, without sending a revision back to the author. This process looks like this:

If you validate this business process, Oracle Business Process Analysis Suite informs you that the BPMN diagram is valid. But, when you transform this to a BPEL process, you get the following error:

As you can see, it is a semantic error: this is valid BPMN, but it can’t be transformed into[ Q: “into”?] BPEL. The diagram shows an error at the write article activity:

There are several solutions to this problem. Usually the best way to solve this is to remove generalizations from the process. Generalizations that you make in your IT systems don’t belong in a business process. For example, in a business process there is a difference between the first time (write the article and submit it) and the consecutive actions that are taken. You can’t avoid the first edit and review, but every edit action after that should be kept to a minimum. So instead of editing the article, we create a new activity called correct article. In our IT systems, we obviously do want to reuse components and services when executing these activities. We also add an event to show that we expect either a revision or a publication message. Finally, we also change the review flow: even if the author agrees with all the changes made by the editor, she or he still needs to explicitly approve the changes. To summarize, we change the model as follows:

  1. We add a gateway to reflect to different messages from the publisher: a revision message and a publication message.
  2. We add an extra activity: accept revision.
  3. We add an extra activity: correct article (instead of edit article).
  4. We add an extra activity: resend article (instead of send article).

This process flow is still relatively easy to understand. We can now generate the blueprint and start editing it in Oracle JDeveloper. The resulting BPEL is a little more complex. This is something to watch out for: the more flows and loops in a BPMN diagram, the more differences there will be in the corresponding BPEL. The BPEL model will also be expanded with assignments and copy actions that are purely technical in nature. Communication between the developer and the business becomes harder because the models differ in shape; this makes it harder to solve problems, add features, and improve the business process. This is something that should be considered when designing the processes in Oracle Business Process Analysis Suite. Organizing the processes in smaller chunks and in different levels of abstraction can reduce the mismatch between BPMN and BPEL considerably.
The solution that is described here, obviously only works when the business process can be rewritten. Sometimes there are use cases with a true go-to in the process. In that case it might be easier to implement the business process using Oracle BPM studio.


In this article, you have learned how to transform a BPMN model from Oracle Business Process Analysis Suite to an executable BPEL process by generating a blueprint. When using this method, it is important to keep in mind the semantic differences between BPMN and BPEL. Generalization should be limited to the technical models: BPEL and services. This makes the process easier to change and easier to translate into BPEL.

Read more:

  • Oracle Business Process Analysis Suite Quick Start Guide
  • Recker, J., Indulska, M., Rosemann, M., Green, P. (2005): Do Process Modelling Techniques Get Better? A Comparative Ontological Analysis of BPMN. In B. Campbell, J. Underwood, D. Bunker (eds.): Proceedings of the 16th Australasian Conference on Information Systems. Australasian Chapter of the Association for Information Systems, Sydney, Australia. (
  • IBM Software Group’s introduction to BPMN

Lonneke Dikmans is an Oracle ACE Director and managing partner at Approach Alliance, a Dutch IT company specializing in SOA and BI.