Guaranteed Delivery Pattern: How to Ensure Guaranteed Delivery in AIA

25-4 Developers Guide for Oracle Application Integration Architecture Foundation Pack The AIA composite business process may not be up and running while the application continues to produce the messages in the JMS queue. When the AIA composite business process comes up, it starts consuming the messages and processes them. Figure 25–2 also shows how the monitoring services can be decoupled from the main AIA functional flows with the help of the JMS queue. All the AIA services and the participating applications can fire a monitoring message into the queue and forget about how it is processed by the downstream applications. In this pattern the services or participating applications do not expect any response. Similarly, the AIA infrastructure services capture the system or business errors from the composite business processes and publish them to an AIA error topic, which is used by the error handling framework for further processing resubmission, notification, logging, and so on. Figure 25–2 Fire-and-Forget Pattern Using Queuing Technology Impact The default implementation does not have inherent support for notifying the requester application of success or the failure of messages. Even though the middleware systems provide the ability to monitor and administer the flow of in-flight message transmissions, there will be use cases where requester applications will either want to be notified or have a logical reversal of work done programmatically. For more information about how compensation handlers can be implemented for this message exchange pattern, see Chapter 11, Designing Application Business Connector Services and Chapter 12, Constructing the ABCS .

25.1.3 Guaranteed Delivery Pattern: How to Ensure Guaranteed Delivery in AIA

Problem Message delivery cannot be guaranteed when the participating systems and the services integrating those systems interact in an unreliable fashion. For example, the Order Capture system might submit an order fulfillment request that triggers a business process, which in turn invokes the services provided by multiple Working with AIA Design Patterns 25-5 disparate systems to fulfill the request. Expecting all of the service providers to be always available might be unrealistic. Solution A milestone is a message checkpoint where the enriched message is preserved after completing a certain amount of business functionality at this logical point or is submitted to the participating application for further processing of that message in an end-to-end composite business process. A milestone helps to commit the business transactions done to that logical point and also releases the resources used in the AIA services and the participating application. AIA recommends introducing milestones at appropriate logical points in an end-to-end integration having the composite business processes, business activity services, or data services designed and implemented for integrating disparate systems to address a business requirement. Queues with database or file as persistence store are used to implement milestones. Figure 25–3 shows how to ensure guaranteed delivery with the help of milestones for a simple use case where the customer service representative updates the billing profile on the source application and the updated profile is reflected in the back-end billing systems. Figure 25–3 Ensuring Guaranteed Delivery Using Milestones AIA recommends that the source application push the billing profile information to Milestone -1 JMS Queue in a transactional mode to ensure the guaranteed delivery of the message. This transaction is outside the AIA transaction boundaries and is not shown in the diagram. Once the billing profile information is stored in Milestone-1, the source application resources can be released because AIA ensures the guaranteed delivery of that message to the target application. The implementation service has the message enrichment logic if needed and the Enterprise Business Service EBS routes the enriched message to appropriate providers or Milestone-2 optional for very simple and straightforward use cases such as no enrichment or processing requirements for implementation service. All the enriched messages would either be transferred to Milestone-2 or rolled back to Milestone - 1 for corrective action or resubmission. To achieve this, all the services present between Milestone-1 and Milestone-2 must enlist themselves in a single global transaction. Once the messages are transferred to Milestone-2, all the Milestone-1 implementation service instances are released to accommodate new requests. The provider implementation service picks up the billing profile information and ensures the message is delivered to the target application. The target application may or may not have the capability of participating in the transaction between Milestone-2 and Milestone-3 so the implementation service should be designed to take care of the compensatory transactions. 25-6 Developers Guide for Oracle Application Integration Architecture Foundation Pack AIA recommends that the target application build the XA capability to ensure guaranteed delivery. If the target application does not have the XA capability, the implementation service should be designed for manual compensations or semi-automatic or automatic compensations based on the target systems capability to acknowledge the business message delivered from AIA. Figure 25–4 shows the usage of milestones to ensure guaranteed delivery for a complex use case where the source system submits an order provisioning request to AIA. Figure 25–4 Using Milestones to Ensure Guaranteed Delivery in a Complex Use Case Impact Introducing a milestone adds processing overhead and could impact the performance of composite business processes, business activity services, or data services. So selecting the number of milestones is a challenge for the designers. However, minimizing the milestones, thereby adding more work to a single transaction, could also have a detrimental effect. Ensuring reliable messaging between the milestones and the application and milestone to achieve the guaranteed delivery adds transactional overheads. This could impact the performance at run time in some situations if the amount of work to be done between two milestones is too large and may also require additional process design requirements for compensation. Working with AIA Design Patterns 25-7

25.1.4 Service Routing Pattern: How to Route the Messages to Appropriate Service Provider in AIA