The faults are one of the most important aspects of the BPEL process. In this recipe, we will explore how to handle the faults that are thrown from the web service.
We will modify the BPEL process we created in the Invoking web services in parallel recipe and name it BPELProcessFault. If we now run the BPEL process, it will complete with the faults. Now, we have to adapt the BPEL process in order to catch the faults thrown from the web service.
- We add the
<catch>activity to the scope, where we invoke the web service. We model the<catch>activity with the following parameters:
- Inside the
<catch>activity we add the<assign>activity, where we report that something went wrong to the client calling our process as follows:<faultHandlers> <catch faultName = "ns1:BookCarServiceInvalidDatesException" faultVariable = "FaultVar"> <assign name = "AssignFault"> <copy> <from expression = "string('Problem with the BPEL process !!!!!')"/> <to variable = "outputVariable" part = "payload" query = "/client:processResponse/client:result"/> </copy> </assign> </catch> </faultHandlers>The final outlook of the BPEL process for handling faults is as follows:
- Now, if we run the BPEL process that finishes successfully, we get the following response:
- In case of the fault, we receive the following response from the BPEL process:
The faults are specified in the port type when we invoke the synchronous web service. The web service itself creates the fault and fills it with information about the fault. This fault message is received by the BPEL process that invokes faulted web service. Based on the criteria about the fault message, the BPEL process catches the fault with the information within. Based on the fault type and information inside the fault, we can decide how to proceed with the BPEL process execution. The fault handler can affect only the scope that encloses it. When the fault occurs in the scope, the BPEL process execution continues after the scope definition. If the fault handler is attached to the outer most scope, then the BPEL process finishes after the fault is handled.
There are cases where the fault message is not known. If we cannot define the message or we fail to catch every fault that comes from the web service invocation, we utilize the <catchAll> activity. The <catchAll> activity does not have any conditions and simply consumes any fault coming into the BPEL process.
Note
We can have multiple <catch> activities per scope in the BPEL process; however, there must exist only one <catchAll> activity per scope. The same functionality can be found in the Java programming language. We can see the BPEL <catch> activity as the Java catch statement with the named exception. Similarly, we can see that the BPEL <catchAll> activity is similar to the Java statement catch(Exception e).