EasyBPEL use-cases

This guide explains how to use EasyBPEL thanks to 2 use cases. These 2 use cases show main supported features.

For each use-case, a description and objectives (what is tested) is made. The first use-case is a concrete well-known use-case: Travel Agency booking. The second use-case is more technical and presents late-binding BPEL intrinsic features.

Petals Studio is used to build theses use-cases. We advise to use it since it contains a certain number of eases and, in particular, an embedded version of the BPEL validator tool provided by EasyBPEL.

You can get more information in the Easy BPEL Javadoc.

Travel Agency use-case

Summary

This use-case is a booking service corresponding to an orchestration process of 3 partners services. The client has to give his name and address, his departure and arrival dates and places.

The process returns to the client a message to indicate either the booking has successfully occurred and his reservation Ids, either the booking of one of the partners failed.

These partners are an airline booking service implemented by a Web Service, an hotel booking service implemented by a batch file deposit and the car booking service, that is based on a WSDL 2.0 description. The car booking service is implemented by a Web Service.

It can be noticed that there is no functional fault handling in this use-case. Although try/catch features have been already implemented, it is not used since compensation feature is not yet available. A further significant work will consist in adding compensation, that should be tested in this use-case.

Objectives

This process validates the flow activity, asynchronous invoke (thanks to the hotel partner), correlation and WSDL 2.0 compliance.

Description

You can find the needed files here (partners folder), that is to say the BPEL file, its WSDL and partners WSDLs. You should see the following BPEL process. 

In order to test this use-case, you can use this request for the first Receive:

For the asynchronous confirmation of the hotel, you can simulate it thanks to a xml file containing:

Be sure the lastname in this message is equal to the lastname of the first message, because of the correlation. Indeed, the correlation used in this use-case is defined here:

It is initialized in the invoke:

The correlation is set thanks to a property, defined in processArtifact.wsdl. This property is linked to at least two aliases:

Dynamic Invocation use-case

Summary

This use-case is useful to understand the invoke mechanism in BPEL. When a partner is defined, only the interface can be provided. The endpoint to call at run time can be dynamically defined. In this use-case, the endpoint (EndPointReference) is filled once thanks to a in message, once with a static assign.

Objectives

The process validates the dynamic assign of an endpoint.

Description

You have to create a SU for BPEL component thanks to Petals Studio thanks to needed files available here. The message to send as input of the BPEL process is the following:

You can see that an EndpointReference is embedded in this message. It corresponds to the endpoint of a service invoked during the BPEL process (called echoService). It is an address defined in a EndpointReference tag. The syntax is the service as a QName with the standard syntax, then the endpoint (or port) separated by "::":

Here is an example of assign to dynamically set an endpoint. If the "from" part would be defined thanks to a first invoke to a endpoints registry partner, we could have a real dynamic invocation at runtime: