When you integrate applications with Process Designer, you can handle error conditions by:
•Catching a fault in a process using boundary events.
•Returning faults from a process either with output fields or by adding a Throw step to the process to throw a fault.
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.
Note: 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:
1Add fault handling for each step individually.
2Define 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:
1If 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.
2Log the fault (for example, by sending an email notification) and continue gracefully.
3Add 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:
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.
Methods to Return a Fault from a Process
1Use an output. This is suitable when you foresee that the error might occur and you want to use a data decision step to branch the process based on the normal process flow.
2Throw a fault. This is suitable when the only appropriate response to the error is to pass the error up to the caller or log the error and suspend the process. For example, if you attempt to access a web service that responds with the HTTP status code, 403 Forbidden, it indicates that the service understood the request but refuses to take any action, because access is denied. Throwing a fault is normally the best option to handle this error because you are unlikely to resolve it in the normal process flow.
Throw Step Usage
When you add a Throw step to a process, the error information is propagated by the Throw step. This allows you to catch the fault when you call it, for example, through a Subprocess step.
Note that:
1The name must be a string value.
2Throw is a terminating step so it does not support any outbound links.
3A Throw step can be used to rethrow information caught using a fault handler. In that case, the payload for the step is a faultInfo element that contains the parameters returned by the service, service connector, or SOA connector.
4You can also use a Throw step to construct specific fault information that you want to use as part of your process.
