0 
0 The use case is very straightforward: we have a SOA & BPM Composite Application for the Order process. Whenever a customer places an order, a new instance of this process kicks off. At any one time we will potentially have multiple instances for orders from the same customer. These instances are uniquely identified by the order id.
It happens that the F&A department – because of for example financial difficulties with a certain customer or government regulations regarding certain countries – publishes an event: “Terminate Customer”. This event should result in having all running Orders for that Customer being terminated.
The challenge is that although BPEL and starting with 11gR1PS4 Feature Pack also BPM can correlate events into running instances, this correlation has to be based on a unique instance identifier – unique across all instances of the process or composite. We cannot have the ‘Terminate Customer’ event consumed into all instances of the Order process. Well, not out of the box at least.
Inspired by yesterday’s BPM Customary Advisory Board session where we were in close contact with developer and product managers for BPM as well as several other parties implementing BPM using Oracle’s product, I came up with the following approach. I have not yet tested it, but feels as if it will work.
The starting situation:
Customer A has placed several orders. Each order has resulted in a running Composite instance. The instances are identified by their order id (correlation key) and have exposed a composite sensor with the Customer Identifier.
When the Customer gets terminated, the ‘terminate customer’ event is published to EDN with the customer identifier (A) in its payload. This event should end up in all running Order Process instances with sensor value A. However, correlation into running instances only works based on unique correlation key – which is the Order identifier.
My thinking is that we could adopt the following approach:
Create a new composite application that consumes events on behalf of running Order instances. It subscribes to the Terminate Customer event (and potentially to other Order related events as well). The Mediator that consumes the event, passes the payload – the customer identifier – onwards to Spring Bean component. This component uses the SOA Suite APIs to retrieve all instances of the Order Process that expose the event’s customer id payload (A) as their ‘Customer Id’ Composite Sensor. Each of these instances also expose their unique identifier (== correlation key == order id).
All order identifiers thus collected are handed of to a Mediator to publish events for: for every order identifier, a ‘abort order’ event is published with the order id as its payload:
Now the Abort Order events need to be consumed by only single running instance – based on correlation with the order id.
Here once again the overview of the entire inner workings. I would be interested in any feedback you may have to offer:
Related posts:
Sjoerd Michels becomes our second Oracle Regional Director for Fusion Middleware 
Package java classes (WSIF calls) in BPEL suitcase SOA Suite 11g (TP4) – Create Mediator based SCA Composite Application from XSD – write to output file using File Adapter Adding a custom method in an ADF BC Service Interface – update of a single attribute in a selected row How to remove unwanted SOAP header elements in JAX-WS
Hi Sridhar, nice article you have written! I have posted a comment, suggesting you use an event handler in the BPEL process to asynchronously process the EDN event. Other than that – your implementation is fine.
Well done.
kind regards,
Lucas
Lucas, Thanks for the post as its really helpful in providing a design for the “Termiate Customer”scenario.
I have implemented the same , using a slighlty different approach. Please look into it and provide comments if any.
http://sridhar-oraclefusion.blogspot.com/2011/11/correlate-one-event-into-multiple.html
Â
Â