The BPEL language

This page gives a short introduction to the possibilities offered in the BPEL4WS 1.1 specification. This introduction will start with a very simple explanation of a BPEL process. After this explanation the BPEL standard will be explained in more detail.

At the moment there's already a draft available of the WS-BPEL 2.0 specification. Because that specification isn't ready yet, we won't describe it on this page.

BPEL is build on the WSDL 1.1 specification. Basically BPEL offers a way to describe and orchestrate peer-to-peer interaction between Web Services that are defined with WSDL. On this page we won't go into all the technical details of BPEL, but we'll try to give enough information so that a beginner can get a good start with BPEL.

There are several code examples on this page and there are some specific names used in these examples. The name ncname and qname are used to show to what format these names must fulfill. A ncname is a name that must always begin with letter or an underscore. After the first character letters, numbers and special characters can be used. A qname is a ncname that also shows from what XML namespace it is. So a qname must always be in the format tns:ncname where tns is the name of the namespace that is defined at the beginning of the document.

Basics

The figure below shows a simple BPEL process based on the situation earlier explained on the usage page. It's advised that you first read the explanation on the usage page before continuing with the text here. The process shown in the figure is pretty simple. All it does is wait until it's started by the ERP system. When the ERP systems starts the process it has to give some localization settings. The first step in the process after the receive is to switch the localization setting. When this is usa a certain firmware needs to be installed, so the provisioning server is called to do so. If the localization is set to france, then the process will invoke the provisioning server to install other firmware for machines going to France. After the firmware is installed, the process returns a status to the ERP.

View of the example process

A heavily simplified form of this process in BPEL would look something like the code below.

As you can see a BPEL process is build using the XML notation. A process always has to start with a process element. After the process element there first is a receive. This receive has the attribute createInstance set to yes. This enables this receive to start a new instance of the BPEL process. When the receive is called upon, the process walks through the different elements sequentially. In the switch there are two cases. One case for usa and one for france. In this simplified version of the process both seem to do the same, but when this process was real there would probably be some variable given with the invoke to let the provisioning server know which firmware to install.

After the provisioning server is invoked a status is returned to the ERP system by the reply element. The status would have probably been the value returned by the invoke on the provisioning server. After the reply element the process can be closed.

Structure

As already shown in the simplified example above, a BPEL process always starts with the process element. In the process element there has to be at least one activity. An activity can be a basic activity or a structured activity, both are explained on this page.

<process name="ncname">
activity
</process>

In the process element there are several attributes that can be added to control different options of the process. The most important properties that can be set are: the language to use with XML queries, the language to use for expressions, the option to suppress join failures and to setup that the process is abstract. In these pages we won't further explain abstract processes and only focus on executable processes.

Partners

An important part of the use of BPEL is the description of business process interaction between partners communicating with Web Services. To connect these partners it's important that relationships can be specified between these partners. Every partner that is involved with the interaction of the BPEL process has to have a WSDL description file that describes how you can communicate with this partner.

PartnerLink

In BPEL a Web Service that is involved in the process is always modeled as a partnerLink. Every partnerLink is characterized by a partnerLinkType which is defined in the WSDL definition. A partnerLinkType specifies the role and the type of a partner.

Every partnerLink has to have a unique name that can be used to identify the partnerLink. The role of the process is specified by the attribute myRole and the role of the partner is specified by the attribute partnerRole. When a partnerLinkType is used with only one role, then one of these attributes can be discarded.

Data manipulation

In BPEL it's possible to use variables. A variable is always connected to a message from a WSDL. When the message in a WSDL file is structured like the message in following code example:

Then this message can be used in BPEL in the following way:

Variables

Variables offer the possibility to store messages that hold the state of the process. The messages that get stored are most of the time either coming from partners or going to partners. Variables also offer the possibility to store data that is only state based and never send to partners.

There are three types of variables: WSDL message type, XML Schema simple type and XML Schema element. The syntax of a variable declaration is shown in the code example below.

The name of a variable has to be unique in it's own scope. The messageType, type or element attributes can be used to specify the type of the variable. Exactly one of there attributes has to be used. The attribute messageType refers to a WSDL message type definition. The attribute type refers to a XML Schema simple type. The attribute element refers to a XML Schema element.

