(For more resources on BPEL, SOA and Oracle see here.)

BPEL business process example

We describe an oversimplified scenario, where the client invokes the business process, specifying the name of the employee, the destination, the departure date, and the return date. The BPEL business process first checks the employee travel status. We will assume that a service exists through which such a check can be made. Then the BPEL process will check the price for the flight ticket with two airlines—American Airlines and Delta Airlines. Again we will suppose that both airline companies provide a service through which such checks can be made. Finally, the BPEL process will select the lower price and return the travel plan to the client.

For the purpose of this example, we first build a synchronous BPEL process, to maintain simplicity. This means that the client will wait for the response. Later in this article, we modify the example and make the BPEL process asynchronous. We will assume that the service for checking the employee travel status is synchronous. This is reasonable because such data can be obtained immediately and returned to the caller.

To acquire the plane ticket prices we use asynchronous invocations. Again, this is reasonable because it might take a little longer to confirm the plane travel schedule. We assume that both airlines offer a service and that both Web Services are identical(provide equal port types and operations). This assumption simplifies our example. In real-world scenarios, you will usually not have the choice about the services but will have to use whatever services are provided by your partners. If you have the luxury of designing the Web Services along with the BPEL process, consider which is the best interface. Usually we use asynchronous services for long-lasting operations and synchronous services for operations that return a result in a relatively short time. If we use asynchronous services, the BPEL process is usually asynchronous as well. In our example, we first develop a synchronous BPEL process that invokes two asynchronous airline Web Services. This is legal, but not recommended in real-world scenarios since the client may have to wait for an arbitrarily long time. In the real world, the solution would be to develop an asynchronous BPEL process, which we will cover later in this article.

We invoke Web Services of both airlines concurrently and asynchronously. This means that our BPEL process will have to implement the callback operation (and a port type), through which the airlines will return the flight ticket confirmation.

Finally, the BPEL process returns the best airline ticket to the client. In this example, to maintain simplicity, we will not implement any fault handling, which is crucial in real-world scenarios.

Let's start by presenting the BPEL process activities using a UML activity diagram. In each activity, we have used the stereotype to indicate the BPEL operation used.

Although the presented process might seem very simple, it will offer a good start for learning BPEL. To develop the BPEL process, we will go through the following steps:

• Get familiar with the involved services
• Define the WSDL for the BPEL process
• Define partner link types
• Define partner links
• Declare variables
• Write the process logic definition

Involved services

Before we can start writing the BPEL process definition, we have to get familiar with all services invoked from our business process. These services are sometimes called partner services. In our example, three services are involved:

• The Employee Travel Status service
• The American Airlines service
• The Delta Airlines service

The two airline services share equal WSDL descriptions.

The services used in this example are not real, so we will have to write WSDLs and even implement them to run the example. In real-world scenarios we would obviously use real Web Services exposed by partners involved in the business process.

The services and the BPEL process example can be downloaded from http://www.packtpub.com The example runs on the Oracle SOA Suite.

Web Service descriptions are available through WSDL. WSDL specifies the operations and port types Web Services offer, the messages they accept, and the types they define. We will now look at both Web Services.

Employee Travel Status service

Understanding the services that a business process interacts with is crucial to writing the BPEL process definition. Let's look into the details of our Employee Travel Status service. It provides the EmployeeTravelStatusPT port type through which the employee travel status can be checked using the EmployeeTravelStatus operation. The operation will return the travel class an employee can use—economy, business, or first. This is shown in the following figure:

The operation is a synchronous request/response operation as we can see from the WSDL:

<?xml version="1.0" encoding="utf-8" ?>
<definitions

targetNamespace="http://packtpub.com/service/employee/"

>
...
<portType name="EmployeeTravelStatusPT">
<operation name="EmployeeTravelStatus">
<input message="tns:EmployeeTravelStatusRequestMessage" />
<output message="tns:EmployeeTravelStatusResponseMessage" />
</operation>
</portType>
...

The EmployeeTravelStatus operation consists of an input and an output message. To maintain simplicity, the fault is not declared. The definitions of input and output messages are also a part of the WSDL:

...
<message name="EmployeeTravelStatusRequestMessage">
<part name="employee" element="tns:Employee" />
</message>
<message name="EmployeeTravelStatusResponseMessage">
<part name="travelClass" element="tns:TravelClass" />
</message>
...

The EmployeeTravelStatusRequestMessage message has a single part—employee of element Employee with type EmployeeType, while the EmployeeTravelStatusResponseMessage has a part called travelClass, of element TravelClass and type TravelClassType. The EmployeeType and the TravelClassType types are defined within the WSDL under the &lttypes> element:

...
<types>
<xs:schema elementFormDefault="qualified"
targetNamespace="http://packtpub.com/service/employee/">

<xs:complexType name="EmployeeType">
<xs:sequence>
<xs:element name="FirstName" type="xs:string" />
<xs:element name="LastName" type="xs:string" />
<xs:element name="Department" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:element name="Employee" type="EmployeeType"/>
...

EmployeeType is a complex type and has three elements: first name, last name, and department name. TravelClassType is a simple type that uses the enumeration to list the possible classes:

...
<xs:simpleType name="TravelClassType">
<xs:restriction base="xs:string">
<xs:enumeration value="Economy"/>
<xs:enumeration value="Business"/>
<xs:enumeration value="First"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="TravelClass" type="TravelClassType"/>
</xs:schema>
</types>
...

Now let us look at the airline service.

Airline service

The Airline Service is an asynchronous web service. Therefore, it specifies two port types. The first, FlightAvailabilityPT, is used to check the flight availability using the FlightAvailability operation. To return the result, the service specifies the second port type, FlightCallbackPT. This port type specifies the FlightTicketCallback operation.

Although the Airline Service defines two port types, it only implements the FlightAvailabilityPT. FlightCallbackPT is implemented by the BPEL process, which is the client of the web service. The architecture of the service is schematically shown as follows:

Flight Availability port type

FlightAvailability is an asynchronous operation, containing only the input message.

<?xml version="1.0" encoding="utf-8" ?>
<definitions

targetNamespace="http://packtpub.com/service/airline/"

>
...
<portType name="FlightAvailabilityPT">
<operation name="FlightAvailability">
<input message="tns:FlightTicketRequestMessage" />
</operation>
</portType>
...

The definition of the input message is shown as follows. It consists of two parts—the flightData part and the travelClass part:

<message name="FlightTicketRequestMessage">
<part name="flightData" element="tns:FlightRequest" />
<part name="travelClass" element="emp:TravelClass" />
</message>

The travelClass part is the same as that used in the Employee Travel Status service. The flightData part is of element FlightRequest, which is defined as follows:

...
<types>
<xs:schema elementFormDefault="qualified"
targetNamespace="http://packtpub.com/service/airline/">

<xs:complexType name="FlightRequestType">
<xs:sequence>
<xs:element name="OriginFrom" type="xs:string" />
<xs:element name="DestinationTo" type="xs:string" />
<xs:element name="DesiredDepartureDate" type="xs:date" />
<xs:element name="DesiredReturnDate" type="xs:date" />
</xs:sequence>
</xs:complexType>
<xs:element name="FlightRequest" type="FlightRequestType"/>
...

FlightRequestType is a complex type and has four elements through which we specify the flight origin and destination, the desired departure data, and the desired return date.

Flight Callback port type

The Airline Service needs to specify another port type for the callback operation through which the BPEL process receives the flight ticket response messages.

The service will only specify this port type, which is implemented by the BPEL process.

We define the FlightCallbackPT port type with the FlightTicketCallback operation, which has the TravelResponseMessage input message:

...
<portType name="FlightCallbackPT">
<operation name="FlightTicketCallback">
<input message="tns:TravelResponseMessage" />
</operation>
</portType>
...

TravelResponseMessage consists of a single part called confirmationData:

...
<message name="TravelResponseMessage">
<part name="confirmationData" element="tns:FlightConfirmation" />
</message>
...

Now that we are familiar with both services, we can define the BPEL process. Remember that our BPEL process is an actual web service. Therefore, we first have to write the WSDL for the BPEL process.

<xs:complexType name="FlightConfirmationType">
<xs:sequence>
<xs:element name="FlightNo" type="xs:string" />
<xs:element name="TravelClass" type="tns:TravelClassType" />
<xs:element name="Price" type="xs:float" />
<xs:element name="DepartureDateTime" type="xs:dateTime" />
<xs:element name="ReturnDateTime" type="xs:dateTime" />
<xs:element name="Approved" type="xs:boolean" />
</xs:sequence>
</xs:complexType>
<xs:element name="FlightConfirmation"
type="FlightConfirmationType"/>
</xs:schema>
</types>

WSDL for the BPEL process

The business travel BPEL process is exposed as a service. We need to define the WSDL for it. The process will have to receive messages from its clients and return results. So it has to expose a port type that will be used by the client to start the process and get the reply. We define the TravelApprovalPT port type with the TravelApproval operation, as shown in the following figure:

We have already said that the BPEL process is synchronous. The TravelApproval operation will be of synchronous request/response type.

<?xml version="1.0" encoding="utf-8" ?>
<definitions

targetNamespace="http://packtpub.com/bpel/travel/"

>
...
<portType name="TravelApprovalPT">
<operation name="TravelApproval">
<input message="tns:TravelRequestMessage" />
<output message="aln:TravelResponseMessage" />
</operation>
</portType>
...

We also have to define messages. The TravelRequestMessage consists of two parts:

• employee: The employee data, which we reuse from the Employee Travel Status service definition
• flightData: The flight data, which we reuse from the airline service definition

...
<import namespace="http://packtpub.com/service/employee/"
location="./Employee.wsdl"/>
<import namespace="http://packtpub.com/service/airline/"
location="./Airline.wsdl"/>
...
<message name="TravelRequestMessage">
<part name="employee" element="emp:Employee" />
<part name="flightData" element="aln:FlightRequest" />
</message>
...

For the output message, we use the same message used to return the flight information from the airline service: the TravelResponseMessage defined in the aln namespace. This is reasonable because the BPEL process will get the TravelResponseMessage from both airlines, select the most appropriate (the cheapest), and return the same message to the client. As we have already imported the Airline WSDL, we are done.

When writing the WSDL for the BPEL process, we usually do not define the binding (&ltbinding>) and the service (&ltservice>) sections. These are usually generated by the BPEL execution environment (BPEL server).

Before we can start writing the BPEL process, we still need to define partner link types.