The steps for adding fault handlers are as follows:
<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:<if>
activity. Click on the if
case in the <if>
activity and use XPath Expression Builder to generate the expression in the box named Condition: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:<throw>
activity. Let's just configure a qualified fault name. Now click on Apply and then on OK:<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:
<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:<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:
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: