Configuring Milestones Implementing Error Handling for the Synchronous Message Exchange Pattern

Configuring Oracle AIA Processes for Error Handling and Trace Logging 24-13 In the case of an error, an exception is raised and the transaction initiated is rolled back with the message safe in the source. The message is either in the source or target and is not lost. For more information about configuring the global transaction, see Section 24.5.3, Configuring Services Between Milestones. ■ Error handling and recovery Any exceptions due to system or business errors must generate a rollback of all preceding services and trigger a single error notification to the Integration Administrator. This requires marking the message in the source as faulted, preventing it from being processed until the error condition is removed. For more information about configuring error rollback, see Section 24.5.6, Configuring Fault Policies to Not Issue Rollback Messages. In case of system errors, once the exception condition has been removed, the faulted messages in the source must be reset. This enables them to be resubmitted. The Message Resubmission Utility can be used to resubmit the messages for reprocessing by the correct source. In case of business errors, the faulted messages in the source must be removed and sent to fallout management for further action. Fallout management is a custom implementation in which the messages encountering business errors are segregated and processed separately. For example, suppose that orders submitted for processing encounter a business error. As a part of an Order Fallout Management implementation, the Order message and error message are routed to an application that introspects the error messages and raises a trouble ticket that provides an explanation of the error and the suggested remedial action. After the remedial action is taken, the order is reprocessed. Error handling and recovery for the asynchronous MEP are implemented as follows to ensure guaranteed message delivery: 1. Ensure that each message has a unique message identifier. 2. Populate the EBM header with the source milestone identifier. 3. Ensure that the fault notification contains the message identifier and source milestone identifier of the faulted message. 4. Use the Message Resubmission Utility to recover and resubmit a faulted message. For more information about how to implement these configurations, see Section 24.5.2, Configuring Milestones and Section 24.5.3, Configuring Services Between Milestones. For more information about using the Message Resubmission Utility, see Using the Message Resubmission Utility in Oracle Fusion Middleware Infrastructure Components and Utilities Users Guide for Oracle Application Integration Architecture Foundation Pack. For more information about the Message Resubmission Utility API, see Section 24.5.7, Using the Message Resubmission Utility API.

24.5.2 Configuring Milestones

As a part of implementing error handling and recovery for the asynchronous MEP to ensure guaranteed message delivery, messages must be persisted at milestones. The movement of messages between milestones must be guaranteed. A milestone can be a JMS queue or a JMS topic. 24-14 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 24–2 and Figure 24–3 illustrate a few possible milestone locations across an integration flow. Figure 24–2 Integration Flow in Which the Receiver Target Milestone is the Target Participating Application Figure 24–3 Integration Flow in Which the Receiver Target Milestone is Within the Global Transaction Space

24.5.3 Configuring Services Between Milestones