How to make a custom fault handling for a BPEL process
Every SOA application needs to establish a set of rules for handling faults. In this blog I will show you how to make a custom fault handling for a BPEL process.
Usually in the BPEL processes this is possible thanks to the fault-policies.xml. In it are defined all the actions that can be done when an error occurs. The policies that can be used in the application are defined in the fault-bindings.xml. They can affect different scope of the SOA application – service components, BPEL process or even the whole SOA application.
The basic construction of the fault-bindings.xml and fault-policies.xml documents represents a rule that is applied for all types of faults and for the whole SOA application. They are usually located in the same directory as the composite.xml of the SOA application.
But how should we construct our policy if we need a single different rule for a single BPEL?
First we should define a new policy that affects only the desired BPEL in
fault-bindings.xml
|
1 2 3 |
<component faultPolicy="insert-custom-name-policy-here"> <name>write-name-of-bpel-component-here</name> </component> |
The whole fault-binding.xml document content should look like this:
After that we will define the rules for this policy inside the tag in the fault-policies.xml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<faultPolicy version="2.0.1" id="custom-name-policy"> <Conditions> <faultName> <condition> <action ref="ora-rethrow-fault"/> </condition> </faultName> </Conditions> <Actions> <Action id="ora-rethrow-fault"> <rethrowFault/> </Action> </Actions> </faultPolicy> |
Defined like this the default action for our policy will be for any type of fault to rethrow that fault. Remember, if we want to apply the rules only for a specific fault (runtime fault for example) we should define it inside the tag <Conditions> like this:
|
1 2 3 4 5 6 |
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:runtimeFault"> <condition> <action ref="set-an-action-in-case-this-error-occurs"/> </condition> </faultName> |
Different types of actions can be defined inside the fault policy.
Basic ones are:
|
1 2 |
<Action id="ora-terminate"> <abort/> |
The abort action terminates the faulted process.
|
1 2 3 |
</Action> <Action id="ora-human-intervention"> <humanIntervention/> |
The human intervention action stops the current activity from processing and waits for manual recovery that can happen when the user logs in the Oracle Enterprise Manager.
|
1 2 3 4 5 6 7 8 9 |
</Action> <Action id="ora-retry"> <retry> <retryCount>3</retryCount> <retryInterval>3</retryInterval> <exponentialBackoff/> <retryFailureAction ref="ora-human-intervention"/> </retry> </Action> |
Retry the setted number of times in the <retryCount>.
Exponential back off indicates the next retry attempt will increase double the retry delay starting with the <retryInterval> value.
If the activity has reached the maximum retry counts, retryFailureAction will be executed.
Example fault-policies.xml content:
In order for the new rules to be applied we need to redeploy the SOA application.
If you want to learn more about how to design the perfect fault handling you can find that information in the Oracle® Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
