Queues

Queues are tables on a database that are managed by Oracle Advanced Queuing. The XML Gateway uses queues specifically at two points in the process, as well as employing a general error queue. The first point is at the transport agent level between the transport agent module and the XML Gateway. The second point is at the transaction level between base Oracle E-Business Suite products or other source process, and the XML Gateway. Details about these queues are provided in the table below.
Queue Name ECX_INBOUND Description Level and Position in Process

Inbound Message Queue: Holds all Transport Agent Level Between the messages that enter the process Transport Agent and the Inbound through the Transport Agent, or are Transaction Queue placed directly on the queue by an API. Transport Agent Level Between the XML Gateway and the Transport Agent

ECX_OUTBOUND Outbound Message Queue: XML Gateway enqueues all outbound messages that it formatted on this queue. ECX_IN_OAG_Q Inbound Transaction Queue: Holds inbound messages that originated from the ECX_INBOUND queue, then enqueued on this queue by Oracle Workflow These messages will be processed by the XML Gateway.

Intermediate Level After the message is received through the Transport Agent (Transport Agent Level above), Oracle Workflow enqueues the message in this queue for the XML Gateway to process.

WF_ERROR

Workflow Error Queue: For errors Transaction Level detected by XML Gateway or WF BES. Notifications are sent to a Trading Partner contact or the System Administrator.

Refer to the Oracle 9i Database title Application Developer's Guide - Advanced Queueing for details, including topics on checking the status and content of the queues.

Outbound Queues

Outbound Message Queues

The outbound Message Queue is positioned between the XML Gateway and the Transport Agent. The XML Gateway creates XML messages, then enqueues them on this queue. Next Step: The Transport Agent dequeues the message and delivers it to the Trading Partner.

Inbound Queues

Inbound Message Queue

Inbound messages are first queued on the Inbound Message Queue. The inbound Message Queue is positioned between the Transport Agent and the Oracle Workflow Business Event System. There are two methods for placing a message on the Inbound Message Queue:
o o

The Transport Agent enqueues the message. An API writes directly to the queue.

Refer to the Oracle 9i Database title Application Developer's Guide Advanced Queueing for details. The full message must be formatted according to the XML Gateway envelope message format described in the Execution Engine section. See XML Gateway Envelope for details. Next Step: Oracle Workflow Business Event System will copy the inbound messages to the proper inbound Transaction Queue. One queue is seeded, but you may define other queues to meet your business needs. See information below.

Inbound Transaction Queue

This is the second queue for an inbound message. After the message is received through the inbound Message Queue, Oracle Workflow Business Event System enqueues the message to this queue for the XML Gateway to process. Next Step: The XML Gateway will process the inbound messages placed in this queue.

Error Queue
When an error is detected by Oracle XML Gateway or Oracle Workflow Business Event System the message is enqueued on to the error queue. A Workflow listener dequeues the error and sends a notification to the Trading Partner contact for data errors or to the System Administrator contact for system or process errors.

XML Gateway Envelope

In addition to the business document such as a purchase order or invoice in the XML Payload, a set of message attributes are transmitted. Collectively, these attributes are called the XML Gateway envelope. This section discusses the XML Gateway envelope and its data in the validation process for inbound messages, or its source of data for its creation for outbound messages. Data entered into the Trading Partner Setup form is referred to as data in the trading partner table. Data entered into the Define Transactions form is referred to as data in the transaction table. Most of the data elements are copied from the Trading Partner tables or the Transaction tables to the XML Gateway envelope. Transaction direction is determined by the XML Gateway. The direction values used by the XML Gateway are the following:
o o

IN for inbound messages OUT for outbound messages

The XML Gateway envelope consists of the data presented in the following table:
Attribute MESSAGE_TYPE Contents Sample Values Data Source (Hard-coded)

Payload XML message format Message format OAG

MESSAGE_STANDARD

Transaction table

standard TRANSACTION_TYPE External Transaction Type for that business document INVOICE Trading Partner table

TRANSACTION_SUBTYPE

External PROCESS Transaction Subtype for that business document Business (Not Used) document number such as invoice number (Not Used) (Not Used)

Trading Partner table

