This feature was required so that in case if the Admin see’s foul play or someone trying to create a suspicious account, the support team or admins should be able to cancel or terminate the request and invalidate the changes performed by the request.
This was an interesting use case where we can leverage the OnEvent functionality of BPEL 2.0 .In BPEL 1.1 there was option of OnMessage which has been replaced with OnEvent. Even though the name is OnEvent it is more of a service call with separate one way operation defined as part of the main service.
So if you have a Service, you can define multiple operations which can be used as part the OnEvent.
In case you want to know the status of the long running process, you can define a getProcessStatus operation which should ideally check the status parallel in the flow and send notification or asynchronous callback to return you the status. The OnEvents are all async in nature.
Couple of use cases would be to update the request details on the fly using an onEvent. Canceling and terminating the request, and in case if compensation needs to be done can handled in the onEventHandler.
When you select onEvent, you expectation will be to see a partnerlink which will accept a service operation or an event subscription. But in BPEL 2.0 Oracle implementation it’s only the service operation option that is available. I am not sure why they didn’t want to have event subscribers also in the parallel scope. It would have given us more options to play with EDN and have event created for different processes.
The only tricky part here is to correlate the instances, so you will need to add a unique identifier like a requestId, or combination of UserId and requestId to correlate the instances and can trigger the events.
You can always define onEvent on different scopes, so if you divide your process into multiple scopes and define OnEvents you will get multiple parallel entry points into your existing /running process, which gives you a lot of flexibility in terms of cleaning up or handling different complex scenarios.
If we design a solution with an onEvent flow for reprocessing, then the flow will come in handy for re-processing the scope again for the instances based on run time decisions. So plan ahead and have a handler for defining the logic which can interfere with the existing process flow and reach a different state of completion.
So our solution had terminate Request service exposed to the application which will trigger cancel Request OnEvent of all the participating processes there by terminating the particular request.
Hope this helps J