Business Flows with BPEL4WS

Jan. 1, 2000 12:00 AM

Business Flows with BPEL4WS

BPEL4WS is now moving rapidly into becoming the de facto standard for Web service orchestration with most platform vendors following in IBM and Microsoft footsteps after the submission of the specification to OASIS. This increased momentum and visibility will drive a great need for educating developers on how to put BPEL to work.

This article illustrates a payment flow example coded using BPEL, highlighting some of the main constructs of the language and demonstrating how the flow can be monitored and managed once it is deployed. The example can be extended in various ways to include more advanced language constructs. Such extensions will be illustrated in subsequent articles.

Business Flow Example

The PayFlow business flow example illustrated in this article is comprised of a client initiating a request to a BPEL process and ending with the process calling back the client with the result of the payment request (receipt). The process includes use of <receive> and <invoke> activities for interacting with the outside world which includes the client (request) and a partner (payment processor service). XML Variables are used for holding messages exchanged between the process and the partners. To make this example interesting, the payment processor service is asynchronous and can take anywhere from several minutes to several days before the service calls back the process. Another interesting element demonstrated by this example is the handling of exceptions and managing of timeouts. These constructs are instrumental to enable a BPEL process to deliver reliable business flows.

The client initiating the PayFlow process specifies a transfer amount in dollars. The PayFlow process receives the transfer request and leverages an asynchronous payment processor to carry out the fund transfer. The payment processor is asynchronous because it requires a manual review prior to returning the result to the process (though note that this fact is opaque to the PayFlow process which uses the service - PayFlow just knows that PaymentProcessor is an asynchronous and potentially long-running service).

The payment processor service, as implemented, will return a normal result if the amount is less than $500. Otherwise, it will return a "transfer refused" fault, which will be handled as an exception by the PayFlow BPEL process. PayFlow also handles an "insufficient funds" fault, which may be thrown by the service. In addition, the PayFlow process specifies a timeout period and terminates if the payment processor takes more than 2 days (the timeout limit) to return a digital receipt indicating a successful fund transfer.

Creating Service Descriptions with WSDL

PaymentProcessor WSDL file

The asynchronous payment processor service provides the following operations: initiate, getStatus and pollResult, grouped under the PaymentProcessorService portType.

The payment processor service also provides the operations onResult, onInsufficientFundException and onTransferRefusedException, grouped under the PaymentProcessorServiceCallback portType. Note that these callback operations will actually be invoked on the client of the service - in this case the PayFlow process.

The payment processor WSDL file defines BPEL partner links for the service. The links associate roles with portTypes for the payment processor service ("service") and for callbacks on its client ("requester").

<plnk:partnerLinkType name="PaymentProcessorService">
<plnk:role name="PaymentProcessorServiceService">
<plnk:portType name="tns:PaymentProcessorService" />
</plnk:role>
<plnk:role name="PaymentProcessorServiceRequester">
<plnk:portType name="tns:PaymentProcessorServiceCallback" />
</plnk:role>
</plnk:partnerLinkType>

You can view the complete contents of the PaymentProcessorService WSDL file, including the details of the input and output messages for the operations described above.

PayFlow WSDL File

The PayFlow BPEL process provides the following operations: initiate, pollResult and PayFlowCallback, grouped under the PayFlow portType.

The PayFlow WSDL file defines BPEL partner links for the process. The links associate roles with portTypes for the PayFlow process and for callbacks on its client ("requester").

<plnk:partnerLinkType name="PayFlow">
<plnk:role name="PayFlowService">
<plnk:portType name="tns:PayFlow"/>
</plnk:role>
<plnk:role name="PayFlowRequester">
<plnk:portType name="tns:PayFlowCallback"/>
</plnk:role>
</plnk:partnerLinkType>

The PayFlow process WSDL defines types to be used for messages exchanged between the process and its partners. These types include PaymentRequest, comprised of five (5) fields (the last of which is the transfer amount, to be discussed later in the BPEL process logic section) and DigitalReceipt, comprised of three (3) fields (the last of which references PaymentRequest).

You can view the complete contents of the the PayFlow WSDL file, including the details of the input and output messages for the operations described above.

Creating the Process with BPEL