DOCUMENT_NUMBER

N/A

PARTYID

Trading Partner table. This is not used by the XML Gateway. SOURCE TP LOCATION (if not recreated) or TARGET TP LOCATION CODE (if recreated) from Trading Partner table (Not Used)

SOURCE_TP_LOCATION_CODE Source Trading ACME_CHICAGO Partner Location Code

PARTY_TYPE PROTOCOL_TYPE

(Not Used) Transmission Protocol Transmission Address User Name

(Not Used)

SMTP, HTTP, HTTP-WM Trading Partner table me@co.com, Trading Partner http://www.co.com:5555 table User1 Trading Partner table if

PROTOCOL_ADDRESS

USERNAME

Connection is "DIRECT"; Hub Definition if "HUB" PASSWORD password ****** Trading Partner table if Connection is "DIRECT"; Hub Definition if "HUB" (determined by application) (determined by application) TARGET TP LOCATION CODE from Trading Partner table (determined by application) (determined by application)

ATTRIBUTE1

(determined by N/A application) (determined by N/A application) Rerouting Location (used only if the message is rerouted) (determined by N/A application) (determined by N/A application) XML business document (XML Message)

ATTRIBUTE2

ATTRIBUTE3

ATTRIBUTE4

ATTRIBUTE5

PAYLOAD

MESSAGE_TYPE
Payload message format. This defaults to "XML".

MESSAGE_STANDARD
(Defaults to OAG.) Message format standard as displayed in the Define Transactions form and entered in the Define XML Standards form.

TRANSACTION_TYPE
External Transaction Type for the business document from the Trading Partner table.

TRANSACTION_SUBTYPE
External Transaction Subtype for the business document from the Trading Partner table.

DOCUMENT_NUMBER
The document identifier used to identify the transaction, such as a purchase order or invoice number. This field is not used by the XML Gateway, but it may be passed on inbound messages.

SOURCE_TP_LOCATION_CODE
Source Trading Partner Location Code if no data is found in the Destination Trading Partner Location Code in the Trading Partner table.

PROTOCOL_TYPE
Transmission Protocol as defined in the Trading Partner table.

PROTOCOL_ADDRESS
Transmission address as defined in the Trading Partner table.

USERNAME
USERNAME as defined in the Trading Partner table.

PASSWORD
The password associated with the USERNAME defined in the Trading Partner table.

ATTRIBUTE3
For outbound messages, this field has the value from the Destination Trading Partner Location Code in the Trading Partner table. For inbound messages, the presence of this value generates another XML message that is sent to the trading partner identified in the Destination Trading Partner Location Code in the Trading Partner table. This value must be recognized by the hub to forward the XML message to the final recipient of the XML Message. Refer to XML Gateway Setup for details.

PAYLOAD

The XML message.

Parameters defined by the Application

The following parameters may be defined by the base application:
o o o o

ATTRIBUTE1 ATTRIBUTE2 ATTRIBUTE4 ATTRIBUTE5

Parameters Not Used

The following parameters are not used:
o o

PARTYID PARTYTYPE

Setup Overview

Implementation Checklist
There are ten setup steps for the XML Gateway as shown in the following table:
Step Completed Task 1 2 3 4 5 6 7 Define System Profile Options Assign XML Gateway Responsibility Define the utl_file_dir parameters (performed by a DBA) Define Hubs Define XML Standards Define Transactions Define Lookup Values

8 9 10

Define Trading Partners Set up Trading Partner Code Conversion Define Standard Code Conversion

Note: Additional setup steps are required for Web services. See the Web Services chapter for details.

XML Gateway Forms

There are seven forms in the XML Gateway that you will use to complete the setup steps:
o o o o o o o

System Profile Options Hub Definitions Define XML Standards Define Transactions Oracle XML Gateway Lookups Define Trading Partner Setup Define Code Conversion

Define System Profile Options

The XML Gateway uses profile options to define the following for your system:
o o o o o o

The directory path for XML messages and log files The directory path for XSLT style sheets The XML Gateway System Administrator's e-mail address The sender's information system The time zone for the database server The maximum size an outbound document may reach before validating whether parsing should continue

The Trading Partner user security feature for inbound transactions

