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 Type Callee Details Fault Policy

(Business Fault)

Fault Policy

(Remote Fault)

Catch

(Business Fault)

Catch

(Remote Fault)

CatchAll
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

insightsLimePoint Team