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.
<wsdl:operation name="request">
<wsdl:input message="client:EventTestRequestMessage"/>
</wsdl:operation>
<wsdl:operation name="getStatus">
<wsdl:input
message="client:EventTestStatusRequestMessage"/>
</wsdl:operation>
<wsdl:operation name="cancelRequest">
<wsdl:input message="client:EventTestCancelRequestMessage"/>
</wsdl:operation>
<wsdl:operation name="updateRequest">
<wsdl:input message="client:EventTestRequestMessage"/>
</wsdl:operation>
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
References:-
