Fault handling in BPEL processes can be quite tricky. There are a number of ways to raise a fault and a number of ways to handle a fault. This is further complicated by additional settings such as bpel.config.transaction and oneWayDeliveryPolicy which also affect fault handling. This post summarises the options then presents a table defining which handlers are able to catch which faults in a number of scenarios.
Raising a Fault
There are three main ways that faults are raised in BPEL:
- Internal faults raised by the BPEL engine. Occur for various reasons such as adapter binding errors, XML transformation errors, etc. These throw various runtime faults which are defined by the BPEL spec.
- A fault received as a response to an invoke activity. Application specific faults that occur when an invoked service replies with a fault defined in the WSDL. Expected faults defined in the WSDL are known as business faults, however some scenarios can also raise runtime faults, particularly bpelx:RemoteFault (e.g. thrown when a service responds with a SOAP Fault).
- Execution of a throw activity. Application specific faults that are raised by a BPEL process. Should be defined in the WSDL and are considered business faults.
Handling a Fault
BPEL provides two main mechanisms for fault handling. The Fault Management Framework provides a mechanism for defining and attaching fault policies to BPEL processes. These policies define fault handling mechanims such as automatic retry and human intervention. Alternatively BPEL faults can be handled inside the BPEL process using BPEL FaultHandlers and Catch activities. These fault handlers allow developers to specfy further processing steps to take when a fault is encountered.
The following list defines the orer or precedence used when BPEL is determining how to handle a fault:
- Fault policy with matching faultName and conditions.
- Catch activity with matching faultName and matching faultVariable type.*
- Catch activity with matching faultName.
- Catch activity with no faultname and matching faultVariable type.*
- CatchAll activity.
The Table
This table defines various invokation and fault handling scenarios and then indicates how the fault can be handled. There are three main scenarios, the fault is thrown as a business fault, the fault is thrown as a remote fault, or the fault cannot be caught.
| Invokation Type (Caller invokes Callee) | Transaction Type | Callee Details | Fault Policy (Business Fault) | Fault Policy (Remote Fault) | Catch (Business Fault) | Catch (Remote Fault) | Catch All |
| Synchronous | requiresNew | BPEL Throw | Yes | No | Yes | No | Yes |
| BPEL Throw bpelx:rollback | No | Yes | No | Yes | Yes | ||
| WS or BPEL Reply Fault | Yes | No | Yes | No | Yes | ||
| EJB Throw ApplicationException | No | Yes | No | Yes | Yes | ||
| EJB Throw RemoteException | No | Yes | No | Yes | Yes | ||
| required | BPEL Throw | Yes | No | Yes | No | Yes | |
| BPEL Throw bpelx:rollback | No | No | No | No | No | ||
| WS or BPEL Reply Fault | Yes | No | Yes | No | Yes | ||
| EJB Throw ApplicationException | No | Yes | No | Yes | Yes | ||
| EJB Throw RemoteException | No | No | No | No | No | ||
| One-Way(onewayDeliveryPolicy=sync) | Any | BPEL Throw | No | Yes | No | Yes | Yes |
| BPEL Throw bpelx:rollback | No | Yes | No | Yes | Yes | ||
| One Way(oneWayDeliveryPolicy=async.cache, async.persist) | Any | BPEL Throw | No | No | No | No | No |
| BPEL Throw bpelx:rollback | No | No | No | No | No | ||
| Asynchronous(with mid process Receive activity)* | Any | BPEL Throw (Not Dehydrated) | Yes | Yes | Yes | Yes | Yes |
| BPEL Throw (Dehydrated) | No | No | No | Yes (Timeout) | Yes (Timeout) | ||
| Callback with Fault (Any) | Yes | Yes | Yes | Yes | Yes | ||
| Internal (no invokation) | Any | BPEL Throw | Yes | No | Yes | No | Yes |
| BPEL Throw bpelx:rollback | No | No | No | No | No |
*Mid-process receives behave differently if the instance is dehydrated by the invoke (or between the invoke and the receive).
See: https://blogs.oracle.com/ateamsoab2b/entry/fault_management_framework_by_example
