SOA/BPM:Incoming Message dispatcher (part 2 of 2)

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 2: Addition to an existing case

In case of an addition the incoming request message is extended with two extra fields:

• the message type (A..Z)
• the request as a PDF file
• the name of the PDF file
• case number (in case of addition)
• type of addition

A simplified version of the real BPM process is shown in the picture below.

The proces of part 1 is extended with a ‘New Case’ condition. When the incoming message already contains a casenumber it is treated as an addition to an existing case and is it not necessary to determine a new casenumber.

The applied payload is stil used to determine the endpoint. In our case: the caseType and the type of addition 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’). Potentionallly this could be a problem. To start a new case and to add an addition the proces needs multiple ‘execute’ operations. Because this is not possible we have used a Mediator to redirect the requests.

The Intake.Service is not needed. It is the default WSDL associated to the BPM proces. The IntakeMediatorService.Service has a generic ‘execute’ operation. Redirection takes place in the Mediator by using routing filters. The following picture shows the redirection of a request of type ‘Start’ to the ‘execute’ operation of the proces. In case of an addition redirection is to the ‘addition’ operation of the proces.

The invoked proces is extended with a receive activity which is only reached under some Business conditions. This activity is associated to the ‘addition’ operator.
To add the addition to the right case instance, the proces is making use of correlation. The casenumber (zaaknummer) is used as the correlation key. At the Start of the proces, the correlationkey is initiated and at the receive activity the incoming message is linked to the key.