What You May Need to Know About Binding Level Retry Execution Within Fault Policy Retries

11-24 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite 1. Create a fault-policies.xml file in which you explicitly add retrySuccessAction ref=ora-java to the fault-policies.xml file. Action id=ora-retry Retry retryCount3retryCount retryInterval2retryInterval exponentialBackoff retryFailureAction ref=ora-java retrySuccessAction ref=ora-java Retry Action 2. Deploy the composite and create an instance. 3. Click the composite instance to invoke the instance trace of the composite. 4. Click the component in which there is a recoverable fault for example, Oracle BPEL Process Manager, Oracle Mediator, or Oracle BPM.

5. Go to the Faults tab.

6. Select the Retry option to successfully retry the fault.

If fault recovery is successful, the After Successful Retry list is displayed. 7. Select the list and note that the ora-java option is now listed. For more information about recovering from faults in Oracle Enterprise Manager Fusion Middleware Control, see Oracle Fusion Middleware Administrators Guide for Oracle SOA Suite and Oracle BPM Suite.

11.5 Catching BPEL Runtime Faults

BPEL runtime faults can be caught as a named BPEL fault. The bindingFault and remoteFault can be associated with a message. This action enables the faultHandler to get details about the faults.

11.5.1 How to Catch BPEL Runtime Faults

The following procedure shows how to use the provided examples to generate a fault and define a fault handler to catch it. In this case, you modify a WSDL file to generate a fault, and create a catch attribute to catch it. To catch BPEL runtime faults: 1. Import RuntimeFault.wsdl into your process WSDL. RuntimeFault.wsdl is seeded into the MDS from soa.mar inside soa-infra-wls.ear during its deployment. You may see a copy of soa.mar in the deployed SOA Infrastructure in the Oracle WebLogic Server domain, which is a JARZIP file containing RuntimeFault.wsdl. 2. Declare a variable with messageType bpelx:RuntimeFaultMessage. 3. Catch it using the following syntax: catch faultName=bpelx:remoteFault | bpelx:bindingFault faultName=varName Using Fault Handling in a BPEL Process 11-25

11.6 Getting Fault Details with the getFaultAsString XPath Extension Function

The catchAll activity is provided to catch possible faults. However, BPEL does not provide a method for obtaining additional information about the captured fault. Use the getFaultAsString XPath extension function to obtain additional information.

11.6.1 How to Get Fault Details with the getFaultAsString XPath Extension Function

Example 11–19 shows how to use this function. Example 11–19 getFaultAsString XPath Extension Function catchAll sequence assign from expression=bpelx:getFaultAsString to variable=faultVar part=message assign reply faultName=ns1:myFault variable=faultVar ... sequence catchAll

11.7 Throwing Internal Faults

A BPEL application can generate and receive fault messages. The throw activity has three elements: its name, the name of the fault, and the fault variable. The fault thrown by a throw activity is internal to BPEL. You cannot use a throw activity on an asynchronous process to communicate with a client. Throw activity syntax includes the throw name, fault name, and fault variable: throw name=delay faultName=nsPrefix:fault-1 faultVariable=fVar

11.7.1 How to Create a Throw Activity

To create a throw activity: 1. In the Component Palette, expand BPEL Constructs. 2. Drag a Throw activity into the designer. 3. Double-click and define the Throw activity. 4. Optionally enter a name or accept the default value.

5. To the right of the Namespace URI field, click the Search icon to select the fault to

monitor.

6. Select the fault in the Fault Chooser dialog, and click OK.

The namespace URI for the selected fault displays in the Namespace URI field. Your fault selection also automatically displays in the Local Part field. Figure 11–3 provides an example of a completed Throw dialog. This example shows the Throw_Fault_CC_Denied throw activity of the Scope_ AuthorizeCreditCard scope activity in the Fusion Order Demo application. This activity throws a fault for orders that are not approved.