Skip Headers
Oracle® Application Server Integration B2B User's Guide
10g Release 2 (10.1.2.0.2)
B19370-01
  Go To Table Of Contents
Contents
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Index
Index

Previous
Previous
Next
Next
 

4 Communicating with Host Trading Partner Applications

OracleAS Integration B2B communicates with the back-end applications of the host trading partner—host applications—by using internal delivery channels. This chapter provides an overview of the predefined internal delivery channels available with OracleAS Integration B2B.

This chapter contains the following topics:

See "Managing Internal Delivery Channels" for details on creating an internal delivery channel.

Internal Delivery Channels in OracleAS Integration B2B

OracleAS Integration B2B provides the following predefined internal delivery channels to communicate with a host application.

You use these predefined internal delivery channels in integration configurations in which OracleAS Integration InterConnect, Oracle E-Business Suite, or Oracle BPEL Process Manager is used.

You use user-defined internal delivery channels to communicate with other host applications. The user-defined internal delivery channels use Oracle AQ, JMS, File or FTP queues.

When using either predefined or user-defined internal delivery channels, you select the channel to use with your host application when you create a trading partner agreement.

Integrations with OracleAS Integration InterConnect

OracleAS Integration B2B provides the following internal delivery channels to communicate with OracleAS Integration InterConnect:

OracleAS Integration InterConnect transforms message formats when the host and remote trading partner applications use different business document formats. The Oracle Advanced Queuing (AQ) adapter of OracleAS Integration InterConnect uses IP queues to send messages to and receive messages from OracleAS Integration B2B. You should set up the OracleAS Integration InterConnect AQ adapter to listen on the IP_IN_QUEUE, with the consumer name of the AQ adapter set to b2buser, as in aq_bridge_consumer_name=b2buser. When AQ is listening for a message sent by OracleAS Integration B2B, AQ must be set to publish. This publishes the message to the hub queue of OracleAS Integration InterConnect.

OracleAS Integration B2B processes all exchange protocol specific headers and enqueues the payload, along with a few attributes, to the IP queue. OracleAS Integration InterConnect picks up the message from the queue and transforms it, first to the common view, and then to the final format, and sends it to the host application.

By default, the B2B Inbound internal delivery channel connects to the IP_IN_QUEUE queue and the B2B Outbound internal delivery channel connects to the IP_OUT_QUEUE queue. These queues are defined as follows:

For OracleAS Integration InterConnect to recognize an incoming AQ message from OracleAS Integration B2B, the incoming AQ message structure must mirror the IP_IN_QUEUE structure. For OracleAS Integration B2B to recognize an outgoing AQ message from OracleAS Integration InterConnect, the outgoing AQ message structure must mirror the IP_OUT_QUEUE structure. In the case of IP_OUT_QUEUE, the message is coming from OracleAS Integration InterConnect to OracleAS Integration B2B, but it is an outbound message—going out from the application to the trading partner.

These two queues, IP_IN_QUEUE and IP_OUT_QUEUE, contain the IP_MESSAGE_TYPE object, which is described in Table 4-1 and provided as reference information.

Table 4-1 IP_MESSAGE_TYPE Parameters

Name Description Type

MSG_ID

A unique identification for the message.

  • For inbound messages, assigned by the trading partner

  • For outbound messages, assigned as part of the middleware process

VARCHAR2(128)

INREPLYTO_MSG_ID

The ID of the message that replies to MSG_ID.

  • Assigned to null if the middleware initiated the message

  • Assigned to MSG_ID when in response to a previous message

VARCHAR2(128)

FROM_PARTY

The trading partner that sends the message.

  • If the middleware initiates the message, assigned to the host trading partner

  • If the messages is a response, assigned to TO_PARTY

VARCHAR2(512)

TO_PARTY

The trading partner that receives the message.

  • If the middleware initiates the message, assigned to the remote trading partner

  • If the message is a response, assigned to FROM_PARTY

VARCHAR2(512)

ACTION_NAME

The business action that defines the document. Can be null.

VARCHAR2(512)

DOCTYPE_NAME

The document type as defined in OracleAS Integration B2B; for example, 850.

VARCHAR2(512)

DOCTYPE_REVISION