Every variable has to be declared in a certain scope and only belongs to this scope and underlying scopes. A variable that has been declared in the highest scope (global) is visible through the entire process.

Reading from variables

Most of the times variables are used to send and receive information, but BPEL also gives the possibility the read the content of a variable in the process. This can be done with an extension which is defined in the BPEL namespace. In the extension offered in the BPEL XML Schema, which can be found on http://schemas.xmlsoap.org/ws/2003/03/business-process/, is a function getVariableProperty. This function can read a value from a variable as shown in the code example below.

getVariableProperty ('variableName','propertyName')

This function can for example be used in an expression within the process.

Assignment

Copying the data from one variable to the other is something that will happen very often in a business process. Copying data can be achieved with the assign activity. This activity can also be used to copy new data into a variable.

The to and from attributes can also be changed to copy from other places. For example, you could copy from a partnerLink to a certain variable. More information on the different attributes that can be used in the assign can be found in the BPEL specification.

Basic activities

Every basic activity has several standard attributes and elements that can be used to specify certain properties. In the explanation on this page we will not get into all the options offered by these attributes and elements. More information about these can be found in the BPEL specification.

Invoke

With an invoke activity a process can call an other Web Service that has been defined as a partner. The invoke can be either asynchronous or synchronous.

An asynchronous invoke only needs to specify an input variable, this because there is no direct reaction and thus no output variable. A synchronous invoke needs both an input and an output variable. In an executable business process these in and output variables are required. A synchronous invoke can return a WSDL error message. This will result in a BPEL error. Such an error could be handled locally. When the fault isn't captured then it's given to the scope.

Receive

A business process offers services to it's partners by receive and matching reply activities. A receive activity specifies a partnerLink, a portType and an operation that can be invoked. There is also an attribute in which a variable can be specified.

The receive activity plays an important role in the life cycle of a business process. One of the ways to initiate a process is by way of a receive activity with the attribute createInstance set to yes. The default value of this attribute is no. A receive activity with createInstance set to yes must be one of the initial activities of a process. It's permitted to have multiple activities with createInstance set to yes. In this case the first activity that is called will initiate the process.

A process shouldn't contain two receive activities that have the same partnerLink, portType, operation and correlationSet.

Reply

A reply activity is used for sending a response after a receive activity has been called. The reply is only useful in a synchronous interaction. A asynchronous reaction always has to be given by use of an invoke. With the reply activity it's also possible to transfer data by specifying a variable. A reply activity can only be placed after a receive or a onMessage activity with the same partnerLink, portType and operation.

Signaling faults

When the process wants to report an internal fault, the throw activity can be used. Every fault must have a globally unique qname. In the fault activity this name must be defined together with a faultVariable. The faultVariable contains further information about the fault. When handling the fault this information could be used to analyze the generated fault en notify other other partners of this fault.

Waiting

The wait activity offers the possibility to build in a certain time to sleep or wait till a specified deadline has passed.

Doing nothing

There are situations where it's necessary that a process does nothing. This could happen when you want to catch a fault, but then want to suppress it. In this case you can use the empty activity.

Structured activities

Structured activities offer a way to structure a BPEL process. They describe the flow of a process by structuring basic activities. In this way control patterns, data flow, fault handling and coordination of messages can be achieved.

The structured activities of BPEL are:

Basic sequence control between activities is offered by the sequence, switch and while activities.
Synchronization and concurrency of activities is offered by the flow activity.
A choice based on information from the outside is offered by the pick activity.

Structured activities can be used recursive and it's important to see that structured activities can be used in anyway to create process flow. On this web page we will refer to both basic and structured activities with the word activity.

Sequence

A sequence activity has one or more activities that are executed sequential in the order they are placed within the sequence element. The sequence activity stops when all activities within it are done.

<sequence>
activities
</sequence>

Switch

