Setting Correlation for the Asynchronous Request-Delayed Response MEP

12-18 Developers Guide for Oracle Application Integration Architecture Foundation Pack Figure 12–7 Example of Requester ABCS Process

12.5.2 Setting Correlation for the Asynchronous Request-Delayed Response MEP

In the process described in Section 12.5.1 you must set the correlation in two places: ■ Correlation Set Add a correlation ID and create a correlation set for the Invoke activity where the process would go into the dehydration store Add a correlation ID and create a correlation set for the Receive activity where the process would be recalled from the dehydration store after getting a delayed response from the provideredge application. ■ Correlation Property Add a standard name-value pair for each partnerLink that is linked to the Invoke or Receive activities where the correlation sets are defined as mentioned previously. The property should always be defined as correlation = correlationSet. 12.5.3 Programming Models for Handling Error Response in the Asynchronous Request-Delayed Response MEP This section discusses programming models for: ■ Using a separate service for error handling ■ Using JMS queue as milestone between RequesterABCS and the EBS ■ Using a parallel routing rule in the EBS Constructing the ABCS 12-19

12.5.3.1 Programming Model 1: Using a Separate Service for Error Handling

In this model, when a message is successfully processed, the response is sent back to the same requester that initiated the process. However, when the message errors out during the processing in the ProviderABCS, it is routed to a separate error handler service using ResponseEBS. An inbound message reaching the Requester ABCS is passed to the EBS which invokes the Provider ABCS, for the message processing. After the message is processed, the Provider ABCS pushes the message into a JMS Queue. If an error occurring during the processing of the message, an error response message should be constructed and the EBM response header should indicate that the response is indeed an error message. In a successful scenario, the response EBS routes the response message to the initiating requesterABS. In a failure scenario, the response EBS should route the message to an error handler service. This model has two transactions as shown in Figure 12–8 . Transaction 1 starts with de-queuing message by the requesterABCS or the external application directly calling the RequesterABCS. This transaction ends when the provider ABCS publishes either the reply or error message, as the case may be, to the JMS Queue. Figure 12–8 Programming Model 1: Using a Separate Service for Error Handling Note: Publish the messages to JMS Queue from Provider ABCS in both Success and Error scenarios, if the Provider ABCS is required to send the response or the error message. 12-20 Developers Guide for Oracle Application Integration Architecture Foundation Pack

12.5.3.2 Programming Model 2: Using JMS Queue as a Milestone Between Requester ABCS and the EBS

In this model, shown in Figure 12–9 , the requester ABCS publishes the inbound message to a JMS milestone. The transaction starts with de-queueing of the message by the requester ABCS or the external application directly calling the requester ABCS. The transaction ends with requester ABCS publishing the message to the JMS queue. A second transaction starts with de-queueing the message from the JMS queue and invoking EBS. The EBS routes the inbound message to the ProviderABCS for the processing. In the case of a successful message processing, the provider ABCS invokes the response EBS, using a native binding call, in the existing transaction. If an error occurs during the message processing, the provider ABCS publishes the errored-out message into another JMS queue. The response EBS picks up the message and invokes the fault handler service Figure 12–9 Programming Model 2: Using JMS Queue as a Milestone Between Requester ABCS and the EBS

12.5.3.3 Programming Model 3: Using a Parallel Routing Rule in the EBS

An inbound message reaching the Requester ABCS is passed to the EBS. The EBS routes the message to the Provider ABCS for the message processing, using a parallel routing rule. The transaction starts with de-queuing of the message by the requester ABCS or the external application directly calling the requester ABCS. The transaction ends when the EBS persists the inbound message for a queued execution. Figure 12–10 illustrates this programming model. A second transaction starts with de-queuing message from EBS. In case of a successful message processing, provider ABCS making a native binding call to the response EBS in the existing transaction. The response EBS routes the response to the requester ABCS by invoking another receive activity. In case of errors, the Provider ABCS makes a web service call to invoke the Response EBS thereby causing a new transaction to Tip: Use this Queue in the Provider ABCS Reference component ONLY for an Error scenario. Constructing the ABCS 12-21 start. In this transaction, the Response EBS is responsible for sending the error message back to the application using either Requester ABCS or directly. Figure 12–10 Programming Model 3: Using a Parallel Routing Rule in the EBS

12.5.4 What Tasks Are Required in Provider ABCS to Implement This MEP