Handling Service Calls from Oracle BPM

In this posting I explain why in Oracle BPM Suite 11g you should consider using reusable subprocesses to handle service calls. The example is based on a synchronous service, but the same holds for asynchronous and fire & forget services.

If you have never experienced during process design with BPMN that the final process model became twice, if not three times more complex than you thought it would be, than you haven't been doing process design for real. You might for example have experienced how, what initially looked like a simple service call, finally exploded in your face. Let me tell you how it did in mine. I made up the example I'm using, but it is not far from reality.

It all started with a simple call to a synchronous service to store an order using some Insert and Update Order Service, or Upsert Order for short. The initial process model looked as simple as this.

This process is kicked off as a service with some initial customer data, after which a SalesRep enters an order that then gets stored using the Upsert Order service. But then I found that to use this service, I had to instantiate some custom request header. So I had to add a Script activity, as you cannot do that in the Service activity itself. The result was this:

But now I was exposing technical aspects in a business process, so to prevent the business audience to get distracted from that, I hid the complexity inside an embedded Store Order subprocess, like this:

And inside the embedded subprocess like this:

 
So far so good. But then I found that I also had to create a message id, log the request and response message, and catch exceptions to forward them to a generic exception handling process because the business might be involved to solve data issues. So before I knew it, my embedded subprocess looked something like this:

Hurray for the embedded subprocess, which hid all this complexity! But then I had to call the same Upsert Order service a second time, requiring me to do all the wiring again. Arghh!! Which brought me to the "brilliant" idea of pushing all this logic to a reusable subprocess, like this:

So in the business process itself, I only have to map the (context-specific) request and response messages to and from, what now has become the generic, and reusable wiring of the service call, like this:

Now you might ask yourself why we did not do the service wiring in PBEL. After all, implementing logic regarding service calls (like exception handling, more complex data transformations) is easier in BPEL. But not every BPM developer is also good in BPEL, making BPMN the better choice from a development process point of view. However, the next evolution could be to create some even more generic Service Request/Response Handler that is capable of calling any synchronous service, taking an anyType input and output argument.