The document revision as defined in OracleAS Integration B2B; for example, 4010.

VARCHAR2(512)

MSG_TYPE

The type of message, for example, a response or a request message. Required. Supported values are:

0 INVALID

1 REQUEST

2 RESPONSE

3 ACKNOWLEDGMENT

4 IN_BAND_EXCEPTION

5 OUT_OF_BAND_EXCEPTION

6 STATUS_REQUEST

7 STATUS_RESPONSE

8 PULL

9 FUNCTIONAL_ACK

99 OTHER

NUMBER(38)

PAYLOAD

Message payload.

CLOB

ATTACHMENT

Attachment (optional).

BLOB


OracleAS Integration B2B provides the following options to enqueue and dequeue messages to and from internal delivery channels:

See Chapter 15, "Utilities for Enqueuing and Dequeuing" for details.

Integrations with Oracle E-Business Suite

OracleAS Integration B2B provides the following internal delivery channels to communicate with Oracle E-Business Suite:

For example, the host trading partner running the Oracle E-Business Suite iProcurement application can send its purchase order request to a remote trading partner using the secure and reliable B2B connectivity of OracleAS Integration B2B. Figure 4-1 shows how OracleAS Integration B2B, using one of the exchange protocols, conducts B2B transactions between a trading partner and Oracle E-Business Suite.

Figure 4-1 Using OracleAS Integration B2B with Oracle E-Business Suite

Description of Figure 4-1  follows
Description of "Figure 4-1 Using OracleAS Integration B2B with Oracle E-Business Suite"

By default, the XML Gateway Inbound internal delivery channel connects to the ECX_INQUEUE queue and the XML Gateway Outbound internal delivery channel connects to the ECX_OUTQUEUE queue. These two queues, ECX_INQUEUE and ECX_OUTQUEUE, contain the SYSTEM.ECXMSG message type, which is described in Table 4-2 and provided as reference information.

Table 4-2 SYSTEM.ECXMSG Parameters

Name Type

MESSAGE_TYPE

VARCHAR2(2000)

MESSAGE_STANDARD

VARCHAR2(2000)

TRANSACTION_TYPE

VARCHAR2(2000)

TRANSACTION_SUBTYPE

VARCHAR2(2000)

DOCUMENT_NUMBER

VARCHAR2(2000)

PARTYID

VARCHAR2(2000)

PARTY_SITE_ID

VARCHAR2(2000)

PARTY_TYPE

VARCHAR2(2000)

PROTOCOL_TYPE

VARCHAR2(2000)

PROTOCOL_ADDRESS

VARCHAR2(2000)

USERNAME

VARCHAR2(2000)

PASSWORD

VARCHAR2(2000)

PAYLOAD

CLOB

ATTRIBUTE1

VARCHAR2(2000)

ATTRIBUTE2

VARCHAR2(2000)

ATTRIBUTE3

VARCHAR2(2000)

ATTRIBUTE4

VARCHAR2(2000)

ATTRIBUTE5

VARCHAR2(2000)


See Oracle Applications Concepts, available at http://download-west.oracle.com/docs/cd/B12190_11/current/html/docset.html, for information about the E-Business Suite Home page, new in Release 11i.

Integrations with Oracle BPEL Process Manager

OracleAS Integration B2B provides the following internal delivery channels to communicate with Oracle BPEL Process Manager:

The B2B Inbound internal delivery channel connects to the IP_IN_QUEUE queue and the B2B Outbound internal delivery channel connects to the IP_OUT_QUEUE queue. These queues are defined as follows:

When you configure OracleAS Integration B2B to communicate with Oracle BPEL Process Manager, you follow the typical process flow in the user interface tool:

OracleAS Integration B2B collaborations and business actions represent the document revision, document type, and document definition that are exchanged with the trading partner and Oracle BPEL Process Manager.

Messages

All inbound and outbound messages include the AQ header, IP_MESSAGE_TYPE, and the document payload. This provides the information needed for routing. For outbound messages, IP_MESSAGE_TYPE must be populated to route the document to the trading partner.

See Table 4-1 for all the parameters of IP_MESSAGE_TYPE.

Headers