The switch activity makes it possible to specify conditional behavior. This activity consists out of an ordered list of conditional branches. Every branch is specified by a case element followed by one optional otherwise element. The case elements in a switch are looked at in the order in which they are placed. The activities specified in the case are executed when the condition of the case is true. When none of the cases are true, the activities in the otherwise element are executed. The switch activity is done when all the activities of one of the branches are completed.

<switch>
   <case condition="bool-expr">
     activity
   </case>
   <otherwise>
     activity
   </otherwise>
</switch>

While

The while activity offers the possibility to walk through certain activities in an iterative way. The activities in the while activity are executed as long as the boolean expression in the condition attribute is true.

<while condition="bool-expr">
activity
</while>

Pick

The pick activity waits till one event in a set of events occurs. When an event occurs the activities associated with that event are executed. When more that one event occurs only the event that occurs first is being processed. Possible events are the arrival of a message or a timer.

Like a receive activity, a pick can be placed at the beginning of a process and set as the initiator of a process by setting the createInstance attribute to yes. If this is the case, then only incoming message events can be placed in this pick activity, timer events are not permitted. Every pick activity needs to have at least one onMessage activity. The onMessage activity works the same as a receive activity, so there can also be a reply with an onMessage activity.

<pick createInstance="yes|no">
   <onMessage partnerLink="ncname"
              portType="qname"
              operation="ncname"
              variable="ncname">
     activity
   </onMessage>
   <onAlarm (for="duration-expr" | until="deadline-expr")>
     activity
   </onAlarm>
</pick>

The pick activity is done when all the activities in the started event are completed.

Flow

The flow activity makes it possible to execute several activities parallel. A flow activity is done when all the activities in it are done. One of the possibilities offered by a flow activity is the synchronization of activities within the flow. More information on how this is done can be found in the BPEL specification.

<flow>
activities
</flow>

Correlation

Because a business process is communicating with multiple services and these services could also be communicating with other services, it's important to make sure that you are always talking with the right instance of a service. To realize this in BPEL you could make use of correlation. Correlation offers the possibility to make sure you always talking to the same instance of a service by adding identifying variables. When the process is invoked, these variables always have to be supplied to make sure it's the same process you where talking to earlier on.

Scope

BPEL uses scopes to split the process up into several parts. These parts all have the possibility to create their own variables. In a scope their can be made a new scope. The variables in this new scope are not visible by it's parent, but the variables of the parent are visible in the child scope. The variables of the global scope are thereby available through out the entire process. Every scope offers a compensation handler, a fault handler and an event handler.

Compensation handler

With a compensation handler it's possible to define a set of activities that have to be executed when there is a problem in the process. The compensation handler can be started from the process itself to undo certain steps that have already been completed. An other use of the compensation handler is to define alternative steps that need to be done when a certain event happens. More information about the compensation handler can be found in chapter 13.3 of the BPEL 1.1 specification.

Fault handler

The optional fault handlers that can be attached to the scope, define a set of fault handling activities, so called catch activities. A catch activity catches a fault by it's faultName en faultVariable. When a fault occurs without a faultName, then the fault will be associated with every faultHandler that has the same type of faultVariable. Next to the catch activities, there is also one catchAll activity that catches all the fault that are not handled by the defined catch activities.

<faultHandlers>
   <catch faultName="qname" faultVariable="ncname">
     activity
   </catch>
   <catchAll>
     activity    </catchAll>
</faulHandlers>

When no catch or catchAll activities are provided, the fault will be given to the parent scope. When the fault isn't caught by the global scope, then the process will stop with a terminal activity.

Event handler

It's possible to attach an event handler to every scope in a process. This event handler can specify what to do when certain events happen. There are two types of events that are both already explained earlier on at the pick activity. The onMessage and onAlarm event. It's important to understand that the event handler is a normal part of the scope that is enabled when it's there. It stands loose from the rest of the activities in the scope so when there are activities in the scope active, it's still possible to receive an event in the event handler.

<eventHandlers>
   <onMessage partnerLink="ncname"
              portType="qname"
              operation="ncname"
              variable="ncname"
     activity
   </onMessage>
   <onAlarm (for="duration-expr" | until="deadline-expr")>
     activity
   </onAlarm>
</eventHandlers>

Go back to the main page