Java Reference
In-Depth Information
Explicitly Throwing a Fault
Problem
You want to signal a fault within the process itself, rather than using only those available in a
partner WSDL.
Solution
Use the
<throw>
construct.
Discussion
If a WSDL used as a partner in a process declares a SOAP fault, your business process should
deal with it (though it is not required to). If your orchestration is largely composed of invoc-
ations of a series of other services in a sequence, you may have nothing further to say on the
subject of errors in your process itself; you may choose just to propagate the faults signaled
by the partners.
But in more sophisticated or complex BPELs that perform more decision logic, branching,
waiting, and so forth, it can be very useful to declare a fault within the process itself. You
can then signal that fault according to the demands of your process. For example, say you're
<wait>
-ing on a partner that isn't responding. It's obviously not going to throw a fault, so you
can decide on a reasonable timeout and do it yourself.
Throwing a fault is a way of transferring control within a process. As in Java and other lan-
guages with structured exception handling, you're signaling that you want to halt the normal
flow of processing, and start the work defined in the fault handler.
The
<throw>
activity provides a name for the fault and, if you like, can also carry detail in-
formation.
Here's an example of using this construct:
<if name="Decision">
<condition>
starts-with($cartRequest.cartData/po:userDomain, 'WEST')
</condition>
<sequence name="MySequence">
<assign name="MyAssign">
<copy>
<from>'User must order from a different region.'</from>
