C Synchronous Request/Reply Support

This appendix describes how to configure Oracle JDeveloper and Oracle B2B to enable synchronous request and reply support in Oracle B2B.

The appendix contains the following topics:

C.1 Introduction

Oracle B2B provides synchronous request/response between from Fabric to Oracle B2B. However, only HTTP transport is supported for the initial release. Figure C-1 shows the end-to-end scenario.

Figure C-1 Synchronous Request/Reply

Description of Figure C-1 follows
Description of "Figure C-1 Synchronous Request/Reply"

C.2 Configuring Sender

To configure the sender, you need to perform the following tasks:

C.2.1 Configuring Oracle JDeveloper

You need to use B2B Configuration Wizard in Oracle JDeveloper to configure the sender for synchronous request/reply support:

C.2.2 Configuring Oracle B2B

In Oracle B2B console, you need to:

  • Set up Oracle B2B agreements: You need to define two agreements. One agreement is required to send the Request, and the other agreement is needed to receive the Response as shown in Figure C-4. You do not need to set up any Oracle B2B property for this. Based on the call from the Fabric to Oracle B2B, the message type "sync request" is determined.

    Figure C-4 Setting Up Oracle B2B Agreements

    Description of Figure C-4 follows
    Description of "Figure C-4 Setting Up Oracle B2B Agreements"

  • Create a Trading Partner channel: You need to create a remote Trading Partner Channel to point to http://server:port/b2b/syncreceiver as shown in Figure C-5. This is required if the communication is between two Oracle B2B products. Please note that the URL will be different if the communication takes place between two different B2B products.

    Figure C-5 Creating a Trading Partner Channel

    Description of Figure C-5 follows
    Description of "Figure C-5 Creating a Trading Partner Channel"

C.3 Configuring Receiver

To configure the receiver, you need to perform the following tasks:

C.3.1 Configuring Oracle JDeveloper

You need to use B2B Configuration Wizard in Oracle JDeveloper to configure the receiver for synchronous request/reply support:

C.3.2 Configuring Oracle B2B

In Oracle B2B console, you need to:

  • Set up Oracle B2B agreements: You need to define two agreements. One agreement is required to receive the Request, and the other agreement is needed to send the Response as shown in Figure C-8. You do not need to set up any Oracle B2B property for this. The synchronous HTTP receiver decides the message type as "sync request".

    Figure C-8 Setting Up Oracle B2B Agreements

    Description of Figure C-8 follows
    Description of "Figure C-8 Setting Up Oracle B2B Agreements"

  • Create a dummy Trading Partner channel: You need to create a dummy remote Trading Partner Channel, but this channel is not used at runtime. You can specify any URL value, but the value needs to be in the format http://host:port/xyz as shown in Figure C-9.

    Figure C-9 Creating a Dummy Trading Partner Channel

    Description of Figure C-9 follows
    Description of "Figure C-9 Creating a Dummy Trading Partner Channel"

C.4 Resubmitting Messages

Synchronous request or response resubmit must be done from the Application side. Although the Oracle B2B console allows resubmit of Application or Wire messages from Oracle B2B, however, it resubmits the messages in the as nonsynchronous mode. Sometimes, the message processing logic is nondeterministic. For example, if an Application or a Wire message is resubmitted from Sender side Oracle B2B, the message is posted to http://server:port/b2b/syncreceiver. The Receiver Oracle B2B processes the message as synchronous request or response. The response message on the Sender side is ignored.

C.5 Pre-defined Custom Response to SOA Composite

In a synchronous request /response messaging pattern, SOA composite sends a message to B2B and B2B in-turn posts the message to the trading partner (TP). However, when B2B does not receive any payload from the TP in a synchronous HTTP connection, the SOA composite is unable to determine if B2B has sent the message to the TP successfully as the composite does not receive any confirmation from B2B.

In general, if the composite does not receive an error in the calling thread, the synchronous call must be deemed successful. However, for complete assurance that B2B has sent the payload successfully, SOA composite must receive a positive response message from B2B when the TP has acknowledged receiving the payload with a HTTP status OK and not with a payload associated with the request/reply mechanism.

C.5.1 b2b.defaultsyncHTTPResponse

By using a new B2B property called b2b.defaultsyncHTTPResponse, SOA composite can receive a positive response message from B2B. This is a global flag.

For example, you can add the new parameter b2b.defaultsyncHTTPResponse=<Status>OK</Status> or b2b.defaultsyncHTTPResponse=OK.

If the TP acknowledges this with a transport level HTTP status OK (200) having no payload, then B2B constructs the content of the EM property into payload as inbound and forwards this to the SOA composite.

C.5.2 Pre-requisites

The following requirements must be met for using b2b.defaultsyncHTTPResponse B2B property:

  • Set the HTTP transport to be in synchronous mode. This way the value configured in b2b.defaultsyncHTTPResponse is returned to the composite

  • Set up a corresponding document definition and agreement so that the response value can be processed on its way back to the composite. Also, the composite to B2B invocation must also be a synchronous request/reply.

C.5.3 Defining a HTTP Response to a SOA composite with No Payload

To define a HTTP response to a SOA composite with no payload, do the following steps:

  1. In the Administration page, create a document under custom protocol. For more information about creating a document under custom protocol, see section Chapter 8, "Using the Custom Document Protocol" of this guide.

  2. Use the following details:

    1. Create Custom Version: e.g ”1.0”

    2. Under Version 1.0, create Document: e.g. &rsquor;SyncResp'

    3. Under Document, create Document Definition ”SyncRespDef” with the followings:

      Identification Type: Either XML or Flat

      In case of XML:

      Identification Expression (XPath): //Status

      Identification Value: OK

      In case of Flat:

      Identification Start Position:1

      Identification End Position:2

      Identification Value: OK

    4. If the document def type is defined as XML:

      b2b.defaultsyncHTTPResponse must be set as " <Status>OK</Status>"

    5. If the document def type is defined as Flat:

      b2b.defaultsyncHTTPResponse must be set as ”OK”

  3. Create agreement associated with trading partner for custom document protocol.

    Add Generic Identifier for both Host and Remote trading partner