Scenario: BPELProcess1 invokes BPELProcess2. In BPELProcess1, I have catch blocks for binding & remoteFault and catchAll.
I retired BPELProcess2 and tried testing BPELProcess1.
Query 1: Ideally, BPELProcess1 should get faulted throwing bindingFault because its not able to bind to partner link but in our environment, its throwing remoteFault.
In 10g, it throws binding fault when the partner link is not accessible. If there is somme issue inside partner link process, it throws remoteFault.
So in 11g when does the control goto binding fault catch block ?
Query 2: In 10g, in case of any SystemFault, control goes to catch block of that Fault and then to catchAll where AIAAsyncErrorHandlingBPELProcess gets invoked
In our 11g environments, if some SystemFault occurs Eg: remoteFault, control is going to catch block of remoteFault but then its not going to catchAll.
I tested in two environments, we are facing same issue.
Here is fautlHandlers code:
<catch faultName="bpelx:remoteFault" faultVariable="SysFaultVar">
<throw name="ReThrow_RemoteFault" faultName="bpelx:remoteFault"
What is your test scenario? Have you just retired a service that is being consumed ? Services that are retired are still reachable. However, invocation of such a service will fail. Hence you would get a remote fault, instead of a binding fault.
When the Service being consumed is either not available or undeployed, then it's WSDL cannot be loaded. In this scenario, you would get a binding fault.
Query 2: This behaviour is as expected. The catch activities in the faulthandler work as a chained if-else stmnts.
As per my understanding and test cases I executed, there are some changes that I observed in 11g
1. Whatever is the case, callee is undeployed/retired/shutdown, caller is getting remoteFault
2. When an exception is rethrown in a Catch branch and CatchAll branch is present on the same level, the exception is propagated to the higher level and not caught by the CatchAll branch. This seems like major change in 11g compared to 10g