To define these profile options, you must sign on to Oracle Applications as the System Administrator responsibility. Navigate to the System Profile Values form using the path (N) Profile > System. For additional information on setting profile options, see the Oracle Applications System Administrator's Guide. The following table lists the XML Gateway system profile options:
Profile Option ECX: Log File Path Description Required Default Value None

Log File Path where the XML messages and runtime YES log are stored YES

ECX: XSLT File Path XSLT Path where XSLT style sheets are stored ECX: System Administrator Email Address ECX: OAG_LOGICALID ECX: Server Time Zone ECX: Maximum XML Size

None None

XML Gateway System Administrator e-mail address YES

Identifier for Sender's Information System

NO

None

The time zone in which the database server is running. See Important below.

YES

Null

Specifies the maximum size of an outbound XML NO document (in characters) beyond which parsing is performed based on the value of ECX: XML Validate Flag. If the size is not set, the document will be parsed by default. See Note below. Specifies whether an outbound document should NO continue to be parsed by the engine after the ECX: Maximum XML Size has been met. See Note below. NO

2 MB

ECX: XML Validate Flag

Enable User Security Controls whether an inbound transaction can be enabled based on the value set in the profile option and the association between a user and Trading Partner.

NO

Attention: The valid values for ECX: Server Time Zone are listed in Appendix E. If this profile option is not set, the time zone ID will default to Greenwich Mean Time (GMT). Note: Setting the ECX: XML Validate Flag value to anything other than "Y" will turn off parser validation for a document once the maximum size has been parsed. Turning off the validation avoids Out of Memory errors for large documents. If validation is turned off, the XSLT Transformation action cannot be performed. For more information on the XSLT Transformation action, see perform_xslt_transformation. For outbound Web services this validation must be turned off. See Web Services Setup. For more information on setting profile options, see the Oracle Applications System Administrator's Guide.

APIs Defined in ECX_STANDARD

perform_xslt_transformation PL/SQL Syntax

procedure perform_xslt_transformation (i_xml_file in out clob, i_xslt_file_name in varchar2, i_xslt_file_ver in number, i_xslt_application_code in varchar2, i_dtd_file_name in varchar2 default null, i_dtd_root_element in varchar2 default null, i_dtd_version in varchar2 default null, i_retcode out pls_integer, i_retmsg out varchar2);

Description
Used to apply a style sheet to an XML message and return the transformed XML messaged for further processing by the calling environment. The DTD file name, version, and root element are required input parameters for this API, therefore the associated DTDs must be loaded into the XML Gateway repository. Refer to Loading and Deleting a DTD for details on loading a DTD. This API is independent of the Message Designer: XSLT Transformation action. This API is not intended for use in a message map. Note: The profile option ECX_XML_VALIDATE_FLAG must be set to"Y"for this action to be performed. For more information on this profile option, see Define System Profile Options.

Arguments (input)
i_xml_file i_xslt_file_name i_xslt_file_ver The XML message to be transformed. The XSLT style sheet file to be used for the transformation. The version of the XSLT style sheet file. The highest version with the same file name and application code is used if no version number is provided.

i_xslt_application_code The name of the subdirectory where the XSLT style sheet is sourcecontrolled (for example: ar/xml/xslt). i_dtd_file_name i_dtd_root_element i_dtd_version The name of the DTD used in the XML message. The root element of the DTD used in the XML message. Version of the DTD used in the XML message.

Arguments (output)
i_xml_file The transformed XML message. i_retcode Return code for the procedure. i_retmsg Return message for the procedure.

Loading and Deleting Message Maps and DTDs Loading/Deleting a Map

Oracle message maps are delivered and installed on the $APPLTOP directory. They are automatically loaded into the XML Gateway repository using the LoadMap program. A map can be deleted using the DeleteMap program. If you modified an Oracle prebuilt message map or created a new message map using the Message Designer, these maps are saved on your local file system. Perform the following steps to load the maps into the XML Gateway repository for use by the XML Gateway Execution Engine:
1. Move <mymap>.xgm file from the local file system to the middle tier. The apps.zip file containing the maps that were installed on the $APPLTOP is installed on the middle tier. 2. Execute java LoadMap<DB username><DB
password><Hostname>:<Port>:<SID><mymap.xgm> to load the message map

