Simple scenario -
An order XYZ is being processed in a composite that includes the following
components-
File Adapter(read) --> Mediator --> BPEL --> human workflow --> DB
Adapter(write).
In the meantime the customer cancels the order XYZ by calling the call center.
The order db is updated accordingly via the call center app, but now we
need to kill the soa composite instance that's still running.
I could create a composite sensor based on the unique Order ID.
The info is then written to the SOA_INFRA table composite_sensor_value
From this table I can then get the COMPOSITE_INSTANCE_ID value.
I can save this pair - Order ID and COMPOSITE_INSTANCE_ID to the DB.
Now we know which composite is processing Order ID XYZ.
Regarding cancelling the running process -
We can use the COMPOSITE_INSTANCE_ID to query
the cube_instance table.
e.g. select * from cube_instance where cmpst_id = xxx;
I can then do the usual purge.
But how should we model this from an architectural perspective?
My OCS colleague, Markus, suggested a generic composite that takes care of
the "cancellation" of all running SOA composite instances.
So we could have the user cancellation call to the call center triggering an event that our generic composite processes.
So essentially we have the following -
1. Create an event via the EDN-Framework.
1.1. The payload contains the info required (orderID, CompositeID etc.) to
find the appropriate running instance.
2. Event is picked up by a Mediator which routes on to a BPEL process that does
the actual purging.
Example to follow after the holidays.
No comments:
Post a Comment