In this post I will descibe the solution we implemented at a customer site to dispatch incoming message in an Oracle SOA/BPM environment.
The solution we implemented handles the following message types:
- A new request resulting in a new case of type A .. Z (subject of the first part of the post)
- An addition to an existing case. (subject of the second part of the post)
Part 1: New requests
A new incomming request message contains the following information:
- the message type (A..Z)
- the request as a PDF file
- the name of the PDF file
A simplified version of the real BPM process is shown in the picture below.
After arrival of the request the content of it is added to a common dataobject for all case types. After that the common dataobject is accommodated with a case number. And finally the dispatch function is executed with the common dataobject as payload.
For dispatching we used Two-Layer Business Process Management. A short discription of this from the Oracle manual:
Two-layer BPM enables you to create dynamic business processes whose execution, rather than being predetermined at design time, depends on elements of the context in which the process executes. Such elements can include, for example, the type of customer, the geographical location, or the channel.Oracle BPM does not have an implementation for this (yet?). In Oracle BPEL we have the Phase Activity for this.
So the Dispatch to Case task is a call of BPEL service that implements the phase activity.
As shown, the Phase activity is implemented as a Service call. This Service call is a call to a Mediator, which subsequently invokes a Business Rules component to dynamically determine (and invoke) the desired endpoint.
In the composite the Mediator, Rules and Service Reference are connected and form one whole.
The applied payload is used to determine the endpoint. In our case: the caseType (zaakType)’ as part of this payload selects the applicable decision table column. The serviceBindingInfo cell in this row contains the endpoint. The content of this cell can be edited during design time as well as during run time.
The invoked method on this endpoint is fixed (‘execute’).
The Phase Activity current only support Asynchrones processes. This means that the dispatcher BPEL proces stays open until it gets a response from the invoke proces. It the invoked proces is longrunning the dispatcher stay unnecessary open for a long time. For this reason we send a return message immediate after the proces start. And after that perform the proces activities.
At the customer site we plan to implement over twenty different implementations of the proces shown in this last picture. For every new endpoint we only have to add another column to the decision table to support te routing.
In the next part of this post I will describe how the extend this solution to handle additions to existing cases.
