Navigate to the Define Trading Partner Setup form from the XML Gateway Responsibility by selecting Setup > Define Trading Partners.
The Trading Partner Setup form is used to:
Set up trading partners for multiple operating units.
Enable messages for the trading partner by identifying the internal and external transaction type and transaction subtype codes, and the XML standard associated with the message.
Access the Trading Partner User Setup form.
Access the Trading Partner Code Conversion form.
Select a message map for the trading partner.
Identify the communications protocol and address for a message. Optionally, the user can be selected from a hub.
For example, if JMS messages are used in the transactions, then you must select JMS as the Protocol Type and appropriate JMS queues in the Protocol Address fields.
This is the component that will enable a message to be processed through the XML Gateway engine. In the XML Gateway, the term "Trading Partner" refers to an entity such as a customer, supplier, bank branch, or internal locations at a particular address with which you exchange messages. Since a given entity may have several locations, you must define one Trading Partner for each customer address, supplier site, or bank branch as required for processing transactions by the Oracle XML Gateway.
During message processing, Trading Partner data is used to:
Link a particular address location in Oracle E-Business Suite to the Trading Partner definition in the Gateway.
Provide a means of telling the Execution Engine which Trading Partner message map to use.
Enable specific transactions for Trading Partners.
Determine how to deliver the message.
This form defines the parameters for the Trading Partner setup. The setup includes the identification of the operating unit, trading partner site, the messages enabled for that site, and the delivery mechanism.
The Trading Partner Setup form requires an entry for each Transaction Type and Transaction Subtype associated with this trading partner.
Trading Partners for Multiple Organizations
To support multiple organization functionality, Oracle XML Gateway allows you to set up Trading Partners for all operating units associated with your responsibility.
All Trading Partner related data, including Trading Partner Types, Trading Partner Names, and Trading Partner Sites, is associated with the specified operating unit. You can select an operating unit that is linked to your responsibility while defining a Trading Partner using the Trading Partner Setup form.
Multiple Organization Access Control
To secure data access, Oracle XML Gateway uses security profiles that are linked to your responsibility to control access to one or more operating units. The security profile concept allows system administrators to predefine the scope of access privileges as a security profile and then associate the security profile with responsibility for a user.
Multiple operating units are associated with a security profile and the security profile is in turn associated with a responsibility. Therefore, through the access control of security profiles, users can access data in multiple operating units without changing responsibility.
Security profiles are defined based on organization hierarchies. For example, a sales company consists of USA and UK operating units; each operating unit also contains sublevel operating units for various regions. These top or sub level operating units can be defined as security profiles based on the organization hierarchy. Sales managers, supervisors, and representatives are responsible for their designated sales units or regions. System administrators can then associate those predefined security profiles with appropriate sales people through their responsibilities. Therefore, sales supervisors can easily access sales data in different sales regions without changing their responsibilities.
See Trading Partner chapter, Oracle e-Commerce Gateway Implementation Guide for details.
The Trading Partner Setup Header includes the following fields:
The Operating Unit field displays the default operating unit that is restricted by the security profile linked to your logon responsibility. You can change the default by selecting other operating unit from the list of values if you are associated with more than one operating units.
Trading Partner Type is tied to the operating unit; that is, once the operating unit is selected, only the associated Trading Partner Type, such as Supplier, Customer, Bank, or internal location, will be displayed in the list of values.
Trading Partner Type defines the type of trading partner, such as Supplier, Customer, Bank or internal location. Once the Trading Partner Type is selected from the list of values, the Trading Partner Names and Trading Partner Sites associated with the Trading Partner Type are displayed in the Trading Partner Name and Trading Partner Site lists of values below.
Given the selection in the Trading Partner Type, the appropriate Trading Partner Names are displayed in the Trading Partner Name list of values. For example, if Partner Type is Customer, then customer names will be displayed. These Trading Partners are limited to those trading partners associated with the organization of your logon responsibility. Select the appropriate Trading Partner Name.
Given the selection in the Trading Partner Name, the appropriate Trading Partner Sites are displayed in the list of values. Select the appropriate Trading Partner Site.
This is the e-mail address of the administration contact to receive e-mails regarding warnings and errors. These notifications may be initiated by Oracle Workflow or by an action defined in the message map using the Message Designer. Users should check the error log.
Use the Code Conversion button to access the Trading Partner Code Conversion form. See:
The combination of Party Type (Trading Partner Type), Trading Partner Name, Trading Partner Site, Transaction Type, and Transaction Subtype uniquely identify an outbound transaction.
The combination of External Transaction Type, External Transaction Subtype, Standard Code, and Source Trading Partner Location Code uniquely identify an inbound transaction.
The Trading Partner Setup form includes the following detail for each message:
Transaction Type is the standard product short code for the base Oracle E-Business Suite application. These values are defined in the Define Transactions form. The list of values will display the available combinations of Transaction Type, Transaction Subtype, Standard Code, External Transaction Type, External Transaction Subtype, and Direction. Select the desired combination.
These values are only used internally to the XML Gateway. Refer to the Define Transactions Form for details.
Transaction subtype is a code for a particular transaction within the application specified by the Transaction Type. The last position represents the direction of the transaction: I for inbound, O for outbound.
The combination of Party Type (Trading Partner Type), Transaction Type, and Transaction Subtype should identify an Oracle transaction with which to associate this message. These values are defined in the Define Transactions form.
These values are only used internally to the XML Gateway. Refer to the Define Transactions Form for details.
The Standard Code associated with the Transaction Type selected above is displayed.
Standard Codes are set up in the Define XML Standards form.
The External Transaction Type associated with the Transaction Type selected above is displayed.
The External Transaction Type is the primary external identifier for the XML message. These values are defined in the Define Transactions form and they are found in the XML Gateway envelope.
The combination of the External Transaction Type and the External Transaction Subtype should identify this external message to the Oracle E-Business Suite.
The External Transaction Subtype associated with the Transaction Type selected above is displayed.
The External Transaction Subtype is the secondary identifier for the XML message. These values are defined in the Define Transactions form and they are found in the XML Gateway envelope.
The combination of the External Transaction Type and the External Transaction Subtype should identify this external message to the Oracle E-Business Suite.
The Direction associated with the Transaction Type selected above is displayed.
This code identifies the direction of the transaction. The value IN identifies an inbound message, and the value OUT identifies an outbound message.
(Message) Map is the name of the map created using Message Designer.
Select the appropriate map from the list of values.
The naming convention for message maps consists of the four components: Transaction Type, Transaction Subtype, Standard and Release, and Direction. For example: "PO_POO_OAG70_OUT" is the outbound Oracle Purchasing Purchase Order in the OAG standard, release 7.0. The direction code OUT makes the message direction more apparent in any list.
Refer to Message Designer for more details on the naming convention.
If the desired map does not appear in the list of values, then the map has not been loaded into the XML Gateway database. Refer to the How to Load Message Maps and DTDs.
A DIRECT connect and a hub are the methods by which the message can be communicated. The XML message can be sent directly to a trading partner, or sent to a trading partner via a hub. The hub will then communicate the message to the trading partner.
Select DIRECT to conduct business directly with a trading partner, or select a hub from the list of values. If a hub is selected, then select a trading partner from that hub.
See the Hub Definition form to define hubs.
Requirements for the entries for Protocol Type, Username, Password, and Protocol Address depend on whether you select DIRECT or a hub.
If you select DIRECT, complete these fields as follows:
Protocol Type (Required)
Each message enabled for a Trading Partner includes a protocol type (also known as communication method). The associated correlation ID is determined internally and is associated with the message enqueued onto the agent (queue). Listeners defined for the agent will dequeue messages based on the correlation ID defined for it. For example, Oracle Transport Agent will only dequeue messages with a correlation ID of OXTA.
The following table shows the Protocol Type, Correlation ID, and Message System.
| Protocol Type | Correlation ID | Message System |
|---|---|---|
| NONE | N/A | Message disabled |
| HTTP-WM, HTTPS-WM | WebMethods | Third party system |
| HTTP, HTTP-OXTA, HTTPS, HTTPS-OXTA, SMTP | OXTA | Oracle Transport Agent without attachments |
| OTAH-ATCH, OTAHS-ATCH | OXTA | Oracle Transport Agent with attachment using standard OTA envelope |
| HTTP-ATCH, HTTPS-ATCH | OXTA | Oracle Transport Agent with attachment and no OTA envelope |
| ITG03 | ITG03 | Oracle iProcurement Connector |
| IAS | IAS | Oracle Integration Server |
| SOAP | N/A | Web Service Agent |
| JMS | N/A | JMS Provider |
Select the protocol type from the list of values. This data is seeded by the XML Gateway.
Protocol type NONE will disable the outbound message for this trading partner.
Username
Enter the destination Username used to log in to the receiving server for the server that is identified in the server address.
For protocol types HTTP and HTTPS, Username and Password are required fields.
Password
Enter the Password for the destination Username. The password is not echoed when it is entered. You will be prompted on the same field to confirm the password.
For protocol types HTTP and HTTPS, Username and Password are required fields.
Protocol Address
Protocol Address is the complete URL (including service/servlet) where the Transport Agent will attempt to post the XML Document.
For protocol type SMTP, the Protocol Address is an e-mail address, and is required.
For protocol type JMS, the Protocol Address is a JMS queue.
If you select a Hub, complete these fields as follows:
Protocol Type
Protocol Type defaults from the Hub definition.
Username
Select the Username from the list of values supplied by the Hub definition. If the Protocol Type is SMTP, the Username is not required. For all other Protocol Types, this field is required.
Password
This field defaults to the password that is associated with the Username selected. The username and password combination is supplied from the Hub definition. If the Protocol Type is SMTP, this field is not required.
Protocol Address
Protocol Address defaults from the Hub definition.
Source Trading Partner Location Code is the code found in the XML Gateway envelope to identify the source of the message. This is the code for the source trading partner of the message.
If you are sending and receiving messages from a trading partner, you will have a mixture of your location codes and your trading partner's location codes depending on the direction of the message. For example, if you are sending messages out, the Source Trading Partner Location Code is your location code because you are the source of the XML message. If you are receiving messages, the Source Trading Partner Location Code is your trading partner's location code because they are the source of the XML message.
This code is examined for inbound messages for Trading Partner validation. When placed on an outbound message, the recipient will validate it as a valid source or sending location.
This field is placed in the PARTY SITE ID in the XML Gateway envelope.
See: XML Gateway Envelope.
There are two types of routing in the XML Gateway: Static Routing and Dynamic Routing. Dynamic Routing allows the message to be rerouted by the first recipient of the message to the final destination recipient. Refer to the Routing field below for Static Routing.
Destination Trading Partner Location Code is the code for the final recipient of the XML message. This code is not needed by the XML Gateway creating this message, but needed by the hub or the first trading partner receiving the message to identify their final trading partner to receive the message. It is the hub's or the first trading partner's code for that final destination trading partner.
For outbound messages, the final intended recipient location code identified by the Destination Trading Partner Location Code will be placed in ATTRIBUTE3 in the XML Gateway envelope.
For inbound messages, this code is found in ATTRIBUTE3 in the XML Gateway envelope. Refer to Static and Dynamic Routing for an illustration that explains how ATTRIBUTE3 is populated.
Document Confirmation is the indicator for the confirmation level that this Trading Partner would like to send or receive a confirmation.
0 (Default value) means Never send a confirmation
1 means Send a confirmation only if there are errors
2 means Always send a confirmation
It defines the condition under which a confirmation XML message is generated or received. Outbound messages receive inbound confirmations. Inbound messages generate outbound confirmations.
Use the Routing field to identify another trading partner to whom messages will be routed. You select a trading partner for outbound transactions from the list of values. The inbound message is forwarded as an outbound message to the trading partner identified in the Routing field.
The XML Gateway provides both Static Routing and Dynamic Routing. Routing is the address to route the outbound message to when using the Static Routing method. Refer to the Destination Trading Partner Location Code field above for Dynamic Routing.
See: Static and Dynamic Routing for more information.
Different data is required depending on whether DIRECT or a trading partner is selected from a hub.
If DIRECT is selected, the following data fields are entered by the user depending on the protocol type for outbound messages:
Protocol Type (required)
Protocol Address (required)
User Name (depends on Protocol Type)
Password (depends on Protocol Type)
Source Trading Partner Location Code to identify the recipient of the message (required)
If the message is sent via a hub, select the hub, then select a Username from the presented list. The following data fields are retrieved for outbound messages:
The following data fields are copied from the Username in the hub definition:
Protocol Type
Protocol Address
Hub Entity Code (acts like the Source Trading Partner Location Code for DIRECT communication)
Password (optional and depends on Protocol Type)
If the message will be rerouted to another trading partner by the hub using Dynamic routing, then the following data is needed. It will be placed in ATTRIBUTE3 in the XML Gateway envelope:
Destination Trading Partner Location Code
See: XML Gateway Envelope.
Inbound messages require the following:
Source Trading Partner Location Code to identify the sender of the message