Scroll to top

Catching, Throwing and Replying: Fault Handling in BPEL

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:

  1. Fault policy with matching faultName and conditions.
  2. Catch activity with matching faultName and matching faultVariable type.*
  3. Catch activity with matching faultName.
  4. Catch activity with no faultname and matching faultVariable type.*
  5. 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 TypeCallee DetailsFault Policy (Business Fault)Fault Policy (Remote Fault)Catch (Business Fault)Catch (Remote Fault)Catch All
SynchronousrequiresNewBPEL ThrowYesNoYesNoYes
BPEL Throw bpelx:rollbackNoYesNoYesYes
WS or BPEL Reply FaultYesNoYesNoYes
EJB Throw ApplicationExceptionNoYesNoYesYes
EJB Throw RemoteExceptionNoYesNoYesYes
requiredBPEL ThrowYesNoYesNoYes
BPEL Throw bpelx:rollbackNoNoNoNoNo
WS or BPEL Reply FaultYesNoYesNoYes
EJB Throw ApplicationExceptionNoYesNoYesYes
EJB Throw RemoteExceptionNoNoNoNoNo
One-Way(onewayDeliveryPolicy=sync)AnyBPEL ThrowNoYesNoYesYes
BPEL Throw bpelx:rollbackNoYesNoYesYes
One Way(oneWayDeliveryPolicy=async.cache, async.persist)AnyBPEL ThrowNoNoNoNoNo
BPEL Throw bpelx:rollbackNoNoNoNoNo
Asynchronous(with mid process Receive activity)*AnyBPEL Throw (Not Dehydrated)YesYesYesYesYes
BPEL Throw (Dehydrated)NoNoNoYes (Timeout)Yes (Timeout)
Callback with Fault (Any)YesYesYesYesYes
 Internal (no invokation)AnyBPEL ThrowYesNoYesNoYes
BPEL Throw bpelx:rollbackNoNoNoNoNo

*Mid-process receives behave differently if the instance is dehydrated by the invoke (or between the invoke and the receive).