How to Implement the Request-Delayed Response Pattern with the Two One-Way Calls of the EBS

Designing and Developing Enterprise Business Services 10-19

10.8 Implementing the Asynchronous Request-Delayed Response Message Exchange Pattern

The initiator of the request-delayed response pattern is a requesting service that invokes the request EBS and waits for a response. The requesting service can be a participating application, requester ABCS Impl, or an EBF. In each of these cases, the request payload is an EBM request and the response payload is an EBM response. For an error in the providing service, a response message with error information is constructed and returned to the requesting service for action. This section includes the following topics: ■ Section 10.8.1, How to Implement the Request-Delayed Response Pattern with the Two One-Way Calls of the EBS ■ Section 10.8.2, Creating Mediator Routing Services for Asynchronous Request-Delayed Response Patterns with Two One-Way Call EBS ■ Section 10.8.3, Asynchronous Request-Delayed Response MEP Error Handling For more information about enabling the ABCS both requester and provider see Chapter 11, Designing Application Business Connector Services , Chapter 12, Constructing the ABCS , and Chapter 13, Completing ABCS Development . For more information about enabling the EBF, see Chapter 15, Designing and Constructing Enterprise Business Flows .

10.8.1 How to Implement the Request-Delayed Response Pattern with the Two One-Way Calls of the EBS

To implement the request-delayed response pattern with the two one-way calls of the EBS: 1. Create EBS WSDLs. 2. Create Mediator routing services for asynchronous request-delayed response patterns with two one-way call EBSs. 3. Route the request from the requesting service to the correct providing service in the routing service of the one-way call operation of the request EBS. 4. Implement error handling for logging and notification based on fault policies. 5. Route the response message in the EBS response to the correct requesting service. Figure 10–4 illustrates the request-delayed response pattern: Note: Perform these steps in addition to the regular steps required for the requesting service and the providing service. 10-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 10–4 Request-Delayed Response Pattern

10.8.1.1 How to Create the EBS WSDLs for the Request-Delayed Response MEP

To create the EBS WSDLs for the request-delayed response MEP: 1. For the entity EBS, use the WSDLs from the Enterprise Service Library of the Foundation Pack. 2. For the process EBS, use the TemplateEBS.wsdl available in the Foundation Pack and create a Process EBS WSDL. 3. The EBS WSDLs must have two portTypes: ■ PortType for all operations used for modeling synchronous request-response operations and request-only operations. The name must not specify the Request. Service operations supporting the synchronous request-response MEP must be defined in one portType, and the operation must have input, output, and fault message defined. ■ PortType for asynchronous response operations. The name must specify Response. Service operations supporting asynchronous request-response pattern must have two operations, one operation for sending the request message and another for processing the response message. 4. Two Mediator routing services must be created for each of the portTypes. 10.8.2 Creating Mediator Routing Services for Asynchronous Request-Delayed Response Patterns with Two One-Way Call EBS To create Mediator routing services: 1. Create Mediator projects. Designing and Developing Enterprise Business Services 10-21 2. Create routing services. 3. Create routing rules.

10.8.2.1 How to Create Mediator Projects for the Request-Delayed Response MEP

To create Mediator projects for the request-delayed response MEP: 1. Create two Mediator projects, one for each of the portTypes in the EBS WSDL. If all of the services operations for an EBS have either synchronous request-response or fire-and-forget pattern, then all of these operations must reside in only one portType, so only one Mediator routing service is used. If the EBS has at least one asynchronous request-response operation, then two portTypes must exist, two Mediator Routing Services and two Mediator Projects one for each routing service. 2. Follow the naming convention detailed in Chapter 29, Oracle AIA Naming Standards for AIA Development . Examples of typical names for the Mediator projects are: ■ CustomerPartyEBSV2 This example has a routing service with all operations for synchronous request-response and request-only. ■ CustomerPartyEBSResponseV2 This example has a routing service with all operations for asynchronous request-response.

10.8.2.2 How to Create Routing Services

To create routing services for the request-delayed response MEP: 1. Put the EBS WSDL created into the Mediator project folder. 2. Create a routing service and name according to the naming convention detailed in Chapter 29, Oracle AIA Naming Standards for AIA Development . 3. Select the WSDL. The WSDL must be parsed and the portType name filled in the portType field of the routing service. 4. Select the portType matching with the routing service. Save the routing service. The routing service created for a portType must have all the operations, including compensate operations, specified in that portType in the EBS WSDL.

10.8.2.3 How to Create Routing Rules

For the asynchronous request-delayed response EBS, routing rules must be created for both request and response. Routing Rules for Request EBS The routing rules for request EBS are the same as those explained in the synchronous request-response section. Note: These guidelines are in addition to the implementation of asynchronous message exchanging patterns. 10-22 Developers Guide for Oracle Application Integration Architecture Foundation Pack For more information, see Section 10.7.3, How to Create Routing Services for the Synchronous Request-Response MEP . Routing Rules for Response EBS There must be two routing rules. To create routing rules for the response EBS: 1. Routing to the correct requesting service. When multiple requesting services from multiple participating applications are invoking a request EBS and are waiting for a delayed response, then you must route the response to the correct requesting service. As illustrated in Figure 10–5 , set the EBMHeaderSenderWSAddresswsa:ReplyTowsa:ServiceName to the name of the requesting service name in the requesting service-Application Business Message ABM to EBM transformation-before invoking the request EBS. Figure 10–5 Structure of the WSAddress Type Element In the providing service, this information is transferred from the request EBM to the response EBM. This information is used in the response EBS by putting a routing rule in the filter as: EBO NameResponseEBM\corecom:EBMHeader\Sender\ WSAddresswsa:ReplyTowsa:ServiceName = Requesting Service Name The target endpoint for the evaluation of this rule should be set to the requesting service. For every requesting service of the request EBS that is waiting for a response EBS to send back a response, specify a routing rule as shown above. 2. CAVS routing rule. Designing and Developing Enterprise Business Services 10-23 The CAVS routing rules are the same as that explained in the Sync Request-Response section. For more information about enabling the ABCS both requester and provider see Chapter 11, Designing Application Business Connector Services , Chapter 12, Constructing the ABCS , and Chapter 13, Completing ABCS Development . Error Handling Implementation For more information, see Section 24.5, Implementing Error Handling and Recovery for the Asynchronous Message Exchange Pattern to Ensure Guaranteed Message Delivery.

10.8.3 Asynchronous Request-Delayed Response MEP Error Handling