into the XML Gateway repository. LoadMap will replace existing maps with the same name.

Example: java LoadMap User1 welcome

ap999sun.us.oracle.com:1521:ORA1151<mymap.xgm>

Note: The LoadMap process will load a map if the map version is compatible with the engine version. The map version is stored in the <ECX_MAJOR_VERSION> and the <ECX_MINOR_VERSION> tags of the map file (.xgm). The engine version is stored in WF_RESOURCES. Maps are compatible with the engine if the major version is the same and the minor version is the same or lower. A map can be deleted using the DeleteMap program as follows:
1. Execute java DeleteMap <DB username><DB
password><Hostname><:<Port>:<SID><mapcode> to delete a message map

from the XML Gateway repository. LoadMap will replace existing maps with the same name, but obsolete maps with a different name must be deleted manually.
<mapcode>

is the map name entered in the Message Designer.

Example: java DeleteMap User1 welcome

ap222sun.us.oracle.com:1521:ORA1151<mapcode>

Loading and Deleting a DTD

Each message map is associated with a set of DTDs: the main and its reference DTDs. Similar to message maps, the DTDs associated with the Oracle prebuilt message maps are delivered and installed on the $APPLTOP. They are automatically loaded into the XML Gateway database using the LoadDTDToClob program. A DTD can be deleted using the DeleteDTDFromClob program. To change a DTD referenced in an existing message map, use the File > Properties menu option of the Message Designer to make the necessary change. The updated message map must be loaded into the XML Gateway repository using LoadMap (refer to Loading/Deleting a Map). In addition, the new DTD used must be loaded into the XML Gateway database as follows:
1. Move <mydtd>.dtd file from the local file system to the middle tier. The apps.zip file containing the DTDs that were installed on the $APPLTOP is on the middle tier. 2. Execute java LoadDTDToClob<DB username><DB
password><Hostname>:<Port>:<SID><mydtd.dtd>

<RootElementName><Location> to load the DTD into the XML Gateway

database. LoadDTDToClob will replace existing DTDs with the same name.
<RootElementName>

is the XML Root Element entered in the Message

Designer. is the subdirectory name entered in the Specify XML File and Root Element window of the wizard.
<Location>

A DTD can be deleted using the DeleteDTDFromClob program as follows: Execute java DeleteDTDFromClob <DB username> <DB password> to delete a DTD from the XML Gateway database. LoadDTDToClob will replace existing DTDs with the same name, but obsolete DTDs with a different name must be manually deleted.
<Hostname>:<Port>:<SID><mydtd.dtd> <RootElementName><Location> <RootElementName> <Location>

is the XML Root Element entered in the Message Designer.

is the subdirectory name entered in the Specify XML File and Root Element window of the wizard. LoadMap and LoadDTDToClob are provided as two separate programs to support various combinations of changes. To ensure that the maps and DTDs are synchronized, always execute LoadMap and LoadDTDToClob as a pair.

Setup Steps
To enable Web service transactions, the following setup is required:

Trading Partner Setup Inbound

No special trading partner setup is required to enable an inbound XML message as a Document-style Web service. For information about setting up a trading partner, see Trading Partner Setup.

Outbound
Enable your trading partner's transactions for Web services in the Trading Partner Setup form by setting the Protocol Type to SOAP and entering the Protocol Address. The Protocol Address is the URL on which the trading partner receives XML documents. For the SOAP protocol it conforms to the format: http://<destination>/webservices/document

To exchange Web services with a trading partner, the following information is extracted from the Trading Partner Setup form and passed as part of the SOAP header:
o o o o o

Username Password Transaction Type Transaction Subtype Message Type

Message Type must be set to "XML".

o

Message Standard

Message Type must be set to "OAG". For more information about setting up a trading partner, see Trading Partner Setup.

Set the ECX: XML Validate Flag

To send outbound Web services, the profile option ECX: XML Validate Flag must be set to "N". For more information about this profile option, see Define System Profile Options.

Enable Agents and Start Agent Listeners

