Callback on ESB

Invoking a service asynchronously is something which is very often in a real world systems and scenarios. ESB allows both synchronous and asynchronous invocation, but all the articles and documentation available tells only about one way asynchronous invocation. At first, it appears that since ESB is stateless, it cannot hold the context and hence callback is not achievable. Implementation of this case gives the understanding that context handling is the task of bpel and not the ESB's. In this post let's look at how to invoke a service connected to an ESB in an asynchronous manner and then getting the response back via callback.

Scenario -
An async BPEL process 1 will invoke a routing service of ESB. Routing service calls the SOAP service on async BPEL process 2. This process then callback the route to BPEL process 1 on ESB (Routing Service --> process 1 SOAP service --> process 1).

Modify the client process wsdl to add a new operation as shown in image. This will be the operation which will be plugged to ESB as a soap service.

Create a routing service RS_In with its own interface/wsdl created by the routing service wizard. Also attach the service bpel to ESB by adding soap service. The routing service and soap service will now look like the one shown in image below.

Register the project to ESB.

Create a partner link of RS_In in client process, connect it with invoke. Add a receive activity below for the callback operation 'submitStockQuote' and connect it to the 'client' partner link. The final client bpel will look like -

Now create another routing service RS_Out and soap service to connect the service bpel to ESB. Connect the routing service with operation 'submitStockQuote' of the soap service. Final ESB project will look like -

Register the project to ESB.

Create a partner link of routing service RS_out in service bpel and associate it with the receive activity 'callbackClient'. The service bpel is as shown in image below.

The only thing remain here is correlation. Correlation is required at bpel and not at ESB. So create a new correlation set and assign it to invoke and receive of the client bpel. Following artifacts where created or modified while creating and assigning correlation.

processname_properties.wsdl

processname.bpel

processname.wsdl

Test and run the client bpel, two instances of ESB gets created as shown below -

XA transactions with Adapters in BPEL

XA transactions are 2-phase transactions normally used to manage and maintain transaction in a distributed environment. Adapters can be configured for global transactions, if they support the JCA transaction contract. In my first blog lets see how technology adapter (DB Adapter) can be configured to participate in global transaction of BPEL.

Environment: Oracle JDeveloper 10.1.3.2
Integration Server: Oracle SOA Suite 10.1.3.1.0

A BPEL is in place that invoke two DB Adapters, one to debit and another to credit an account. The debit and credit should happen as a single unit of work. These adapters uses different database and hence different datasources. Follow steps below to create datasources -

Oracle JDBC drivers are already available in application server as shared library "oracle.jdbc". If you are going to use third party database, then add the jdbc drivers as shared library. Go to oc4j home > Administration > Shared Libraries and add all jdbc jars.

Under "Applications Importing This Shared Library" section various applications are listed. Applications "ascontrol" and "default" are importing this library to allow us to test the connection of the datasource from the console. Import the shared library to "ascontrol" and "default" by manually adding the entries in "orion-application.xml" and "application.xml" respectively. These files can be found in -

\j2ee\home\application-deployments\ascontrol
\j2ee\home\config

Go to oc4j home > Administration > JDBC Resources and create a new connection pool. Make sure to use a XA datasource as shown in the image below. For Oracle, XA datasource class is - oracle.jdbc.xa.client.OracleXADataSource

Now create a managed datasource and select the newly created connection pool for default application. Provide a jndi name for the datasource like "jndi/OracleDataSource" and make sure to set transaction level as "Global & Local Transactions".

Till now shared library and datasource are established. Now modify the DB adapter deployment descriptor file "oc4j-ra.xml" to add the following entry -

See that the value of xADataSourceName property is the name of datasource created previously. The jndi location for connector-factory is "eis/DB/OracleDBConnection". This should match with the jndi name created by adapter configuration wizard of JDeveloper. See the image below -

Also import the shared library "oracle.jdbc" in oc4j-ra.xml.

Although not mandatory, you can comment the mcf properties in adapter wsdl. In case adapter won't find the jndi location in wsdl or in oc4j-ra.xml, it will fall back on mcf properties.

Change bpel.xml to allow db adapter to participate in bpel process transaction. Add the property "transaction" in bpel.xml as shown in image -

Restart the server and deploy the bpel process so that changes get reflected.

Test the bpel process such that second adapter throws a fault. The account debit done by first adapter should rollback.