Skip Headers

Oracle E-Business Suite Integrated SOA Gateway Developer's Guide
Release 12.1
Part Number E12065-06
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Understanding Basic BPEL Process Creation

Overview

To design a composite service, integration developers use a Web service composition language BPEL to specify the invocation sequence through Oracle BPEL Process Manager (PM). This composite service has its own WSDL definition and endpoint through the creation of a Partner Link which allows a business event, for example, to be published to the Oracle BPEL Process Manager or to interact with a partner service.

To efficiently utilize a BPEL process in orchestrating a meaningful business flow, the basic concept of creating a BPEL process is discussed in this section.

Understanding BPEL Business Processes

A BPEL process specifies the exact order in which participating Web services should be invoked either sequentially or in parallel. In a typical scenario, a BPEL process receives a request. To fulfill it, the process invokes the involved Web services and then responds to the original requestor. Because the BPEL process communicates with other Web services, it heavily relies on the WSDL description of the Web services invoked by the composite services.

For example, a BPEL process consists of steps that are placed in the exact order that will be invoked. And these steps are called 'activities'. Each activity represents basic construct and is used for a common task, such as use <invoke> activity to invoke a Web service; use <reply> to generate a response for synchronous operations.

Key Activities and Message Patterns

In supporting Web services and message exchanges over the Web, there are many communication patterns to model the processes. For example, a basic request - response pattern can be used in a synchronous or asynchronous way. A synchronous request - response pattern is one that waits for a response before continuing on; while an asynchronous request - response pattern does not wait for a response before continuing on which allows operations to occur in parallel until the response is ready. Another pattern can be request only operation that does not require response at all.

Based on the message patterns, appropriate activities representing various actions can be orchestrated in a meaningful way and enable the services.

To have better explanation about the message patterns and some key activities that are frequently used in a BPEL process, the following two message patterns are used to further describe how to build a simple BPEL process:

Synchronous Request - Response BPEL Process

For synchronous request-response service type, a consumer or client sends a request to a service, and receives an immediate reply.

Synchronous Request - Response Message Pattern

the picture is described in the document text

Many online banking tasks are programmed in request-response mode. For example, a request for an account balance is executed as follows:

The synchronous request-response interaction pattern interpreted in a BPEL process can be illustrated in the following diagram:

Synchronous Request-Response Interaction Pattern in BPEL

the picture is described in the document text

In the above diagram, there are two BPEL processes involved to complete the synchronous request-response service:

Partner Link

A partner link defines the location and the role of the Web services that the BPEL process connects to in order to perform tasks, as well as the variables used to carry information between the Web service and the BPEL process. A partner link is required for each Web service that the BPEL process calls.

Invoke Activity

An Invoke activity opens a port in the BPEL process to send and receive data. It uses this port to submit the required data and receive the response.

In the account balance inquiry example, the Invoke activity submits the account number entered by the customer to the server and receives dollar amount in return as the account balance. For synchronous callbacks, the Java rule function supports the feature through Business Event System. Thus, only one port is needed for both the send and receive functions.

Receive Activity

A Receive activity waits for an incoming request data as an input variable. For example, the Receive activity accepts the account balance inquiry by taking the account number as an input variable to the server.

Reply Activity

A Reply activity enables the business process to send a response message in reply to a message that was received through a Receive activity. For example, the Reply activity takes the account balance from the server as an output variable and sends it back to the requestor.

The combination of a receive and a reply forms a request-response operation.

Orchestrating a Synchronous BPEL Process

The composite BPEL process design flow should be orchestrated with necessary BPEL components or activities so as to successfully invoke a synchronous Web service.

Use the account balance inquiry as an example. The service invocation sequence can be orchestrated in Oracle JDeveloper BPEL Designer as shown in the following diagram:

the picture is described in the document text

  1. A client sends the request by entering account number for the balance inquiry.

  2. The Receive activity receives it as an input variable.

  3. The Assign activity takes the account number and passes it to the Invoke activity.

  4. The Invoke activity submits the account number entered by the client to a ActBalanceService Partner Link and receives dollar amount in return as the account balance.

  5. The Assign activity then takes the dollar amount as an input variable and passes it to the Reply activity.

  6. The Reply activity takes the account balance and replies to the requestor.

The above composite service - BPEL process requires the following tasks at the design time:

Once a Partner Link is successfully added to a synchronous BPEL project, a WSDL description URL that corresponds to the ActBalanceService business event service with appropriate event payload will be automatically generated. This ActBalanceService Partner Link serves as a bridge to communicate information between the service and the synchronous BPEL project.

Note: The generated WSDL URL of a BPEL process can also be used in defining an event subscription if the BPEL process is used for service invocation through the Business Event System.

One-Way BPEL Process

For One-way or request only service type, there is only one input element which is a client's request for a service and no response is expected.

Request Only Message Pattern

the picture is described in the document text

For example, a stock symbol sends updated price to the stock quote service when the price change using the request only operation. The server updates the stock price but no response is sent back.

This type of interaction pattern interpreted in a BPEL process can be illustrated in the following diagram:

One-Way (Request Only) Interaction Pattern in BPEL

the picture is described in the document text

The following two BPEL processes are involved in this type of service:

In the stock quote update example, the Invoke activity submits a stock symbol along with a market price to the StockQuote service in a server. The Receive activity takes the new price as an input and update the StockQuote service.

The following diagram illustrates the service invocation sequence for the stock update example in Oracle JDeveloper BPEL Designer:

the picture is described in the document text

  1. A client sends the stock symbol and updated price.

  2. The Receive activity receives it as an input variable.

  3. The Assign activity takes the new price and passes it to the Invoke activity.

  4. The Invoke activity submits a stock symbol along with an updated price to the StockQuoteService Partner Link in a server.

This composite service - BPEL process requires the following tasks at the design time:

Like synchronous request - response operation, once a Partner Link is successfully added to a BPEL project, a WSDL description URL that corresponds to the service with appropriate event payload will be automatically generated.