IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > Bindings > Export and import binding configuration > Fault handling
How faults are handled in export bindings
When a fault occurs during the processing of the request from a client application, the export binding can return the fault information to the client. You configure the export binding to specify how the fault should be processed and returned to the client.
You configure the export binding using IBM Integration Designer.
During request processing, a client invokes an export with a request, and the export invokes the SCA component. During the processing of the request, the SCA component can either return a business response or can throw a service business exception or a service runtime exception. When this occurs, the export binding transforms the exception into a fault message and sends it to the client, as shown in the following figure and described in the sections that follow.
Figure 1. How fault information is sent from the component through the export binding to the client
You can create a custom data handler or data binding to handle faults.
Business faults
Business faults are business errors or exceptions that occur during processing.
Consider the following interface, which has a createCustomer operation on it. This operation has two business faults defined: CustomerAlreadyExists and MissingCustomerId.
Figure 2. Interface with two faults
In this example, if a client sends a request to create a customer (to this SCA component) and that customer already exists, the component throws a CustomerAlreadyExists fault to the export. The export needs to propagate this business fault back to the calling client. To do so, it uses the fault data handler that is set up on the export binding.
When a business fault is received by the export binding, the following processing occurs:
- The binding determines which fault data handler to invoke for handling the fault. If the service business exception contains the fault name, the data handler that is set up on the fault is called.
If the service business exception does not contain the name of the fault, the fault name is derived by matching the fault types.
- The binding calls the fault data handler with the data object from the service business exception.
- The fault data handler transforms the fault data object to a response message and returns it to the export binding.
- The export returns the response message to the client.
If the service business exception contains the fault name, the data handler that is set up on the fault is called. If the service business exception does not contain the name of the fault, the fault name is derived by matching the fault types.
Runtime exceptions
A runtime exception is an exception that occurs in the SCA application during the processing of a request that does not correspond to a business fault. Unlike business faults, runtime exceptions are not defined on the interface.
In certain scenarios, you might want to propagate these runtime exceptions to the client application so that the client application can take the appropriate action.
For example, if a client sends a request (to the SCA component) to create a customer and an authorization error occurs during processing of the request, the component throws a runtime exception. This runtime exception has to be propagated back to the calling client so it can take the appropriate action regarding the authorization. This is achieved by the runtime exception data handler configured on the export binding.
You can configure a runtime exception data handler only on HTTP bindings.
The processing of a runtime exception is similar to the processing of a business fault. If a runtime exception data handler was set up, the following processing occurs:
- The export binding calls the appropriate data handler with the service runtime exception.
- The data handler transforms the fault data object to a response message and returns it to the export binding.
- The export returns the response message to the client.
Fault handling and runtime exception handling are optional.
If you do not want to propagate faults or runtime exceptions to the calling client, do not configure the fault data handler or runtime exception data handler.