The following AQ header parameters provide routing information:

  • PRIORITY

  • CORRELATION

  • ATTEMPTS

  • ENQUEUETIME

  • ORIGMESSAGEID

The following IP_MESSAGE_TYPE parameters provide information for OracleAS Integration B2B to route the document to the appropriate trading partner.

  • MSG_ID

  • INREPLYTO_MSG_ID

  • FROM_PARTY

  • TO_PARTY

  • ACTION_NAME

  • DOCTYPE_NAME

  • DOCTYPE_REVISION

The Payload

The OracleAS Integration B2B document type defines the payload, which is defined in the PAYLOAD parameter of IP_MESSAGE_TYPE.

Internal Delivery Channels

OracleAS Integration B2B supports the following user-defined internal delivery channels:

  • Oracle AQ

  • JMS queues

  • File

  • FTP

See "Managing Internal Delivery Channels" on page 10-30 for details on defining an internal delivery channel.

Configuring OracleAS Integration B2B

Before you configure and deploy a trading partner agreement, ensure that oracle.tip.adapter.b2b.DocumentRouting is set to true. This parameter is found in the following OracleAS Integration B2B installation directory:

Oracle_Home\ip\config\tip.properties

A UUID is automatically generated for Document Routing ID in the Document Protocol Parameter. This UUID is used as a recipient/consumer for AQ so that the BPEL AQ adapter is able to pick up the corresponding message.

The B2B WSIL Browser

The B2B WSIL Browser enables B2B-BPEL interoperability. It is in B2B-BPEL.zip in the following OracleAS Integration B2B installation directory:

Oracle_Home\ip\install

See README.txt, located in B2B-BPEL.zip, for instructions on installing the B2B WSIL Browser.

The B2B WSIL Browser automates the configuration of the B2B connection and is invoked using the WSIF browser, which enables the B2B repository to be checked for deployed documents. The B2B WSIL Browser does the following:

  • Creates a WSDL for retrieving a deployed document (for example, 850)

  • Uses the default Oracle queues

  • Uses an AQ consumer for the document type selected

  • Uses an XML schema corresponding to the deployed document (for example, 850.xsd)

  • Uses IP_MESSAGE_TYPE as the AQ header

    (In JDeveloper BPEL Designer, variables are assigned to the AQ header message type header_msg and to the payload message type document_msg.)

Configuring Oracle BPEL Process Manager

To configure Oracle BPEL Process Manager to communicate with OracleAS Integration B2B, you do the following:

  • Create a partner link

  • Use the B2B WSIL Browser to browse the B2B document types

To invoke the B2B WSIL Browser, click the WSIL Browser icon (second from the left), as shown in Figure 4-2.

Figure 4-2 Create Partner Link Window

Description of Figure 4-2  follows
Description of "Figure 4-2 Create Partner Link Window"

To access B2B document types and generate a WSDL file for each document type that is deployed on the B2B server, navigate in the WSDL Chooser window as follows: Click Adapters, then B2B, and then navigate through the document protocol, document protocol revision, document type, and document definition, as shown in Figure 4-3.

Figure 4-3 Oracle BPEL Process Manager WSDL Chooser

Description of Figure 4-3  follows
Description of "Figure 4-3 Oracle BPEL Process Manager WSDL Chooser"

The WSDL Chooser displays only documents that have been deployed on the B2B Server. Selecting a document type generates a WSDL URL. In the example shown in the figure, selecting Acme_CONTROL generates the WSDL URL http://127.0.0.1:9700/BPELConsole/wsil/adapters/B2B/EDI_EDIFACT/EDIFACT_D3-D3/CONTRL/Acme_CONTROL?wsdl.

After the document is selected, you are returned to the Create Partner Link window. The WSDL file and Partner Link Type sections are populated. To send an outbound document from the BPEL Engine to the B2B Server, you must populate partnerRole with the B2BSend_% role. For the preceding example shown Figure 4-3, partnerRole will be B2BSend_CONTROL_EDIFACT_D3-D3. To receive an inbound document from the B2B Server to the BPEL Engine, you must populate myRole with the B2BReceive_% role. For the preceding example shown in Figure 4-3, myRole will be B2BReceive_CONTROL_EDIFACT_D3-D3. You must populate either partnerRole or myRole. Do not populate both or leave both unpopulated.

