How to Implement Fault Handling in BPEL Processes

24-4 Developers Guide for Oracle Application Integration Architecture Foundation Pack template files. In this case, the tool will not create the XML elements property in the composite.xml. For more information, see Schema Definition File for Fault-policies.xml and Schema Definition File for Fault-bindings.xml in Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

24.3.1.1 Associating a Fault Policy File with Fault Policy Bindings File

The following example shows how to associate a fault policy defined in a sample fault-policy file with a fault-policy binding.xml file. Consider a sample fault policy file, SamplesQueryCustomerPartyPortalProvABCSImplFaultPolicy.xml, with the fault policies defined as shown in Example 24–2 . Example 24–2 Sample Fault Policy File with Fault Policies Defined faultPolicies xmlns=http:schemas.oracle.combpelfaultpolicy faultPolicy version=2.0.1 id=SamplesQueryCustomerPartyPortalProvABCSImplFaultPolicy . . . . . . . faultPolicy faultPolicies We need to associate the policies defined in the preceding fault policy file with the level of fault policy binding that you are using-either a SOA composite application or a component BPEL process or Oracle Mediator service component. To do this, you need to modify the template fault-bindings.xml file created by the AIA Service Constructor when the developer chooses to have a service-specific fault policy instead of using a default fault policy. In the fault-bindings.xml file, the association is done as shown in Example 24–3 . Example 24–3 Association in fault-bindings.xml faultPolicyBindings version=2.0.1xmlns=http:schemas.oracle.combpel faultpolicy xmlns:xsi=http:www.w3.org2001XMLSchema-instance compositefaultPolicy=SamplesQueryCustomerPartyPortalProvABCSImpl FaultPolicy faultPolicyBindings We recommend that the fault policy binding level be a SOA composite application by default because this conforms with our recommendation that a composite needs to be built with a single component in it.

24.3.2 How to Implement Fault Handling in BPEL Processes

To implement fault handling in a BPEL process: 1. Define an EBM HEADER variable in the BPEL process and populate it as the first step. The Error Handling Framework uses this variable to populate the fault message with contextual details from the Enterprise Business Message EBM header. If the Note: In this example, the association is made at the level of the SOA composite application. Configuring Oracle AIA Processes for Error Handling and Trace Logging 24-5 BPEL process is an Application Business Connector Service ABCS, then input is an Application Business Message ABM, and the EBM HEADER variable should be populated as soon as the ABM is converted to an EBM. This way, if the error occurs on a partner link after this transformation step, the Error Handling Framework will be able to access and use the EBM header details. 2. Define a fault policy for the BPEL process and bind the process with this policy in fault-bindings.xml. When you are using a service-specific fault policy file, always use the CompositeJavaAction, oracle.apps.aia.core.eh.CompositeJavaAction, as specified in the default policy. Including this CompositeJavaAction accounts for error notifications and error logging. For more information about how to define a fault policy XML file to handle business faults, see Section 24.4.2.1, Handling Business Faults. For more information about how to define a fault policy XML file to handle run-time faults in the synchronous message exchange pattern MEP, see Section 24.4, Implementing Error Handling for the Synchronous Message Exchange Pattern. For more information about how to define a fault policy XML file to handle run-time faults in the asynchronous MEP, see Section 24.5, Implementing Error Handling and Recovery for the Asynchronous Message Exchange Pattern to Ensure Guaranteed Message Delivery. 3. Define the catch blocks. The default behavior of the fault policy after the CompositeJavaAction is to do a rethrow. This returns the execution control to the catch or catch-all block specified in the BPEL process. In a way, interception of faults using a fault policy is transparent to you because the CompositeJavaAction rethrows the same fault that has been intercepted by it. So in BPEL, you must catch the fault, such as a binding or remote fault, which is expected out of the invoke activity. Hence, define a catch block for each business fault and run-time fault that can be expected at design time. 4. Define a catch-all block. This assists in catching any unexpected errors that may occur while you are running the process. For more information about defining BPEL catch and catch-all blocks for the synchronous request-response MEP, see Section 24.4.2, Guidelines for BPEL Catch and Catch-All Blocks in Synchronous Request-Response. For more information about defining BPEL catch and catch-all blocks for the asynchronous MEP, see Section 24.5.4, Guidelines for BPEL Catch and Catch-All Blocks.

24.4 Implementing Error Handling for the Synchronous Message Exchange Pattern