Fault Handling for Service Invocations
A fault response to an invoke activity uses the definition of the fault in the WSDL operation. A WSDL fault is defined by using the target namespace of the port type and the fault name.
Example: Purchase Order BPEL Process
In a normal purchase order BPEL process, the following steps occur:
- 1. A customer sends in a purchase order.
- 2. The BPEL process receives a purchase order and performs tasks for calculating shipping and production costs.
- 3. The BPEL process returns an invoice to the customer.
If something goes wrong, the process returns an error. Fault messages are defined in the WSDL file and used in the BPEL process as described in the following example:
WSDL Fault Definition | BPEL Fault Handling for Service Invocation |
|---|
<portType name="POrderPT">
<operation name="sendPOrder">
<input message="..."/>
<output message="..."/>
<fault name="cannotCompletePO"
message="pos:orderFaultType"/>
</operation>
</portType> | <faultHandlers>
<catch
faultMessageType="ns1:errorMessage"
faultName=="lns:cannotCompletePO"
faultVariable="POFault">
<reply partnerLink="purchasing"
operation="sendPOrder"
variable="POFault"
faultName="lns:cannotCompletePO"/>
</catch>
</faultHandlers> |
In the WSDL definition above, the operation called sendPOrder specifies the fault named cannotCompletePO that is used by the BPEL process if the purchase order cannot be completed. In the BPEL process fault handlers section, the catch activity contains a reply defined to return a message in the POFault variable in the event that a fault is received.
When an invoke operation returns a fault message, it causes a fault in the current scope. The fault variable in the corresponding <catch> is initialized with the fault message received.
If a Web service operation is not defined with a fault message, you can use the Process Developer custom functions to catch undeclared faults.
For more information, see Adding a Fault Handler as a Boundary Event for an Invoke Activity and Catching Undeclared and SOAP Faults.