In-line fault handling

The WS-BPEL 2.0 specification enables defining fault handlers that are specific to behavioral contexts. In other words, WS-BPEL 2.0 supports defining different fault handlers to different activities from a set of activities. The <scope> activity supports the creation of behavioral contexts which can consist of fault handlers, variables, partner links, correlation sets, and so on that are local to that specific <scope> activity. We'll talk more about the <scope> activity in the next chapter. In this section, we will discuss how to define a fault handler that is specific to a particular activity or a particular set of activities. In the BPEL world, we call them in-line fault handlers.

An in-line fault handler is defined within a <scope> activity, so it's only visible to the particular scope and not the whole process definition. Also, a fault handler also can be defined within the <invoke> activity in a similar manner. This enables a much shorter way to manage faults that could occur within the execution of the <invoke> activity. In the upcoming sections, we discuss those two in-line fault handlers with basic examples which both have similar functionality.

Within a <scope> activity

Once you define a fault handler within a <scope> activity, that fault handler can handle only those faults that are generated within that <scope> activity. So within the <faultHandlers> construct, you can define zero or more <catch> activities and can also specify a <catchAll> handler. Let's suppose we need to invoke a synchronous web service and handle the faults that could be generated during that web service invocation:

<!-- Synchronously invoke the Book Warehousing Web Service -->
<scope name="BookWarehousingInvoke">

  <faultHandlers>
    <catchAll>
      <assign>
        <copy>
          <from expression="false()"/>
          <to variable="WarehousingServicePartnerLink_OutputVariable" />"
          part="warehouseSuccessed"/>
        </copy>
      </assign>
    </catchAll>
  </faultHandlers>
  <invoke partnerLink="WarehousingServicePartnerLink" 
  portType="ns3:Warehousing_porttype" 
  operation="WarehouseOperation"
  inputVariable="WarehousingServicePartnerLink_InputVariable"
  outputVariable="WarehousingServicePartnerLink_OutputVariable" />
</scope>

In the previous sample, the faults that occurred during the <invoke> activity are handled within the fault handler defined in <scope> that encloses that particular <invoke> activity. And, if any fault occurs, the <catchAll> handler sets the warehouseSuccessed part of the output variable in the <invoke> activity to false.

Within an <invoke> activity

Now, let's see how to achieve the same fault handling functionality using a fault handler within the <invoke> activity. Here, the only difference is that there's no need to define fault handlers (<catch> and <catchAll>) within the <faultHandlers> construct, rather you can define them within the <invoke> activity. So, within the <invoke> activity, you can define zero or more <catch> activities and you can also specify a <catchAll> handler:

<!-- Synchronously invoke the Book Warehousing Web Service -->
<invoke partnerLink="WarehousingServicePartnerLink" 
portType="ns3:Warehousing_porttype"
operation="WarehouseOperation"
inputVariable="WarehousingServicePartnerLink_InputVariable"
outputVariable="WarehousingServicePartnerLink_OutputVariable" />

  <catchAll>
    <assign>
      <copy>
        <from expression="false()"/>
        <to variable="WarehousingServicePartnerLink_OutputVariable" />" 
        part="warehouseSuccessed"/>
      </copy>
    </assign>
  </catchAll>
</invoke>
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset