Last week, we looked at the assign and other basic activities, and studied flow. This week, we'll be examining more sturctured activities, and fault handling. This article, the fifth in a six-part series, is excerpted from chapter 12 of Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).
Fault Handling with Web Services - Fault Handling (Page 2 of 4 )
BPEL introduces fault handlers in order to let you deal with exceptional situations, such as the following:
A fault recognized as the result of a Web service invocation
A fault thrown explicitly by the process logic
A fault caused by a problem encountered by the runtime infrastructure
Let's take a closer look at these three potential sources of faults in BPEL.
The outcome of a Web service invocation is either regular output or a fault, as specified by the WSDL operation. The example shows the definition of a WSDL operation with two faults. WSDL faults have a name and a reference to a message definition, as shown in the following snippet:
BPEL also lets you raise faults explicitly by means of the throw activity. The throw activity declares a qualified name of a fault and optionally provides a variable to associate data with the fault. The following BPEL snippet shows a throw activity. It's used to end the execution of the normal path in the process because the validation of the received purchase order has failed:
Finally, the BPEL runtime infrastructure recognizes a number of predefined exceptional situations within a running process instance. If such a situation occurs, a BPEL standard fault is raised. Examples for such standard faults are
mismatchedAssignmentFailure—Incompatible types in an assign activity
forcedTermination—Fault in an enclosing scope
correlationViolation—Message contents in receive, reply, invoke, or pick/onMessage don't match correlation data
uninitializedVariable—Attempt to access an uninitialized part of a message variable
invalidReply—Attempt to execute a reply for which no corresponding receive activity has been processed
In BPEL, fault handlers are the mechanism to explicitly catch these faults and respond to them in appropriate business logic. Fault handlers are associated with a scope activity or with the overall process.
When a fault is recognized, the scope or process first stops all its nested activities. Structured activities are terminated immediately. Some types of basic activities are also interrupted, including wait, receive, reply, and invoke. Other activities are considered short-lived and aren't interrupted.
A fault handler contains an activity that runs in case the corresponding fault occurs. For example, the fault handler may contain a reply activity that notifies a partner that normal processing of the logic can't be completed.
Syntactically, a fault handler is a catch or catchAll element. The catch element lets you specify the qualified name of a fault, a fault variable, or both. The fault variable can be omitted in cases where faults don't have additional data associated with them. The catchAll element doesn't have attributes.
Following is an example of a fault handler declaration for the overall process: