The steps for adding fault handlers are as follows:
- We check the content of the input message before preparing the request to the query services. The
<if>activity can be used to check the content of input and get an action based on the result. So let's drag-and-drop a new<if>activity in between the<receive>and<assign>activities that prepare the request message to the query service:
- Now, let's add the content verification logic as the condition in the
<if>activity. Click on theifcase in the<if>activity and use XPath Expression Builder to generate the expression in the box named Condition:
- Now, if the condition is
true, the activity defined within the<if>case is executed. So let's generate a fault within the<if>case. In WS-BPEL 2.0, to generate a fault, the<throw>activity is used. Drag-and-drop a<throw>activity within the<if>case, as follows:
- The next step is to configure the fault that is generated by the
<throw>activity. Let's just configure a qualified fault name. Now click on Apply and then on OK:
- Now, similar to traditional programming languages like Java, we need to add a construct that handles the generated fault. In WS-BPEL 2.0,
<faultHandler>is responsible for this. To add<faultHandler>to the process, click on the following icon in the icon pallet of the process definition:
Once you have clicked on that icon, a fault handler is generated with a catch construct:
This catch construct can handle a specific type of fault. When we need to generate a fault handler that can handle any type of fault, we can use the
<catchall>construct which can be generated by clicking on the following icon on the icon palette of the process definition:
- In step 4, we defined the fault by a qualified name that is generated by a
<throw>activity. Now in order to handle that particular fault, the catch fault handler should be configured to handle the same qualified name of that fault. So double-click on the catch fault handler and specify the same qualified name as the Fault Name:
- As the remaining step of defining a fault handler, what is left is to define a fault handling logic within the fault handler. For the sake of simplicity, we add an
<exit>activity (as shown in the following screenshot), so the process instance is immediately ended. In the next exercise, we declare a more meaningful fault handling behavior.
In the previous sections, we introduced a high-level view of the possible faults that can be generated during the life cycle of a business process. They are as follows:
- Communication issues
- Contract issues
- Faults thrown from the external web service
- Faults thrown from the business process itself
Then we demonstrated an example with step-by-step instructions to implement a fault handler for a fault thrown from the business process itself. We generated that fault by checking the content of a variable of the business process. Then a fault handler was added where the fault is handled within the business process. For the sake of simplicity, we used the <exit> activity as the fault handling logic. In that example, we introduced a few WS-BPEL 2.0 constructs such as <throw>, <faultHandler>, and <catchall> to signal and handle an error. But we didn't explain their usage in detail. So, in this section, we explain in detail how those constructs model a fault handling behavior within a business process.
We discussed four categories of possible faults that can be generated during the life cycle of a business process in the Introducing Faults and Fault Handlers section. The WS-BPEL 2.0 specification models those aforementioned faults based on three different models. They are as follows: