To cope with exceptional situations, e.g. calling a Web service that is currently unavailable, BPEL offers the concept of fault handlers. A fault handler can be attached to a scope, a process, or even directly as a shorthand notation on an invoke activity.

A fault handler gets installed as soon as the scope it is associated to gets started. As an example, the process level fault handler gets installed when the process starts. If the process completes normally, the installed fault handler then gets discarded, but if a fault situation occurs, that fault gets propagated to the fault handler.

A fault handler can have two types of children: One or more catch constructs, and at most one catchAll. Each catch construct then has to provide an activity that performs exception handling for a specific type of error condition.

A catch construct has optional additional attributes: a faultName that refers to the name of the fault that should get caught, and a faultVariable attribute. When faultVariable attribute is used, either faultMessageType or faultElement attribute must be specified. The faultVariable would point to a variable locally declared within the catch construct based on the faultMessageType or faultElement attribute.

Optionally, the fault hander can end with a catchAll construct. The intention is to provide a means for default fault handling.

 There are now companies with  <a href="www.karmaticIT.com" title="Learn BPEL" alt="SOA BPEL">Prepackaged BPEL Error Handling</a> www.karmaticIT.com

See also:

- WS-BPEL 2.0 Primer: Exception handling