Understanding fault handlers and signaling

Fault handler, as the name suggests, is used in the WS-BPEL 2.0 specification to handle the generated faults. These faults can be logical errors, execution errors, or errors generated due to the external environment of the BPEL process. These faults can be either implicitly generated by the BPEL runtime or explicitly generated using the <throw> activity.

The basic <throw> activity has the following syntax with an attribute named faultName. The value of this attribute can be any qualified name so it can be used to realize the correct fault handler that is responsible for the generated fault. Consider the following code snippet:

<throw xmlns:fltns="http://packtpub.com/bpel/faults" 
faultName="fltns:faultName" />

However, some generated faults can contain data related to the fault. As usual, this data is represented by a BPEL variable and the optional attribute named faultVariable is used to refer to the particular variable that contains the data. Consider the following code snippet:

<throw xmlns:fltns="http://packtpub.com/bpel/faults" 
faultName="fltns:faultName" <!--mandatory attribute-->
faultVariable="variableName" <!--optional attribute--> />

Now, let's see the structure of a <faultHandler> construct in detail in the upcoming section.

Structure of a fault handler

The following code template depicts the structure of a fault handler:

<faultHandlers>
  <catch ... ><!-- First fault handler -->
    <!-- Perform an activity -->
  </catch>
  <catch ... ><!-- Second fault handler -->
    <!-- Perform an activity -->
  </catch>
  <catchAll>
    <!-- Perform an activity -->
  </catchAll>
</faultHandlers>

So the immediate child elements of a fault handler can be <catch> or <catchAll>. A <catch> element can be used to handle a specific fault and <catchAll> is used to handle faults that are not handled by the other <catch> elements. Also, the optional <catchAll> element should be located as the last element in <faultHandler>. We'll get into more detail on the construction of <catch> and <catchAll> elements in the upcoming sections.

Location of a fault handler

A fault handler cannot be placed in any place in a BPEL process. Basically, it can be placed only at two locations and it can be categorized into two types based on its location as follows.

The global fault handler

The global fault handler is defined for the whole process and it is located as the immediate previous element to the first activity of the BPEL process. It can correspond to faults that occur across the BPEL process. The global fault handler is owned by the process element which houses all other sequences, scopes, and activities.

The local (inline) fault handler

A fault handler can be included within a scope or invoke activity to handle faults generated within the particular <scope> or <invoke> activity. The <scope> activity is a structural activity in the WS-BPEL 2.0 specification and it provides a context boundary to its child constructs. So within a <scope> activity, there can be defined variables or partner links which are local to that particular scope. We will discuss scopes more deeply in the next chapter.

Configuring a fault handler

Within <faultHandler>, the <catch> and <catchAll> activities maintain the fault handling logic related to the fault captured by the <catch> or <catchAll> activity. So the <catch> and <catchAll> activity should consist of some parameters which precisely define the fault that the particular <catch> or <catchAll> activity handles. In this section, we discuss how to configure <catch> and <catchAll> activities such that the generated faults are propagated to the right <catch> or <catchAll> activity.

Earlier in the chapter, we introduced the structure of <faultHandler>, and how <catch> and <catchAll> are organized within <faultHandler>. We also mentioned that <catch> can be used to handle a specific fault and <catchAll> is used to handle faults that are not handled by the other <catch> elements. Keeping that in mind, let's take a look at the attributes used in <catch> which specifically define the faults that it is supposed to handle. There are few attributes which can be used to realize the faults that a particular <catch> is responsible for. Based on those attributes, the BPEL runtime can realize the faults that a particular <catch> handles. These attributes are as follows:

  • faultName: This attribute defines the qualified name of the fault. So if a fault is generated with such a qualified name, this <catch> activity becomes a potential candidate to handle it. Consider the following code snippet:
    <catch faultName="fltns:faultName" >
   ...
</catch>
  • faultVariable: This attribute refers to the variable type used for the fault data. There are two other optional attributes named faultMessageType and faultElement of which only one can be used with the faultVariable attribute at any given point of time. The faultMessageType attribute is used to specify the WSDL message type of the faultVariable attribute. Alternatively, faultElement is used to specify the schema of the faultVariable attribute. These attributes help the BPEL runtime to select the most suitable fault handler (<catch> or <catchAll>) for a generated fault. We discuss this selection process in the following section in more detail. The syntax for this attribute is as follows:
    <catchfaultVariable="fltns:faultVariable" >
   ...
</catch>

BPEL runtime fault handler selection

When it comes to programming languages such as Java and C#, they define their own mechanisms to realize that a particular fault handler should be selected based on the generated fault. In WS-BPEL 2.0 too, the specification defines a fault handler selection mechanism based on details embedded in the fault (such as <throw>) and the details embedded in the fault handler (such as <catch>).

We'll see how this works by correlating the attributes defined in the <throw> activity and the attributes defined in the <catch> activity.

Selecting a fault handler when the fault is not associated with data

As mentioned earlier, some faults only consist of a name where some other faults contain some data related to the fault. Some examples are as follows:

  • The <throw> activity which only has the faultName attribute
  • A standard fault that is generated from BPEL runtime (correlationViolation)

The following mechanism is used to select the correct fault handler for a fault which has no associated data:

  1. The <catch> element which is configured with the same faultName attribute value and that does not specify the faultVariable attribute is selected.
  2. If there is no such <catch> activity, the fault is passed to the <catchAll> activity.

Selecting a fault handler when the fault is associated with data

As some generated faults can consist of data, the selection process for such faults becomes quite complicated, rather than selecting a fault handler for a fault that has only a name.

The following mechanism is used to select the correct fault handler for a fault which has associated data:

  1. A <catch> activity specifying a matching faultName value and a faultVariable attribute whose type matches the type of the fault data will be selected, if present.
  2. Else, a <catch> activity with no specified faultName and with a matching faultVariable attribute will be selected, if present.
  3. Else, the default <catchAll> handler will be used, if present (<catchAll> will execute only if no other <catch> activity has been selected).
..................Content has been hidden....................

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