|
Oracle® Application Server Integration B2B User's Guide
10g Release 2 (10.1.2.0.2) B19370-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Integration B2B User's Guide
10g Release 2 (10.1.2.0.2) B19370-01 |
|
|
Previous |
Next |
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.
OracleAS Integration B2B provides the following predefined internal delivery channels to communicate with a host application.
B2B Outbound and B2B Inbound—internal delivery channels for OracleAS Integration InterConnect and Oracle BPEL Process Manager
XML Gateway Outbound and XML Gateway Inbound—internal delivery channels for Oracle E-Business Suite
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.
"Creating a Trading Partner Agreement" for information on selecting an internal delivery channel
OracleAS Integration B2B provides the following internal delivery channels to communicate with OracleAS Integration InterConnect:
B2B Inbound—this channel enables communication between the host application and OracleAS Integration B2B upon receipt of inbound messages from the remote trading partner.
B2B Outbound—this channel enables communication between the host application and OracleAS Integration B2B to send outbound messages to the remote trading partner.
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:
IP_IN_QUEUE—queue on which OracleAS Integration B2B (target) receives messages and publishes to OracleAS Integration InterConnect.
IP_OUT_QUEUE—queue on which OracleAS Integration B2B (source) publishes messages that are received from OracleAS Integration InterConnect.
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 |
|---|---|---|
|
|
A unique identification for the message.
|
|
|
|
The ID of the message that replies to
|
|
|
|
The trading partner that sends the message.
|
|
|
|
The trading partner that receives the message.
|
|
|
|
The business action that defines the document. Can be null. |
|
|
|
The document type as defined in OracleAS Integration B2B; for example, |
|
|
|
The document revision as defined in OracleAS Integration B2B; for example, |
|
|
|
The type of message, for example, a response or a request message. Required. Supported values are:
|
|
|
|
Message payload. |
|
|
|
Attachment (optional). |
|
OracleAS Integration B2B provides the following options to enqueue and dequeue messages to and from internal delivery channels:
Java commands to enable enqueuing to IP_OUT_QUEUE and dequeuing from IP_IN_QUEUE
PL/SQL scripts to enable enqueuing and dequeuing to and from B2B queues
See Chapter 15, "Utilities for Enqueuing and Dequeuing" for details.
OracleAS Integration B2B provides the following internal delivery channels to communicate with Oracle E-Business Suite:
XML Gateway Inbound—this channel enables communication between the host application and OracleAS Integration B2B upon receipt of inbound messages from the remote trading partner.
XML Gateway Outbound—this channel enables communication between the host application and OracleAS Integration B2B to send outbound messages to the remote trading partner.
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
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 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
OracleAS Integration B2B provides the following internal delivery channels to communicate with Oracle BPEL Process Manager:
B2B Inbound—this channel enables communication between the host application and OracleAS Integration B2B upon receipt of inbound messages from the remote trading partner.
B2B Outbound—this channel enables communication between the host application and OracleAS Integration B2B to send outbound messages to the remote trading partner.
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:
IP_IN_QUEUE—queue on which OracleAS Integration B2B (target) receives messages and publishes to Oracle BPEL Process Manager.
IP_OUT_QUEUE—queue on which OracleAS Integration B2B (source) publishes messages that are received from Oracle BPEL Process Manager.
When you configure OracleAS Integration B2B to communicate with Oracle BPEL Process Manager, you follow the typical process flow in the user interface tool:
Create the business action
Set up the host and remote trading partner
Create the trading partner agreement
Validate and deploy the trading partner agreement
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.
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.
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
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 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.)
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.
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
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 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.
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
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.
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:
One for the initiating purchase order request
One for the responding purchase order acceptance
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.
