Guidelines for BPEL Catch and Catch-All Blocks Guidelines for Defining Fault Policies Configuring Fault Policies to Not Issue Rollback Messages

24-18 Developers Guide for Oracle Application Integration Architecture Foundation Pack

24.5.3.2 Configuring All Services to Participate in a Single Global Transaction

Configure a single global transaction as follows: ■ Ensure that no commit points are between two milestones. ■ Ensure that the work done between two milestones is one logical unit of work. For more information about configuring the global transaction, see Chapter 10, Designing and Developing Enterprise Business Services , Chapter 11, Designing Application Business Connector Services , Chapter 12, Constructing the ABCS , and Chapter 15, Designing and Constructing Enterprise Business Flows.

24.5.4 Guidelines for BPEL Catch and Catch-All Blocks

This section includes the following topics: ■ Section 24.5.4.1, Handling Run-time Faults Defined in the Fault Policy File ■ Section 24.5.4.2, Handling Run-time Faults Not Defined in the Fault Policy File

24.5.4.1 Handling Run-time Faults Defined in the Fault Policy File

For each of the run-time faults that has been defined in the fault policy xml file, have a catch block in the BPEL. In the catch block, rethrow the fault that has been caught. This will enable the process to appear as faulted in the Oracle Enterprise Manager Console.

24.5.4.2 Handling Run-time Faults Not Defined in the Fault Policy File

Each BPEL process should also have a catch-all block to process run-time faults that are not caught in catch-blocks and not defined in the fault policy file. To define the catch-all block: 1. Construct an Oracle AIA fault message. Populate the AIA Fault message with ECID as shown in Example 24–15 . Example 24–15 AIA Fault Message with an ECID Defined copy from expression=ora:getECID to variable=AIAFaultMessage part=AIAFault query=corecom:Faultcorecom: FaultNotificationcorecom:FaultingServicecorecom:ExecutionContextID copy 2. Invoke the AIAAsyncErrorHandlingBPELProcess with this Oracle AIA fault message as input. 3. Throw the AIA fault message. This will enable the process to appear as faulted in the Oracle Enterprise Manager Console. 4. Unless otherwise required, these catch and catch-all blocks can be defined at the top-level scope and do not need to be defined at the scope for each partner link. For more information, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite.

24.5.5 Guidelines for Defining Fault Policies

For more information, see Section 24.4.1.1, Defining a Fault Policy XML File for Handling Run-time Faults. Configuring Oracle AIA Processes for Error Handling and Trace Logging 24-19

24.5.6 Configuring Fault Policies to Not Issue Rollback Messages

According to the guaranteed message delivery programming model, when a message cannot be delivered to a service or component in the flow of a global transaction, the message is rolled back to the appropriate source milestone. This source milestone corresponds to an Oracle Advanced Queue, JMS Topic, or Mediator Resequencer Store. The message will be persisted here until it can be resubmitted for delivery to the service or component. The BPEL processes along the transaction rollback path will issue fault messages and should be configured to not issue rollback messages as well. The configuration deciphers a rollback transaction so that services in the rollback path do not issue unnecessary notifications. Without this configuration to suppress rollback messages, these processes will issue unnecessary notifications. For example, in the transaction rollback flow illustrated in Figure 24–4 , redundant rollback notifications would be sent out by the Requester ABCS, in addition to the one sent out by the Provider ABCS, which is the only one that should be issued. Figure 24–4 Transaction Rollback Flow To suppress unnecessary notifications for a rollback transaction: ■ Use bpelx:rollback instead of throw in the catch blocks: throw name=ThrowEBSFault faultName=bpelx:rollback ■ Use a Java snippet to invoke the Oracle AIA Error Handler, as shown in Example 24–16 . Example 24–16 Java Snippet to Invoke the Oracle AIA Error Handler bpelx:exec name=Java_Embedding_1 language=java version=1.5 [CDATA[ oracle.apps.aia.core.eh.InvokeBusinessErrorHandler.process oracle.xml.parser.v2.XMLElementgetVariableDatainputVariable, FaultMessage,ns1:Fault;]] bpelx:exec ■ Add an empty no-op action to the fault policies of Mediator and BPEL processes along the transaction rollback flow. This empty no-op action is aia-no-action. When a Mediator or BPEL process receives a rollback message, the control will be directed to the class oracle.apps.aia.core.eh.CompositeJavaNoAction, which is implemented against the aia-no-action action. The oracle.apps.aia.core.eh.CompositeJavaNoAction class is an empty operation, meaning that it does nothing, and thus suppresses further notifications in the rollback flow. 24-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack These sample BPEL and Mediator fault policies illustrate the way in which these conditions should be defined in impacted fault policy files. The aia-no-action fault policy contains a filter expression to perform no action in the case of the rollback fault ORABPEL-02180. An example is illustrated in Example 24–17 . Example 24–17 Sample Fault Policy Using the aia-no-action No-op Action ?xml version=1.0 encoding=UTF-8? faultPolicy version=2.0.1 id=SamplesCreateCustomerPartyPortal ProvABCSImplFaultPolicy xmlns:env=http:schemas.xmlsoap.orgsoap envelope xmlns:xs=http:www.w3.org2001XMLSchemaxmlns=http:schemas. oracle.combpelfaultpolicyxmlns:xsi=http:www.w3.org2001XMLSchema- instance Conditions faultNamexmlns:plmfault=http:xmlns.oracle.comEnterpriseServices CoreCustomerPartyV2 name=plmfault:fault condition testfault.summarysummary[contains., ORABPEL-02180]test action ref=aia-do-nothing condition condition action ref=aia-ora-java condition faultName faultName condition testfault.summarysummary[contains., ORABPEL-02180]test action ref=aia-do-nothing condition condition action ref=aia-ora-java condition faultName Conditions Actions -- This action will attempt 8 retries at increasing intervals of 2, 4, 8, 16, 32, 64, 128, and 256 seconds. -- Action id=aia-ora-retry retry retryCount1retryCount retryInterval2retryInterval exponentialBackoff retryFailureAction ref=aia-ora-java retrySuccessAction ref=aia-ora-java retry Action -- This is an action will cause a replay scope fault -- Action id=ora-replay-scope replayScope Action -- This is an action will bubble up the fault -- Action id=ora-rethrow-fault rethrowFault Action -- This is an action will mark the work item to be pending recovery from console -- Action id=ora-human-intervention humanIntervention Configuring Oracle AIA Processes for Error Handling and Trace Logging 24-21 Action -- This action will cause the instance to terminate -- Action id=ora-terminate abort Action Action id=aia-do-nothing javaAction className=oracle.apps.aia.core.eh.CompositeJavaNo Action defaultAction=ora-rethrow-fault returnValue value=REPLAY ref=ora-terminate returnValue value=RETRHOW ref=ora-rethrow-fault returnValue value=ABORT ref=ora-terminate returnValue value=RETRY ref=aia-ora-retry returnValue value=MANUAL ref=ora-human-intervention javaAction Action Action id=aia-ora-java javaAction className=oracle.apps.aia.core.eh.CompositeJava Action defaultAction=ora-rethrow-fault returnValue value=REPLAY ref=ora-terminate returnValue value=RETRHOW ref=ora-rethrow-fault returnValue value=ABORT ref=ora-terminate returnValue value=RETRY ref=aia-ora-retry returnValue value=MANUAL ref=ora-human-intervention javaAction Action Actions faultPolicy

24.5.7 Using the Message Resubmission Utility API