Table of Contents

Search

  1. Preface
  2. Understanding Data Types and Field Properties
  3. Designing Processes
  4. Using and Displaying Data
  5. Designing Guides
  6. Designing Process Objects
  7. Designing Service Connectors
  8. Using Connectors
  9. System Services, Listeners and Connectors

2. Design

2. Design

Fault Handling and Boundary Events

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:
    1. Add fault handling for each step individually.
    2. 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:
    1. 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.
    2. Log the fault (for example, by sending an email notification) and continue gracefully.
    3. 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.


Updated February 11, 2021