Fault Handling Checklist

# Checklist Item Additional Information (only high-level hints are provided – Developer Guide / Guidelines wiki need to be referred to get the complete information)

1. Have catchall block in every BPEL component

You can have individual catch blocks to handle the named business faults or system faults. However, make sure that you also put catchall block to avoid unwanted retry issues with the unhandled faults.

2. Have default action in the fault policy If you are using fault policies, to mimic catchall situation of

BPEL, have default policy condition as shown in the below

sample:

<faultName

xmlns:bpelx="http://schemas.oracle.com/bpel/extension"

name="bpelx:remoteFault">

<condition> ------ Condition with a filter criteria

<test>$fault.code/code="WSDLReadingError"</test>

<action ref="ora-terminate"/></condition>

<condition> ------ Catch all condition for remoteFault

<action ref="ora-java"/> </condition>

</faultName>

3. Check the required fault policy for your composite

• Check whether the default fault policy would be sufficient for your composite.

• Have a custom fault policy based on your fault handling requirements

4. Try to define named faults in the ADFBC services

• Coarse grained: Example: “InsufficientCustomerInformation”

• Fine grained: Example: “InsufficientContactDetails”, “IncorrectAddress”

Named faults would help to differentiate business faults from system faults and they can be treated separately based on the business requirements

5. Re-throw faults from fault policies After handling the faults via fault policy actions, you need to re-throw the faults from fault policies. This would ensure that BPEL catchall block activities would be executed such as fault notification or compensation process can be triggered

# Checklist Item Additional Information (only high-level hints are provided – Developer Guide / Guidelines wiki need to be referred to get the complete information)

6. Have a notification service Make sure to handle all types of faults and notify errors to the

administrators via a notification service call from the

composites

7. Have a compensation mechanism Based on the error notification, display a summary of necessary actions on the dashboard to compensate a failed transaction. (example: resubmit a fresh request, retry the existing transaction, cancel/abort transaction and then raise a new request, call a service to update any status…etc)

8. Ensure short lived transactions via milestones

Make sure that your transactions are short lived especially for synchronous calls within a process. If you encounter long transaction flows during design time or during near real-time stress testing, make sure that appropriate dehydration points/milestones are in place to divide the long transactions into short lived transactions

9. Use business identifier for all kinds of error related notifications

Make sure to correlate a unique business key like PO number for all kinds of notifications and tables used to store the error logs which further be used while displaying it on dash boards

10. Partner-link retries should be used judiciously

Partner link level retries would commit the transaction and dehydrate BPEL process state at the invoke activity. Retries will happen in a different thread. A new transaction will start to complete the subsequent activities

11. Terminate/retry the process after handling faults depending on the use case

• For payload related exceptions, terminate the process after invoking an error notification service. Let the caller resubmit the transaction with corrected payload

• For the business faults which can be recovered by modifying the business rules or filters at runtime, then re-throw the fault after invoking error notification service to make it available for recovery

12. Make sure to send callbacks with error response for all the asynchronous processes

• Design your process to have the callbacks with error/success status embedded in the response message payload

• Make sure that you have a switch condition after mid process receive activity to handle both the success and error responses