Interfacing with Transport Adapters

13-16 Developers Guide for Oracle Application Integration Architecture Foundation Pack

13.2.1 How to Handle Errors and Faults

■ In synchronous request-response message exchange patterns MEPs, the requesting services are waiting for response. Whenever an error occurs in the provider services, an exception is raised and the fault message is propagated back to the requesting service. ■ In asynchronous fire-and-forget MEPs, the requesting service does not expect a response. If an error occurs in the providing service, compensation may be needed. In such situations, the compensatory operations in EBS must be used for triggering compensations. ■ In asynchronous request-delayed response MEPs, the requesting service is in a suspended mode, waiting for a response. If an error occurs in the providing service, the response to the requesting service includes details about the error. For details on implementing the ABCS and EBS services in this scenario, see Section 12.5, Implementing the Asynchronous Request Delayed Response MEP. For more information about implementing error handling in BPEL and Mediator processes in each of the MEPs, see Chapter 24, Configuring Oracle AIA Processes for Error Handling and Trace Logging . ■ In an asynchronous MEP, the message initiated from a sender is persisted until it is successfully delivered to and acknowledged by the receiver, if an acknowledgment is expected. The sender and receiver are not necessarily the participating applications. Rather, they can be logical milestones in an Oracle AIA integration scenario. Each persistence store represents a milestone and may be a database, file system, or JMS persistence. Multiple milestones may be configured in an integration scenario to ensure the movement of messages from one persistence point to another. For more information about configuring milestones for Guaranteed Message Delivery in an Integration flow, see Chapter 24, Configuring Oracle AIA Processes for Error Handling and Trace Logging .

13.3 Working with Adapters

This section discusses working with transport and version adapters. This section includes the following topics: ■ Section 13.3.1, Interfacing with Transport Adapters ■ Section 13.3.2, How to Develop Transport Adapters ■ Section 13.3.3, When to Put Adapters in a Single Composite ■ Section 13.3.4, Planning Version Adapters ■ Section 13.3.5, How to Configure a Version Adapter

13.3.1 Interfacing with Transport Adapters

Use transport adapters to interface with the ABCS in these scenarios: ■ For packaged applications, such as Siebel, PeopleSoft, J.D. Edwards, and SAP, the preferred route is to use the respective packaged-application adapters. These Completing ABCS Development 13-17 adapters can be deployed as JCA resource adapters. This solution is better than using the conventional SOAP interface. ■ In situations for which the participating applications do not expose their business logic as Web services, interactions with these applications must occur using technology adapters such as database adapters, JMS adapters, and so forth. Transport adapters allow connectivity to the systemsapplications that were not originally developed using Web services technologies. Some examples of applications that can use adapters are: ■ Systems that use non-xml for communication ■ Packaged software ■ Database systems ■ Data sources or persistent stores such as JMS, and so on Investigate whether or not the services exposed by the participating applications provide support for proprietary message formats, technologies, and standards. If the applications that implement the functionality do not have inherent support for standards and technologies such as XML, SOAP, and JMS, then the transformations must happen in the ABCS. For example, the application might be able to receive and send messages only using files, and EDI is the only format it recognizes. In this case, the ABCS is responsible for integrating with the application using a file adapter, translating the EDI-based message into XML format, exposing the message as a SOAP message. When to Use Adapters for Message Aggregation In some situations, you must combine responses to a request that originated from multiple sources. For example, for convergent billing in the telecommunication solution, the Application Business Connector Service for the getBillDetails EBS might have to retrieve details from multiple participating applications. For more information about the Message Aggregation design pattern, see Chapter 25, Working with AIA Design Patterns . When to Use Adapters for Event Aggregation The Event Aggregation model provides a comprehensive methodology for the business use case in which events, entity, or message aggregation is needed. In such scenarios, multiple events are raised before the completion of a business message, and all such fine-grained message events are consolidated into a single coarse-grained event. In such use cases, a requester ABCS is invoked by an event consumer adapter service, which feeds the requester ABCS with an aggregated event message. For more information about the event aggregation design pattern, see Chapter 25, Working with AIA Design Patterns .

13.3.2 How to Develop Transport Adapters