After defining the process WSDL and examining the partner WSDL, we can now turn to defining the process logic using BPEL. First, we need to define the namespaces, which will allow the process to refer to the message types defined within the WSDL files and qualify other names appropriately.

Next, we need to declare the parties involved in the process, each associated with a partnerLinkType and up to two roles, myRole and partnerRole, which describe the relative roles the process and the partner play, respectively. The parties involved here include the PayFlow process client PayFlowRequestor and the payment processor service PaymentProcessorService. For each partnerLink, myRole is the role of the PayFlow BPEL process.

In order to facilitate the interactions between the process and the partners, we need to define XML Variables, which will contain the messages used to communicate with the partners.

Based on the requirements of the PayFlow process, it receives an initiatePayFlowSoapRequest message as input, communicates with the payment processor asynchronously through request and response messages, needs to handle transfer-refused and a insufficient-funds faults, and finally provides a digital receipt at the conclusion of its execution.

The PayFlow process is essentially a sequence of activities, meaning the activities should be executed serially. We first add a <receive> activity to the sequence in order to take the client message and put it in the input XML variable. The <receive> activity indicates that a new process instance is to be created upon receiving a message at portType PayFlow for operation initiate.

After receiving the client message, the process proceeds to start the main sequence for processing the payment flow. This <sequence> activity is enclosed within a <scope> that defines a catchall fault handler for terminating the process upon encountering a network error while interacting with an external service. The sequence starts by copying the client request from the input variable to the request variable used for sending it to the payment processor.

Once client request has been copied into the request variable, we can now use the <invoke> activity to pass the request to the PaymentProcessor partner specifying request as its input parameter. The payment processor invocation is asynchronous meaning that the invoke activity does not return or wait for a result. For handling the asynchronous replies from the payment processor, the BPEL PayFlow process uses the <pick> activity, which picks up messages coming as callbacks from the PaymentProcessor partner, saving the messages in the response variable. Upon receiving a message as a result of the payment processor normal execution, it is copied from the response variable to the digitalReceipt variable.

Other messages received by the <pick> activity may also include transfer-refused (in case the transfer amount exceeds $500) and insufficient-fund faults (in case the client SSN# provided is invalid). These messages are stored in their respective variables associated with onTransferRefusedException and onInsufficientFundException. In addition to handling exceptions, the BPEL process also provides for timeout management, in case the result from the payment processor is not received within 2 days of invoking it. A timeout alarm in this case will trigger the <terminate> activity and abort the process execution. Note that a real-world process could have any arbitrary logic executed upon a timeout alarm. That completes the <scope> activity containing the payment processor interaction set.

Finally, in order for the PayFlow process to respond to its client's request asynchronously, it uses an activity to invoke a callback operation on the client. The result stored by the digitalReceipt variable is passed as a message to the client using the onResult operation of the callback portType. After the invocation, the process is ended.

Running the Process The PayFlow business flow can be run online using Collaxa's hosted BPEL console or by downloading Collaxa's BPEL Orchestration Server and deploying the above sample (included as part of the software package). Whether using the online console or the locally installed software, the following BPEL console window will show the PayFlow BPEL process:

Clicking on the PayFlow BPEL process leads to the test interface initiating the business flow:

We can try an amount less than $500 for testing normal process execution. The sequence looks like this:

We can also try an amount larger than $500 for observing the process behavior when an exception occurs:

After initiating the flow, we can follow the visual flow, textual audit trail and debug/inspect links to see what happens behind the scenes during execution of the BPEL process. Manual approval is accomplished using the payment processor service form, in order to allow the PaymentProcessorService service instance and subsequently, the PayFlow process instance, to continue execution.

Resources

BPEL4WS Fast Facts, including BPEL 1.1 and OASIS submission perspective
Learn the basics of BPEL4WS in this BPEL 101 Tutorial (followed perhaps by reading the BPEL 1.1 specification).
And... many more BPEL samples for your perusal and further experimentation.

About Doron Sherman
Doron Sherman is the CTO of Collaxa, Inc., a Web Service Orchestration Server vendor and a BEA Partner located in Redwood Shores, California. He has been involved with Java since its early days and pioneered application server technology while being a founder and chief scientist at NetDynamics.