Oracle BPEL Process Manager Adapters

Oracle BPEL Process Manager provides the following adapters for interoperability with OracleAS Integration B2B:

  • Oracle AQ adapter

    • The B2B WSIL uses these default queues and is the recommended method.

    • You can configure the adapter manually to enqueue and dequeue documents from OracleAS Integration B2B

    • Trading partner information is defined in IP_MESSAGE_TYPE

  • JMS adapter

    The JMS header and properties define the trading partner information

  • File/FTP adapter

    Trading partner information is defined in the file names.

See Oracle Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide for more information.

Message Correlation

In OracleAS Integration B2B, a transaction typically contains only one message. Messages are automatically correlated by virtue of the business protocol being used. For example, RosettaNet supports correlation between documents through the PIPs. See the following for more information about message correlation:

In Oracle BPEL Process Manager, messages are correlated based on correlation sets. Oracle BPEL Process Manager uses the MSG_ID and INREPLYTO_MSG_ID parameters of IP_MESSAGE_TYPE to correlate messages.

For example, assume that Acme and GlobalChips exchange purchase order information using the EDI X12 over Internet (AS2) business protocol, as shown in Figure 4-4. GlobalChips initiates the transaction by sending the inbound purchase order. Acme receives the purchase order and responds with an outbound purchase order acknowledgment. In OracleAS Integration B2B, you define the EDI X12 4010, 850, and 855 documents, the AS2 exchange, the remote trading partner, and the trading partner agreement. In Oracle BPEL Process Manager, you define a correlation set between the purchase order and the purchase order acknowledgment using the purchase order number. MSG_ID of the inbound purchase order is assigned to INREPLYTO_MSG_ID of the outbound purchase order acknowledgment.

See Oracle BPEL Process Manager Developer's Guide for more information.

Figure 4-4 Message Correlation in OracleAS Integration B2B and Oracle BPEL Process Manager

Description of Figure 4-4  follows
Description of "Figure 4-4 Message Correlation in OracleAS Integration B2B and Oracle BPEL Process Manager"

Integrations with Host Applications

You can define JMS, AQ, File, and FTP queues to communicate with host trading partner applications by defining your own internal delivery channels. You use user-defined internal delivery channels in integration configurations in which OracleAS Integration InterConnect or another transformation tool is not used. You also create a callout and callout usages.

See "Creating an Internal Delivery Channel" and "Example: Creating an Internal Delivery Channel Using the JMS Transport Protocol" for more information.

Overview of Callouts

Consider the example of a remote trading partner who sends a RosettaNet XML-formatted purchase order request to the host trading partner. The host trading partner application is an Oracle E-Business Suite application that does not understand RosettaNet XML-formatted messages. To enable communication between these two different formats, you create a callout that consists of callout usages. In this example, one callout usage transforms the RosettaNet XML-formatted purchase order request into an Oracle E-Business Suite XML format understood by the Oracle E-Business Suite application. Oracle E-Business Suite application, in turn, responds to the request message with a purchase order acceptance message in Oracle E-Business Suite XML format. This message is transformed by another callout usage back into a RosettaNet XML-formatted message for the remote trading partner.

You create two separate internal delivery channels for these messages:

When you create a trading partner agreement between the host and remote trading partners, you associate the initiating internal delivery channel with the initiating callout usage that transforms the purchase order request from RosettaNet XML to Oracle E-Business Suite XML. You also associate the responding internal delivery channel with the responding callout usage that transforms the purchase order acceptance from Oracle E-Business Suite XML to RosettaNet XML.

By default, the initiating internal delivery channel and callout usage are available for selection when you create a trading partner agreement. If you also want a responding internal delivery channel and responding callout usage to be available for selection, you must select Yes from the Is acknowledgement handled By Integration B2B? list on the Create Trading Partner - Operational Capability page or Create Supported Collaboration Role page when you create a trading partner.

See Chapter 11, "Managing Callouts" for more information.

Chapter Summary

This chapter describes how OracleAS Integration B2B communicates with host applications through the following internal delivery channels: B2B Inbound, B2B Outbound, XML Gateway Inbound, and XML Gateway Outbound.