Introduction to MEPs Choosing the Appropriate MEP

Designing Application Business Connector Services 11-7 4. Tabulate the mapping between the Enterprise Business Object EBO attributeselements and the application objects attributeselements in a spreadsheet. Remember these points when creating the transformation maps: 5. For an ABM being mapped to an EBM, ensure that an attempt is made to populate all of the data elements present in the ABM to the relevant elements in the EBM. In situations in which the ABM does not have all of the content to supply all of the data elements in the EBM, you must work with the respective requester application teams to identify the application services that could be used to enter the content in the EBM. For example, a Siebel application invoking the CreateOrder ABCs might supply only the Siebel Customer ID in the ABM that is being passed as the payload. However, the EBM to be passed as a payload to the CreateOrder EBS operation expects all the information regarding the Customer. So the CreateOrder ABCS is responsible for invoking a Siebel service to retrieve complete Customer details from the Siebel application and populate the EBM. Although the integration platform provides support for this pattern, we highly recommend that you work with the participating application to ensure that the payload being passed to the ABCS is as close to the shape of the EBM as possible to minimize the chattiness.

11.3 Identifying the MEP

The possible interaction types between an ABCS and its client are: ■ Synchronous request-response ■ Asynchronous request only ■ Asynchronous request-delayed response MEPs vary in functionality and usage depending on the role of the ABCS. For more information about MEPs, see Understanding Interaction Patterns in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

11.3.1 Introduction to MEPs

Synchronous Request-Response Pattern ■ A requester sends a request to a provider, who processes the request and sends back a response. ■ The requester is in a suspended mode until the response is received from the provider. ■ Results are in real-time response or error feedback. Asynchronous Request Only ■ The message exchange is one-way, with a requester sending a request to a provider. No response comes from provider to requester. ■ The requester is free, after request submission, to resume normal execution. Asynchronous Request - Delayed Response ■ This involves two one-way invocations. 11-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack ■ First, a one-way message is sent from requester to provider. At a later time, another one-way message is returned from the provider to the original requester. ■ Two distinct one-way messages are correlated. For more information about MEPs, see Understanding Interaction Patterns in the Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

11.3.2 Choosing the Appropriate MEP

■ Identify how the participating applications interact with the ABCS for inbound as well as outbound interactions. ■ Identify whether the requester application must be in a call-waiting state until it has received the response from the provider application. Waiting until the response is received from the provider application forces the requester application to invoke the ABCS in a synchronous manner. For example, a CRM application submitting a request to retrieve account details from a billing application would fit this scenario. In this case, the requester cannot perform any task until the response is received. On the other hand, sending a request from the CRM application to create a customer in a billing application can be done in an asynchronous manner. After publishing an outbound request, the CRM application can move to the next activity without having to wait until the provider application has successfully created a customer. In this case, the CRM application invokes this outbound request in an asynchronous manner. Applications can leverage different kinds of integration technologies for synchronous versus asynchronous invocations. You must select the most appropriate technology based on the situation. For more information about how AIA services interact with applications, see Chapter 21, Establishing Resource Connectivity. In a single flow, even though the requester ABCS MEP is influenced by the MEP for the EBS operation to be invoked, the requester applications interaction capabilities influence the MEP for requester ABCS. For provider ABCS, the MEP is predominantly influenced by the MEP of the EBS operation.

11.3.2.1 When to Use the Synchronous Request-Response MEP

Most of the cases involving Query and Validate need this pattern because the participating application that initiated the request is waiting for the response. For all the other cases, the suitability of this pattern is determined by the demands of the response time and possibility of meeting those requirements based on the amount of processing to be done. The MEP between requester ABCS and EBS is synchronous. The MEP between provider ABCS and participating application servicing the request can be either synchronous or asynchronous. For more information about Query, see Section 12.8.7, Query . For more information about Validate, see Section 12.8.5, Validate . Use Case CRM Application requesting account details about a customer from the billing system Designing Application Business Connector Services 11-9 Figure 11–3 illustrates the two-way communication between AIA services, requester ABCS, and CustomerPartyEBS. Figure 11–3 GetAccountBalanceSummary Integration Scenario

11.3.2.2 When to Use the Asynchronous Request Only Fire-and Forget MEP

Use this pattern when: ■ The requester ABCS receives the request message from the participating application and ends with invoking of the EBS. In this case, no response comes from the EBS to the requester ABCS and no response is made to the participating application that initiated the request. ■ The provider ABCS receives the request message from the EBS and ends with invoking the provider participating application API. No response is made to the EBS that initiated the request. Use Case A CRM application submitting a request to the BRM application to create CustomerParty From the perspective of the participating application, Siebel, a request message to the BRM application to create a CustomerParty is enqueued for processing at a later time. 11-10 Developers Guide for Oracle Application Integration Architecture Foundation Pack The Siebel application is free to resume its processing immediately. The request message is dequeued from the queue and is processed in an asynchronous fashion. Figure 11–4 illustrates the one-way invocation between AIA services, Requester ABCS, and CustomerPartyEBS. Figure 11–4 Example of One-Way Invocation

11.3.2.3 When to Use the Asynchronous Request Delayed Response MEP

Use this pattern when: ■ The requester ABCS receives the request message, processes the message, and finally updates the participating application that initiated the request by invoking an API exposed by the participating application. The participating application is not waiting for the response. ■ The provider ABCS receives the request message from the EBS Request mediator service, processes the message, and finally responds to the requesting service-requester ABCS or Enterprise Business Flow EBF-by invoking the response operation of the EBS Response mediator service. The EBS Mediator service is not waiting for the response. Designing Application Business Connector Services 11-11 The MEP between requester ABCS and EBS can be synchronous or asynchronous, and between the provider ABCS and the provider participating application can also be synchronous or asynchronous.

11.4 Technology Options