By Santosh Malik [Dec-07]

Unlike Oracle BPEL Process Manager, Siebel does not support async web service interactions. Using sync interactions can be an issue for long running BPEL Processes, which sometimes can take days, and this can, load up not only BPEL, but also Siebel Object Manager. In this blog, we will describe how to mimic async interactions between Siebel and Oracle BPEL Process Manager.

The solution is to create two BPEL Processes. This is a two-step interaction: one process receives Siebel payload and returns acknowledgement. Second process completes processing and update status in Siebel. In our solution we send the payload to the Order Receiving Process (ORP). What we do here is just update the status to "Submitted" and return the acknowledgement. In Siebel the Order status is updated. At the same time, the Order Receiving Process invokes the BPEL Order Booking Process, which is an asynchronous invocation. Finally when the Order Booking Process completes, it invokes an inbound web service in Siebel, which then updates the status to "Complete".

What activities to perform in the first process and what to leave for the second is an architectural choice. We don't want our Siebel Call Center application to wait for the final response. Common tasks to perform in receiving process are Order validation and optionally any transformation to canonical. Once we have confirmed that a valid order is received, we can return a response to Siebel. Here is a sample SiebelOrderReceivingProcess.wsdl. All the complex processing is being done in the secondary BPEL process that might take its own time. In fig.1, you can see that the secondary BPEL process is set as an external web service or a partner link in the primary BPEL process. This partner link can be a pure web service, a BPEL process or an ESB service. The partner link is established using the wsdl provided for the target service. Here is a sample BPEL process invoked using partner link OrderBookingProcess.wsdl Achieving this kind of abstraction reduces some of the heavy processing in the primary BPEL process and pushes it to the secondary BPEL process(es) keeping the overall functionality unchanged.

Now once we are able to invoke the secondary BPEL process, we can go ahead and complete the designated tasks. In our case, we can perform a database transaction, invoke an external web services, and interact with human workflow or another ESB layer. Once the desired result is achieved, we need to notify Siebel Application that the request was indeed processed and completed. If you look at fig.2, a simple web service invocation in the secondary BPEL process (usually towards the end) with updated status is performed using Siebel Inbound Web Service. We can design our own business services in Siebel Infrastructure or make use of existing ones. Here is a sample Siebel Inbound Web service SiebelUpdateOrderWS.wsdl The point here is to complete the synchronous loop that was initiated by a synchronous invocation.

This is not a request-reply because there is no automatic correlation. BPEL handles correlation using manually using Order ID. The only way we interact with Siebel and BPEL is by using the unique order-id. The mechanism is synchronous invocation which triggers an asynchronous artifact but the seamless interaction gives us the feel of synchronous behavior even though the point to note here is that this synchronous callback is rather late one and not immediate!

To summarize, we have broken down a complex process into two sub-processes. The primary BPEL process handles just the acknowledgement part and invokes the secondary BPEL process. This secondary BPEL process then completes the required tasks and finally makes a callback to Siebel application and provides a final acknowledgement.