Earlier in the chapter, we introduced the fault handlers (<catch>
and <catchAll>
), where to locate them, and how to configure them. Also, we introduced you to the <throw>
activity which signals faults explicitly so that the correct fault handler can trigger its fault handling logic. We also talked about WSDL faults and the fact that the BPEL runtime implicitly signals such faults.
In this section, we discuss how to define the fault handling logic within the fault handler (such as <catch>
and <catchAll>
).
The fault handling logic can be defined using any structural activities (such as <sequence>
, <flow>
, and <scope>
) and behavioral activities (such as <invoke>
, <assign>
, and <reply>
) that are defined in the WS-BPEL 2.0 specification. So a <faultHandlers>
tag might look like the following code:
<faultHandlers> <!-- First fault handler --> <catch faultName="fltns:incompatibleFormat" > <reply ... /> </catch> <!-- Second fault handler --> <catch faultName="fltns:faultName" faultVariable="Fault" > <sequence> <assign ... /> <invoke ... /> </sequence> </catch> <!-- Fourth fault handler --> <catchAll> <empty/><!--does nothing--> </catchAll> </faultHandlers>
In the Location of a fault handler section, we discussed global and inline fault handlers, which handle faults that are generated within that particular scope. But sometimes it's intuitive not to handle the fault at the particular scope and let it be handled by a fault handler defined within the parent scope. In such a scenario, we use the <rethrow>
activity to trigger a fault handler defined within the immediately enclosed scope. Consider the following code snippet:
<faultHandlers> <catchAll> <!-- Modifying the fault variable --> <assign> <copy> <from>string('Incompatible input')</from> <to variable="faultVariable" part="error" /> </copy> </assign> <rethrow/> </catchAll> </faultHandlers>