Action in Fault Policies

Retry action The Retry action instructs the fault management framework to retry a failed service invocation until it is successful or it reaches a specified limit. In the previous example, we have specified that we will retry the service five times, and if the invocation still fails after this, we have specified that we want to invoke the ora-human-intervention action. The Retry action takes a number of parameters that allow us to configure how it behaves, and they are defined as follows: retryCount This specifies the maximum number of retries before this action completes with a failure status. retryInterval This specifies the period in seconds between retries. exponentialBackoff This is an optional element, which takes no parameters. When specified, if a retry fails, the interval between this retry and the next retry is twice that of the previous interval. In the previous Example, the first retry would occur after 15 seconds, the second after 30 seconds, the third after 60 seconds, and so on. retrySuccessAction This is an optional element with a single attribute ref. This references another action to be taken upon successful retry of a service. This should only be used to reference a java action (see below), which we can use to generate an alert. retryFailureAction This is an optional element with a single attribute ref that allows you to define the action to be carried out, should all retries fail. For scenarios where the interaction between a BPEL process and its client are synchronous, we should only use small retry periods. This is because we are suspending the BPEL process between retries; thus if the retry period is too long, the client which invoked the BPEL process could timeout while waiting for a response. Human intervention action For errors which are more permanent, the human Intervention action gives us the ability to suspend the routing rule or process where the fault is occurring. Once suspended, we can log into the Fusion Middleware Control Console in Enterprise Manager to manually handle the fault. From within the console, we can perform a number of actions. These include manually retrying the service, with the option of modifying the input payload in case this is causing the error. Or, in the event that the service can't be called, we can get the process to skip the invoke activity and manually create the output that should have been returned by the service. When using this action for a BPEL process, because we are suspending the process, we should only use this action if the interaction between the BPEL process and its client is asynchronous. Otherwise, the clients will timeout while waiting for the problem to be resolved. Abort action This action causes the Mediator to abort the routing rule or the BPEL process to terminate. For BPEL, it's the equivalent of executing a terminate activity directly within the BPEL process. An abort action takes no parameters and is defined as follows: <Action id="ora-terminate"> <abort/> </Action> Rethrow action

For errors that we don't want handled by the fault management framework, we can use the rethrowFault action to re-throw the fault to our BPEL process. This is often useful when we have defined a generic fault handler to catch all faults, but want to exclude certain faults. For example, if we look at the fault policy defined previously, the final handler within our conditions section is defined as follows: <faultName> <condition> <action ref="ora-human-intervention"/> </condition> </faultName> This will catch all faults that have not yet been handled. This is exactly what we want for any unknown system faults. However, we want business faults to be explicitly handled by our BPEL process. The re-throw action allows us to do just this. We can define a fault handler that catches our business faults such as the following: <faultName xmlns:tns="http://rubiconred.com/obay/svc/CreditCard" name="invalidCreditCard" <condition> <action ref="ora-rethrow-fault"/> </condition> </faultName> This will then invoke the following action: <Action id="ora-rethrow-fault"> <rethrowFault/> </Action> This will re-throw the fault to our BPEL process. This action can't be used to handle faults within a Mediator component. Replay scope action This action causes the fault management framework to return a replay fault to the BPEL process. This fault will be automatically caught by the scope in which the fault is thrown and trigger the BPEL engine to re-execute the scope from the beginning. A replay scope action takes no parameters and is defined as follows: <Action id="ora-replay-scope"> <replayScope/> </Action> Note: This action can't be used to handle faults within a Mediator component. Java action This enables us to call out to a custom java class as part of the process of handling the fault. This class must implement the interface IFaultRecoveryJavaClass, which defines two methods: public void handleRetrySuccess(IFaultRecoveryContext ctx ); public String handleFault( IFaultRecoveryContext ctx ); The first method handleRetrySuccess is called after a successful retry of an invocation, otherwise handleFault is called.

This class is not intended to handle a fault, but is more for generating alerts and so on. For example, you could use invocation of the method handleFault to generate a notification that there is a problem with a particular endpoint, and likewise, use the invocation of the method handleRetrySuccess to generate a notification that the problem with the endpoint has now been resolved. The method handleFault returns a string value, which can be mapped to the next action to be invoked by the framework, for example, if we defined the following javaAction: <Action id="ora-java"> <javaAction className="mypackage.myClass" defaultAction="ora-human-intervention"> <returnValue value="RETRY" ref="ora-retry"/> <returnValue value="MANUAL" ref="ora-human-intervention"/> </javaAction> </Action> The javaAction element takes two attributes: className, which specifies the java class to be invoked, and defaultAction, which specifies the default action to be executed upon completion of the java action. Within the javaAction element, we can specify zero, one, or more returnValue elements, each of which maps a value returned by handleFault to a corresponding follow-up action to be executed by the fault management framework. In the previous example, we have specified for a return value of 'RETRY'. The framework should execute the ora-retry action, and if a value of MANUAL is returned, then it should execute the ora-humanintervention action. If no mapping is found for the return value, then the defaultAction specified as part of the javaAction is executed. This gives us the flexibility to calculate how we wish to handle a particular fault at runtime.