Tuesday, October 29, 2013

Compilation error - java.lang.IllegalArgumentException: Choice Pattern incorrect,1=null,2={2},3={3},4={4},5={5}



error: !!BPELC_PA__OMIT! [0=java.lang.IllegalArgumentException: Choice Pattern incorrect,1=null,2={2},3={3},4={4},5={5}]
  
This is a generic error which gets thrown during compilation time, due to the changes in the WSDL.
In one of the scenarios if we changed the WSDL or selected DB adapter with a different but similar operation, it will automatically recreate the wsdl, which may remove any custom changes that has been added to the WSDL’s.

The wsdl earlier was a sync operation and it was modified to be an async operation. So in case you haven’t regenerated the invoke or removed the extra variable it will throw compilation error.


For eg:-

        <invoke name="Invoke1"
                partnerLink="DBRequestService"
                portType="ns10:DBRequestService_ptt" operation="insert"
                inputVariable="Invoke1_insert_InputVariable"
                bpelx:invokeAsDetail="no"/>
       

        <!--<invoke name="invokeCreateRequest" partnerLink="DBRequestService"
                portType="ns10:DBRequestService_ptt" operation="insert"
                inputVariable="inCreateRequest"
                outputVariable="outCreateRequest" bpelx:invokeAsDetail="no"/>-->

Saturday, October 19, 2013

OnEvent functionality of Oracle BPEL 2.0 for parallel processing

                           One of my recent projects involved automation of account creation in multiple systems, using multiple workflow process. There was a main process which was controlling the rest of the flow. One of the requirements was to give option to admins or the super user to cancel the workflow or process flow at any point of time during their execution.
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:-