Design

Back Next

Fault Handling and Boundary Events

A boundary event is an event that catches an error that occurs on the boundary of a particular step, that is, within the scope of the step where it is defined. When you enable fault handling for a step in your process, you are defining a boundary event. The fault handler listens for a fault on that step when the process executes. When the the fault is caught, the step is interrupted and the process then follows the path you define for handling the fault. In the fault path, for example, you might send an email notification and terminate the process, retry after waiting for a specified interval, suspend the process, or complete the process using an alternative path.

For example, you can catch a fault that occurs when a REST service returns an error code to the process because the host system is not accessible or because the process provided invalid data.

A fault handler on a step is an interrupting boundary event. This means that when a fault occurs, the process follows the fault path and the main path from the step does not execute.

Design Guidelines for Fault Handling

When you define fault handlers, you must note the following points:

Determine whether the boundary event occurs at a single step or in a set of steps. If the boundary event occurs on a set of steps you have two options:

Add fault handling for each step individually.

Define the steps inside a wrapping process.

The latter option allows you to then add the fault handler on a Subprocess step and invoke the wrapped process.

If you have a Parallel Path step for fault handling, be sure to provide unique field names for each field that contains fault information. Because you define the fault information ouptut field at the process level, there is a chance that fault information from one path can overwrite the fault information of another path. To avoid this, be sure to set a unique field name for fault information in each path of a Parallel Path step.

To handle faults, you have several options:

If there is an uncaught fault, suspend the process and debug it using the

Application Integration Console

. In this case, you must select Suspend on Uncaught Fault in the Advanced process properties. If you do not catch the fault, it will be suspended and visible in the

Application Integration Console

. You can also rethrow the fault after you catch it.

Log the fault (for example, by sending an email notification) and continue gracefully.

Add a Wait step to wait for some interval and then retry the step by adding a Jump step. However, you cannot use a Jump step from the fault path. This means you must merge back to the main process path and then add the Jump step.

Because you get the fault detail (in the faultInfo process object) as an any type value, you can use XQuery to access the detail, provided you know the structure of the fault information returned from the service.

Faults can be triggered by:

Service

step (using a service connector or an automated step created in the process).

Create step (a special kind of

Service

step available in Process Designer).

Host system interaction.

Throw step defined in a process.

Other faults.

Faults Triggered by Service Connectors

If a fault is triggered by a service connector, the faultInfo process object includes a description of the error and returns this to the process.

When you enable fault handling in Process Designer, you also catch any explicit runtimeError faults that might be generated by an SOA connector. For example:

 <wsdl:operation name="read">
    <wsdl:input message="tns:readRequest"></wsdl:input>
    <wsdl:output message="tns:readResponse"></wsdl:output>
    <wsdl:fault name="runtimeError" message="tns:faultResponse"/>
</wsdl:operation>

Step Types that Support Fault Handling

You can enable fault handling on the following step types:

Create

Service

Subprocess

If enabled, the fault handler catches all faults on the individual step. Because it is interrupting, it creates a separate execution path in the process. You specify a fault name field so you can get all the fault details in the process object.

On the

Fault Handling

tab for each of these Step types, you can set these properties:

Property	Description
Catch Faults	Required. Check to enable fault handling on this step. By default, this option is disabled.
Fault Field Name	Required if Catch Faults is enabled. The fault name, which defaults to faultInfo.

The following image shows a service step with fault handling enabled:

You can also configure a specific fault type, reason, and description in a Throw step. You can then call the Throw step from other processes when it is caught by a pattern or process, rather than using an output field to pass fault information.

Fault Handling

Download Guide

Watch

Comments

Cloud Application Integration Homepage