Navigate to the Define Transactions form from the XML Gateway Responsibility by selecting Setup > Define Transactions.
Use the Define Transactions form to define the transactions that will be used by the XML Gateway Execution Engine. You will then associate these transactions with a trading partner in the Trading Partner Setup form.
The Define Transactions form provides the following:
A cross-reference between the external transaction identifiers and the internal Oracle transaction identifiers.
Identification of the queue from which to retrieve inbound messages
This form provides a cross-reference between internal Oracle transaction identifiers, represented by the Transaction Type and Transaction Subtype, and External Transaction Types and External Transaction Subtypes.
Note: The data element pair of External Transaction Type and External Transaction Subtype, and the data element pair of Transaction Type and Transaction Subtype are not a one-to-one cross-reference by similar data element names. It is the combination of each pair that is significant to identify the external representation of the XML message, or the internal representation to identify the transaction to the Oracle E-Business Suite.
For example: The following is an inbound message with a Party Type of "CUSTOMER": OAG PROCESS_INVOICE_003. The message has the External Transaction Type "PROCESS" and External Transaction Subtype "INVOICE." The inbound direction is determined by the XML Gateway.
The External Transaction Type "PROCESS" and External Transaction Subtype "INVOICE" will be matched to Transaction Type and Transaction Subtype equal to AP and INI as they are defined in the Define Transactions form. For this trading partner, the message map defines on which tables in Oracle Payables to place the inbound data.
Another example is an outbound message with a Party Type of "SUPPLIER":
Invoice transaction from Oracle Receivables has the Transaction Type "AR" and the Transaction Subtype "INO." The outbound direction is determined by the XML Gateway.
This Transaction Type and Transaction Subtype will be matched to the External Transaction Type "INVOICE" and External Transaction Subtype "PROCESS" as defined in the Define Transactions form for the specified trading partner. For this trading partner, the message map identifies what data to extract from Oracle Receivables.
The Party Type, Transaction Type, and Transaction Subtype are key codes used by Oracle E-Business Suite to integrate with the Workflow Business Event System (BES) to trigger message creation or message consumption.
Different queues can be defined for various transactions from the application, or for XML messages to be transmitted. The queue names are assigned to the transactions via this form.
See Message Queues.
Party Type defines the type of trading partner, such as Supplier, Customer, Bank, or internal locations (such as warehouses). Select a value from the list of values.
Transaction Type is the product short name for the base Oracle E-Business Suite application associated with the transaction, such as "AR" for Oracle Receivables. Refer to Transaction Type and Transaction Subtype Naming Conventions.
If you are using OAG standards, refer to Setting VERB and NOUN in OAG Standards.
Transaction Subtype is a code for a particular transaction within the application specified by the Transaction Type. The last position of the code represents the direction of the transaction: "I" for inbound, "O" for outbound.
See Transaction Type and Transaction Subtype Naming Conventions.
The combination of the Transaction Type and the Transaction Subtype identifies an Oracle transaction with which to associate this message. This data will appear on the Trading Partner Setup form.
If you are using OAG standards, refer to Setting VERB and NOUN in OAG Standards.
Enter a description for the transaction.
You can optionally enter a transaction owner's user name. A transaction owner is considered as an expert for a specified transaction type defined in this form.
When an error occurs during a transaction, in addition to the XML Gateway system administrator for system or process errors and Trading Partner contact for data errors, Oracle Workflow can send a notification to a transaction owner if it is specified here based on the transaction type of an erred inbound transaction. For example, if an inbound transaction error occurs in Purchasing transaction type, then the transaction owner of the Purchasing if defined here will receive a notification in addition to the XML Gateway system administrator or Trading Partner contact depending on the error type.
When notifications are sent to the XML Gateway system administrator and the transaction owner if specified, both of them can take actions in response to the error notifications if necessary. See: XML Gateway Error Processing Item Type.
The XML standard to be used for this transaction. The Standard Codes are set up in the Define XML Standards form. Choose the code from the list of values.
Direction indicates if the message is inbound or outbound. Select "IN" for inbound messages, or "OUT" for outbound messages from the list of values.
External Transaction Type is the primary external identifier for the XML message.
The combination of the External Transaction Type and the External Transaction Subtype should cross-reference this message to the Oracle internal transaction identified by the Transaction Type and the Transaction Subtype.
External Transaction Subtype is the secondary external identifier for the XML message.
The combination of the External Transaction Type and the External Transaction Subtype should cross-reference this message to the Oracle internal transaction identified by the Transaction Type and the Transaction Subtype.
A queue is a table in a database where transactions are staged for processing. Default queues are defined during installation. Select a queue from the list of values.
The field is disabled for outbound messages.
See Message Queues.
Note: Only queues with a prefix of ECX will display in the list of values.
Naming conventions for Transaction Type and Transaction Subtype are necessary to facilitate the reading of audit trails and for troubleshooting across applications.
The Transaction Type and Transaction Subtype codes should not focus on naming conventions based on the standard XML message that is implemented. A given transaction from an application may be mapped to several XML standards based on the trading partner agreements, likewise for inbound messages.
The following naming conventions are recommended:
The Transaction Type is the product short name for the base Oracle E-Business Suite application. Examples of Oracle E-Business Suite application product short names are shown in the following table:
| Transaction Type | Application |
|---|---|
| AP | Payables |
| AR | Receivables |
| OM | Order Management |
| PO | Purchasing |
| SS | Supplier Scheduling |
| RLM | Release Management |
| CUSTOM | (for user-defined messages) |
The Transaction Subtype is a code for a particular transaction within the application specified by the Transaction Type. The last position of the subtype code represents the direction of the transaction: "I" for inbound, "O" for outbound.
The naming convention is XXXXI or XXXXO where XXXX is significant to the application and its function, such as invoicing to Receivables and Payables.
For custom transactions, add a prefix to distinguish custom transactions from the Oracle supplied transactions.
The table below lists common combinations of Transaction Type and Transaction Subtype:
| Transaction Type (Application) | Transaction Subtype (Transaction) | Transaction Type's Processing Application | Transaction Type's Processing Application (Transaction Code plus Direction) |
|---|---|---|---|
| PO | POCO | Purchasing | Purchase Order Change, Outbound |
| PO | POO | Purchasing | Purchase Order, Outbound |
| PO | POAI | Purchasing | Purchase Order Acknowledgment, Inbound |
| OM | POI | Order Management | Purchase Order, Inbound |
| OM | POCI | Order Management | Purchase Order Change, Inbound |
| OM | POAO | Order Management | Purchase Order Acknowledgment, Outbound |
| OM | POCAO | Order Management | Purchase Order Change Acknowledgment, Outbound |
| AR | INO | Receivables | Invoices, Outbound |
| AP | INI | Payables | Invoices, Inbound |
The actual transaction detail is therefore recognized by its unique combination of the Transaction Type and Transaction Subtype. The Transaction Subtype does not have to be unique across applications, but only within the application specified by the Transaction Type.
Consequently, both the Purchasing and the Order Management application can use the same Transaction Subtype (for example, POI) because they may both import some type of purchase order. For example, Order Management will load orders from its customers; Purchasing may load from another purchasing application.
If different database views are used to extract different types of transaction data, such as a blanket order versus a standard order, or different XML messages are needed for transactions such as a blanket order versus a standard order, then you can create different message maps using the Message Designer. You may also need to define different Transaction Subtypes to distinguish between such transactions in the Transaction setup.
When appropriate, a suffix can be attached to the base Transaction Subtype following the XXXXI or XXXXO naming convention to further distinguish a transaction in the XML Gateway. For queries in a form, it is recommended to keep the same base Transaction Subtype XXXXI or XXXXO, so the Transaction Subtypes will follow each other in queries.
The suffix naming convention is therefore XXXXI-yyyy and XXXXO-yyyy where yyyy is the suffix.
The following table illustrates the Transaction Subtype naming convention using a suffix:
| Transaction Type (Application) | Transaction Subtype (Transaction) | Transaction Type's Processing Application | Transaction Type's Processing Application (Transaction Code plus Direction) |
|---|---|---|---|
| PO | POO-BLK | Purchasing | Blanket Purchase Order, Outbound |
| PO | POO-REL | Purchasing | Purchase Order Release, Outbound |
| PO | POO-STD | Purchasing | Standard Purchase Order, Outbound |
For example in a Purchasing application, all types of outbound purchase orders can be initiated under the general subtype POO with qualifiers for the various types of purchase orders such as blanket, standard, and release. Their subtype codes can be recognized as POO-BLK, POO-STD, and POO-REL respectively by the process. Avoid using long suffixes such as -BLANKET, -STANDARD, and -RELEASE to keep the naming convention simple. This sample is for illustration only.
The following topic discusses sources of data for the OAG CNTROLAREA.
The VERB and NOUN are key values required in the OAG CNTROLAREA data type. XML Gateway provides a database view that provides key data from the transaction table, while the attribute values are default values from the DTD used to create the outbound message map.
The purpose of the database view is to populate the VERB and NOUN elements illustrated below.
The Verb and Noun in OAG's CNTROLAREA
<NOUN value = "INVOICE"> INVOICE </NOUN>
<VERB value = "PROCESS"> PROCESS </VERB>
When the External Transaction Type and External Transaction Subtype are entered into the transaction table through the Define Transactions form, they can be mapped to the NOUN and VERB value fields respectively by using the database view ECX_OAG_CONTROLAREA_TP_V (formerly ECX_OAG_CONTROLAREA_V). See Transaction Map - Element Mapping.
Note: The ECX_OAG_CONTROLAREA_TP_V view is an upgraded version of the ECX_OAG_CONTROLAREA_V view. Oracle XML Gateway supports both versions of the database view. For a detailed description of the differences, see the Note, in the Message Designer chapter.
Attention: Within the OAG CNTROLAREA, the sequence of fields is VERB then NOUN in the message. In the Define Transactions form, the sequence of fields is NOUN in the External Transaction Type, then VERB in the External Transaction Subtype. Be careful not to reverse the order of the data.