The following agents must be enabled and the seeded agent listener service components must be running:
Agent Name WF_WS_JMS_IN Listener Name Web Services IN Agent

WF_WS_JMS_OUT Web Services OUT Agent

Use the Workflow Administrator: Agents window to enable the agents if necessary (the agents are enabled by default). The same window can be used to disable an agent. Use Oracle Applications Manager to schedule and manage agent listener service components. For more information, refer to the Oracle Applications Manager online help.

The agent listener components are seeded with a manual startup mode and therefore must be manually started.

Provide the WSDL to your Trading Partner (for Inbound Transactions)

For all inbound transactions, the WSDL is published at the following URL:
http://<IPAddress:port>/webservices/document/oracle/apps/fnd/XMLGateway?wsdl

You can also access the WSDL by selecting Generic XML Gateway WSDL from the Workflow Administrator Web Applications responsibility or the Workflow Administrator Web (New) responsibility.

Configure the Secure Socket Layer (SSL)

For inbound Web Services, SSL is handled by the Apache Server and no additional settings are required. Outbound requires additional settings. The steps required depend on what level of SSL you are enabling, Client Authentication or Server Authentication. For all SSL communications, digital certificates will be stored in Oracle Wallet Manager. The following digital certificates are required:
o o o o

Root or Intermediate certifications of all well known Certificate Authorities Client Certificate Certificate of CA authority who signed the client certificate Password for accessing client certificate or the Oracle Wallet manager.

For additional configuration steps required for Web services over SSL,, see "About Oracle Workflow Mini-pack OWF.H," OracleMetaLink note 258312.1. For information on setting up the Oracle Wallet Manager, see "A Guide to Understanding and Implementing SSL with Oracle Applications 11 i," OracleMetaLink note 123718.1.

Trading Partner Setup

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:

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.

o o o o

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:
o

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.

o o

Note: Multi-Org Consideration Trading Partner setup in XML Gateway is organization-dependent. The list of Trading Partners and Trading Partner sites displayed is limited to those trading partners defined to the organization of the logon responsibility. This form defines the parameters for the Trading Partner setup. The setup includes the identification of the 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.

The Trading Partner Setup form includes the following data to define the Trading Partner:

Trading Partner Type (Required)

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.

Trading Partner Name (Required)

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.

Trading Partner Site (Required)

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.

Company Admin Email (Required)

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.

Code Conversion Button

Use the Code Conversion button to access the Trading Partner Code Conversion form See: Code Conversion Trading Partner Code Conversion Form

Trading Partner Details

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 (Required)

Transaction Type is the standard product short code for the base Oracle 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
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.

Standard Code
The Standard Code associated with the Transaction Type selected above is displayed. Standard Codes are set up in the Define XML Standards form.

External Transaction Type

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.

External Transaction Subtype

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.

Direction
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.

Map (Required)
(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.

Connection/Hub (Required for outbound messages only)

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:
o

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 NONE HTTP-WM, HTTPS-WM HTTP, HTTP-OXTA, HTTPS, HTTPS-OXTA, SMTP OTAH-ATCH, OTAHS-ATCH Correlation ID N/A Message System Message disabled

WebMethods Third party system OXTA Oracle Transport Agent without attachments

OXTA

Oracle Transport Agent with attachment using standard OTA envelope Oracle Transport Agent with attachment and no OTA envelope Oracle iProcurement Connector Oracle Integration Server Web Service Agent JMS Provider

HTTP-ATCH, HTTPS-ATCH

OXTA

ITG03 IAS SOAP JMS

ITG03 IAS N/A N/A

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.
o

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.
o

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.
o

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:
o

Protocol Type

Protocol Type defaults from the Hub definition.

o

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.
o

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.
o

Protocol Address

Protocol Address defaults from the Hub definition.

Source Trading Partner Location Code (Required)

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.

Destination Trading Partner Location Code

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
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.

Routing
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.

Required Communications Data

Required Communications for Outbound Messages

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:
o o o o o

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:
o

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:
o

Destination Trading Partner Location Code

See: XML Gateway Envelope.

Required Communications Data for Inbound Messages

Inbound messages require the following:
o

Source Trading Partner Location Code to identify the sender of the message