Map Analysis Guidelines

Map Analysis Overview

A map analysis is required to determine how to map data between the Oracle E-Business Suite data model and the required message. For outbound messages, this requires a comparison between the Oracle E-Business Suite database views and the Document Type Definition (DTD) or a production XML message.

The result of the map analysis is used as input to the XML Gateway Message Designer. It is imperative that a complete map analysis is done before attempting to create the message map. The map analysis must resolve all data gaps, identify derivation rules, identify default values, identity data transformation and process controls via Actions, and ensure that all required target fields are mapped.

Map Analysis Guidelines for Outbound Messages

The steps to performing a map analysis for an outbound message are as follows:

Map Analysis Guidelines for Outbound Messages Checklist

Use the following table as a checklist to track your progress when analyzing an outbound message. Details of each step are provided in the following sections. Use the "Completed" column to check off the step as it is completed.

Step Completed Description
1   CREATE WORKSHEET: Create a worksheet to identify all data.
2   SET UP SOURCE: Create database views or get database views/table definitions (source) for the required message from the database schema.
3   SET UP TARGET: Populate the target column of the worksheet with the DTD or production XML message in the expanded format.
3A   Identify the required DTD (target) elements.
3B   For DTD elements with "|" as the occurrence indicator, select one element from the list. Make a note of the elements not selected because these must be removed from the message map to prevent a parser violation.
4   RELATE SOURCE ELEMENT TO TARGET ELEMENT: For each DTD (target) element, identify the database view (source) column to map from.
4A   Identify where code conversion is needed.
4B   Identify Derivation Rules
4C   Identify Defaulting Rules
4D   Identify DTD Attribute Settings
5   CONVERT FROM ORACLE FORMAT TO OAG FORMAT: For each OAG DTD (target) DATETIME, AMOUNT, OPERAMT, or QUANTITY element, identify the database view/table (source) column to map from. Other XML standards may have similar elements.
5A   Identify and map each DATETIME element.
5B   Identify and map each AMOUNT element.
5C   Identify and map each OPERAMT element.
5D   Identify and map each QUANTITY element.
6   ADD SIBLING FOR DUPLICATE NODES/ELEMENTS: Add Sibling nodes and elements if needed.
7   ADD CHILD TO EXTEND DTD DEFINITION FOR FLEXFIELDS: If there is a database view or table column that you wish to map from but no DTD element is defined to support it, you can use the OAG's USERAREA. Map data to the USERAREA (or corresponding area if using other XML standards).
8   RESOLVE DATA GAPS: Any DTD (target) elements that have not been mapped are data gaps.
9   IDENTIFY APPLICATION BUSINESS EVENT TRIGGER: Identify the application business events to trigger message creation.
10   IDENTIFY REQUIRED ACTIONS: All outbound messages require the following Actions to define the selection criteria. Make a notation on the worksheet to include them. Use the Append Where Clause action to bind to transaction type, transaction subtype, party ID, and party site ID to ECX_OAG_CONTROLAREA_TP_V (formerly ECX_OAG_CONTROLAREA_V see Note). If using ECX_OAG_CONTROLAREA_V, use the Append Where Clause action to bind to transaction type and transaction subtype. Use the Append Where Clause action to bind document ID to header view to select the document
11   IDENTIFY SOURCE AND TARGET DOCUMENT LEVELS

Compare Database Views (Source) to DTD (Target)

Step 1 Create a Worksheet

Create a worksheet with the following columns: Target, Required (Y/N), Source, Code Category, Derivation Rule, Default Value, and Action, as shown in the following table:

Target Required
(Y/N)		 Source Code Category Derivation Rule Default Value Action
             
             

Step 2 Set Up Source

Create database views or get database view and table definitions (source) for the required message from the database schema. Include ECX_OAG_CONTROLAREA_V or ECX_OAG_CONTROLAREA_TP_V (see Note) view to map to the CNTROLAREA segment of the DTD.

Step 3 Set Up Target

Populate the target column of the worksheet with the DTD or production XML message in the expanded format.

Note: You may use third party software to expand the DTD or use a production XML message.

Step 3A Identify Required Target Elements

Identify the required DTD (target) elements. An element is required if there is no special symbol next to the element name.

The XML occurrence indicators are:

"+" implies one or more

"*" implies zero or more

"?" implies zero or 1

"|" implies either one or the other

"," implies all listed child elements must be used in the order shown

Step 3B For Elements with "|" as the occurrence indicator

For DTD elements with "|" as the occurrence indicator, select one element from the list. Make a note of the elements not selected in order to remove them from the message map. They must be removed from the message map to prevent a parser violation.

Step 4 Relate Source Element to Target Element

For each DTD (target) element, identify the database view (source) column to map from.

Note: Use the Open Application Group's Integration Specification (available at http://www.openapplications.org) Appendix C, Field Identifier Descriptions and Appendix D, Segment Descriptions, to get detailed descriptions of each element identified on the DTD.

Step 4A

If the DTD (target) element can be sourced from a database view (source) column, determine if the database view column value requires code conversion.

Step 4B Identify Derivation Rule

If the DTD (target) element cannot be sourced from a database view (source) column, determine if the value can be derived. If yes, identify the derivation rule. The derivation rule can be, for example, a combination of several view columns, a procedure call, or a function call. Make a notation that an XML Gateway Action may be required (for example, to get a value from another column, or to combine the values of several columns).

Refer to Appendix C. for a list of XML Gateway supported Actions.

Determine if the derived value requires code conversion. If code conversion is required, identify the code category from the list in Appendix B.

Important: Identify the from or to value to determine if the required values are available in the database. If the values are not available, they must be added.

Step 4C Identify Defaulting Rule

If the DTD (target) element cannot be sourced from a database view (source) column or derived, determine if the value can be defaulted. If yes, identify the default value. The default value can be a literal or based on a value from another database view column. Make a notation that an XML Gateway Action may be required.

The default value can be set directly in the map using the Message Designer or as an XML Gateway Action if the default value is based on a condition.

Refer to Transaction Map - Actions for a list of XML Gateway supported Actions.

Determine if the default value requires code conversion. If code conversion is required, identify the code category from the list in Appendix B.

Important: Identify the from or to value to determine if the required values are available in the database. If the values are not available, they must to be added.

Step 4D Identify DTD Attribute Setting

For each DTD (target) element containing attributes (lower case tags), determine the appropriate setting by checking the usage of the database view or table column and then identifying a valid setting for the attribute by reviewing the options in OAG's Appendix D that lists Segment Descriptions for the DTD element. The appropriate attribute setting is set directly in the target definition as a default value using the Message Designer.

For example, if a view column is used for creation date, the DATETIME "qualifier" attribute value of "CREATION" will be set as the default value using the Message Designer.

Step 5 Convert from Oracle Format to OAG Format

For each DTD (target) DATETIME, AMOUNT, OPERAMT, or QUANTITY element, identify the database view or table (source) column to map from.

Oracle E-Business Suite represents date, amount, operating amount, and quantity in a single database column. OAG represents these as a collection of data. Oracle XML Gateway provides an Action to convert the Oracle representation to the OAG representation. Make a notation that this column requires an Action for "Convert to OAG" that will be defined using the Message Designer.

Step 5A

Step 5B

Step 5C

Step 5D

For the QUANTITY element, identify database view or table (source) column for the unit of measure code if available. The XML Gateway "Convert to OAG" Action can be defined to use the view or table column value or default to the OAG recommended value if the view or table column is not available.

Follow Step 4D to set the "qualifier" attribute.

The OAG fields for NUMOFDEC and SIGN are set by the "Convert to OAG" Action based on the quantity value.

Note: OAG QUANTITY is made up of the following attributes and elements: qualifier, VALUE, NUMOFDEC, SIGN, UOM.

Step 6 Add Sibling for Duplicate Nodes/Elements

A DTD defines a single occurrence of a node or element. If you have multiple occurrences from the database view or table (source) to map from, make a notation on your worksheet showing the duplicate node or element and then map the element and attributes of the duplicate node or element. Make a notation to ADD SIBLING using the Message Designer.

An example is the DTD element for PARTNER used to map SHIP-TO, BILL-TO, and REMIT-TO from the Oracle E-Business Suite. You will need to add two PARTNER sibling nodes (same hierarchy level) to map BILL-TO and REMIT-TO.

Step 7 Add Child to Extend DTD Definition for Flexfields

If there is a database view or table column you wish to map from but no DTD element is defined to support it, you can use the USERAREA. You can add a USERAREA as a sibling (same hierarchy level) of another USERAREA or extend an existing USERAREA by adding a child (next level of hierarchy) element and then mapping the element. Make a notation to ADD CHILD using the Message Designer.

This approach is necessary to support all the flexfields included in the database views and tables. Since we do not know which flexfields are implemented at a user's site, all flexfields must be mapped.

Refer to How to Extend DTDs for details.

Note: The only updates allowed for a DTD are to the USERAREA. Any other changes will invalidate the DTD.

Step 8 Resolve Data Gaps

At this point, you have identified database view and table (source) columns for as many DTD (target) elements as possible. Any required DTD (target) element that has not been mapped represents a data gap.

Consider resolving the data gap using an application flexfield that is included in the database view or table. If this is a valid option, you must implement the designated flexfield by defining and populating it in the Oracle E-Business Suite. Consider carefully which flexfield to implement as you do not want to overwrite a flexfield implemented by the user.

Consider resolving the data gap using an application column not included in the database view. If this is a valid option, you must modify the database view to include the application column as opposed to referencing the table and column directly. Load the modified database view into the database schema. Remember to map the field.

If neither of the above considerations resolves the data gap, then you must add functionality to your application module, create new database views, load the new views into the database schema, and then create the message map.

Step 9 Identify Application Event Trigger

Identify the application business events to trigger message creation. The common trigger points are when the document is created, confirmed, updated, or deleted.

Use the Oracle Workflow Business Event System to register the business event to define the corresponding event subscription to create and send the message.

See: Integrating Oracle XML Gateway with Oracle Workflow Business Event System for details on how to register and subscribe to application business events.

Step 10 Identify Required Actions

All outbound messages require the following Actions to identify the selection criteria. Make a notation on your worksheet to include them.

Step 11 Identify Source and Target Document Levels

See: Identifying Source and Target Document Levels.

Map Analysis Guidelines for Inbound Messages

The map analysis process for inbound messages consists of the following steps:

Map Analysis Guidelines for Inbound Messages Checklist

Use the following table as a checklist to track your progress when analyzing an inbound message. Details of each step are provided in the following sections. Use the "Completed" column to enter completion data or to check off the step when completed.

Step Completed Description
1   CREATE WORKSHEET: Create a worksheet to identify all data.
2   SET UP SOURCE: Get the DTD (source) for the required message or use a production XML message.
3   SET UP TARGET: Populate the target column of the worksheet with the Application Open Interface table definitions or Application API parameter list.
3A   Identify the required Application Open Interface (target) table columns or Application API parameters.
4   RELATE SOURCE ELEMENT TO TARGET ELEMENT: For each Application Open Interface (target) table column, identify the DTD (source) element to map from.
4A   Identify where code conversion is needed.
4B   Identify Derivation Rules
4C   Identify Defaulting Rules
5   CONVERT FROM OAG FORMAT TO ORACLE FORMAT: For each OAG DTD (source) DATETIME, AMOUNT, OPERAMT, or QUANTITY element, identify the Application Open Interface (target) column or Application API parameter to map to. Other XML standards may have similar elements.
5A   Identify and map each DATETIME element.
5B   Identify and map each AMOUNT element.
5C   Identify and map each OPERAMT element.
5D   Identify and map each QUANTITY element.
6   ADD SIBLING FOR DUPLICATE NODES/ELEMENTS: Add Siblings nodes/elements if needed.
7   REVIEW DTD USERAREA: Review all OAG's USERAREA definitions and determine whether they should be mapped to the Application Open Interface table column or Application API parameter. Other XML standards may have similar elements.
8   RESOLVE DATA GAPS: The DTD (source) elements for as many Application Open Interface (target) table columns or Application API parameters have been identified, and identify any data gaps.
9   OPTIONAL Actions: For Application products that use Application Open Interface tables to stage incoming data and utilize an Application Open Interface API to validate the staged data Use Insert to Database Table action to insert data into Application Open Interface tables Use Procedure Call action to execute Application Open Interface API For Application products that use application APIs that combine staging tables and the validation API. Use Procedure Call action and map source (DTD) data to the Application API parameter list.
10   REQUIRED ACTION: Add root-level, post-process action to raise business event indicating inbound process is complete. Add Procedure Call action for ECX_STANDARD.setEventDetails. See setEventDetails in the API Appendix.
11   IDENTIFY SOURCE AND TARGET DOCUMENT LEVELS.

Compare Database Views (Source) to DTD (Target)

Step 1 Create a Worksheet

Create a worksheet with the following columns: Target, Required (Y/N), Source, Code Category, Derivation Rule, Default Value, and Action, as shown in the following table:

Target Required (Y/N) Source Code Category Derivation Rule Default Value Action
             
             

Step 2 Set Up Source

Get the DTD (source) for the required message or use a production XML message.

Include the the Field Identifier and Segment Descriptions, from the Open Applications Group Integration Specification Appendixes C and D, respectively.

Note: You may use third party software to expand the DTD or use a production XML message.

Step 3 Set Up Target

Populate the target column of the worksheet with the Application Open Interface table definitions or Application API parameter list.

Note: You may use third party software to expand the DTD or use a production XML message.

Step 3A Identify Required Target Elements

Identify the required Application Open Interface (target) table columns or Application API parameter list as follows:

Step 4 Relate Source Element to Target Element

For each Application Open Interface (target) table column, identify the DTD (source) element to map from.

Note: Use the Open Applications Group Integration Specification Appendix C (Field Identifier Descriptions) and D (Segment Descriptions) to get detailed descriptions of each element identified on the DTD.

If the target column is for an internal ID, you must resolve this using a derivation or defaulting rule as outlined in steps 4B and 4C below. The sender cannot send an ID as they do not know what the valid internal IDs are. XML Gateway provides derivation actions to derive address and organization ID.

DTD attributes (lowercase tags) are not stored in the Oracle E-Business Suite, and therefore are not mapped. However, the value of the attribute can be used to determine the exact Application Open Interface table column or Application API parameter to map to.

Step 4A

If the Application Open Interface (target) table column can be sourced from a DTD (source) element, determine if the DTD (source) element value requires code conversion so the resulting value is meaningful to the Oracle E-Business Suite.

If code conversion is required, identify the code category from the list in Appendix B.

Identify the from/to value to determine if the required values are available in the database you are using. If the values are not available, they must be added.

Step 4B Identify Derivation Rule

If the Application Open Interface (target) table column cannot be sourced from a DTD (source) element, determine if it can be derived. Refer to your product's Application Open Interface documentation for any predefined derivation rules. If a derivation rule is defined, make sure the incoming message provides the data to support the derivation rule because the Application Open Interface API will use the data to derive the value for the target column. Make a notation of the derivation rule on your worksheet so that you can verify this during unit testing.

If no derivation rule is defined, you can define one. The derivation rule can be based on several DTD elements or some default values. Make a notation of the derivation rule on your worksheet. Make a notation that an Action may be required.

Refer to Transaction Map - Actions for a list of XML Gateway supported Actions.

Determine if the derivation rule (element or literal) requires code conversion for the trading partner. If code conversion is required, identify the code category from the list in Appendix B.

Identify the from/to value to determine if the required values are available in the database. If the values are not available, they must be added.

Step 4C Identify Defaulting Rule

If the Application Open Interface (target) table column cannot be sourced from a DTD (source) element or derived, determine if it can be defaulted. Refer to your product's Application Open Interface documentation for any predefined defaulting rules. If a defaulting rule is defined, make sure the incoming message provides the data to support the defaulting rule. The Application Open Interface API will use the data as the default value for the target column. Make a notation of the defaulting rule on your worksheet so that you can verify this during unit testing.

If no defaulting rule is defined, you can define one. The default value may be set directly in the target definition using the Message Designer or as an XML Gateway Action if the default value is based on a condition. See Appendix C - XML Gateway Supported Actions.

Determine if the defaulting rule (element or literal) requires code conversion for the trading partner. If code conversion is required, identify the code category from the list in Appendix B.

Identify the from/to value to determine if the required values are available in the database. If the values are not available, they must be added.

Step 5 Convert from OAG Format to Oracle Format

For each DTD (source) DATETIME, AMOUNT, OPERAMT, or QUANTITY element, identify the Application Open Interface (target) column or Application API parameter to map to.

Oracle E-Business Suite represents date, amount, operating amount, and quantity in a single database column. OAG represents these as a collection of data. Oracle XML Gateway provides an Action to convert the OAG representation to the Oracle representation. Make a notation that this column requires an Action for "Convert from OAG" that will be defined using the Message Designer.

Step 5A

For the DATETIME element, identify the Application Open Interface (target) table column for date.

Values for attributes "qualifier," "type," and "index" are not mapped because the meaning is implied in the Application Open Interface table column for date.

Note: OAG DATETIME is made up of the following attributes and elements: qualifier, type, index, YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, SUBSECOND, TIMEZONE.

Step 5B

For the AMOUNT element, identify the Application Open Interface (target) table columns for currency code and debit/credit flag if available. The XML Gateway "Convert from OAG" Action can be defined to store the OAG currency code and debit/credit flag in the columns identified, or ignored if the columns are not available.

Values for attributes "qualifier," "type," and "index" are not mapped because the meaning is implied in the Application Open Interface table column.

Values for NUMOFDEC and SIGN are implied in the Oracle representation of the amount value. The values are not mapped unless your application supports it. If so, you will need to map them using the Message Designer.

Note: OAG AMOUNT is made up of the following elements and attributes: qualifier, type, index, VALUE, NUMOFDEC, SIGN, CURRENCY, DRCR.

Step 5C

For the OPERAMT element, identify the Application Open Interface (target) table columns for the currency code and unit of measure code if available. The XML Gateway "Convert from OAG" Action can be defined to store the OAG currency code and unit of measure code in the columns identified, or ignored if the columns are not available.

Values for attributes "qualifier" and "type" are not mapped because the meaning is implied in the Application Open Interface table column.

Values for NUMOFDEC, SIGN, UOMVALUE, and UOMNUMDEC are implied in the Oracle representation of the operating amount value. The values are not mapped unless your application supports it. If so, you will need to map them using the Message Designer.

Note: OAG OPERAMT is made up of the following attributes and elements: qualifier, type, VALUE, NUMOFDEC, SIGN, CURRENCY, UOMVALUE, UOMNUMDEC, UOM.

Step 5D

For the QUANTITY element, identify the Application Open Interface (target) table column for the unit of measure code if available. The XML Gateway "Convert from OAG" Action can be defined to store the OAG unit of measure code in the column identified, or ignored if the column is not available.

The value for the "qualifier" attribute is not mapped because the meaning is implied in the Application Open Interface table column.

Values for NUMOFDEC and SIGN are implied in the Oracle representation of the quantity value. The values are not mapped unless your application supports it. If so, you will need to map them using the Message Designer.

Note: OAG QUANTITY is made up of the following attributes and elements: qualifier, VALUE, NUMOFDEC, SIGN, UOM.

Step 6 Add Sibling for Duplicate Nodes/Elements

A DTD defines a single occurrence of an element, but additional occurrences can be added during message implementation to accommodate the business data. Map the duplicate node to the appropriate Application Open Interface table columns.

An example is the DTD element for PARTNER used to identify the trading party. If the Application Open Interface requires a SHIP-TO, BILL-TO, and REMIT-TO, then two PARTNER sibling nodes (same hierarchy level) were added to the original DTD to accommodate the BILL-TO and REMIT-TO. Map these entities to the appropriate Application Open Interface table columns.

Step 7 Review DTD USERAREA

Consider that the original DTD may have been extended to support additional data required by the message. Review all USERAREA definitions and determine whether they should be mapped to the Application Open Interface table column or to an application API parameter.

For outbound messages, all application flexfields were mapped to USERAREA fields. If the outbound message is being processed as an inbound message to another Oracle E-Business Suite application module, the values may be meaningful. If so, they must be mapped to Application Open Interface table columns or Application API parameters.

Step 8 Resolve Data Gaps

At this point, you have identified DTD (source) elements for as many Application Open Interface (target) table columns or Application API parameters as possible. Any required Application Open Interface (target) table column or Application API parameter that has not been mapped represents a data gap.

Step 9 Optional Actions

For Application products that use Application Open Interface tables to stage incoming data and utilize an Application Open Interface API to validate the staged data:

For Application products that use application APIs that combine the staging tables and the validation API:

Step 10 Required Action

Add root-level, post-process action to raise business event indicating inbound process is complete.

Add Procedure Call action for ECX_STANDARD.setEventDetails. See setEventDetails in the API Appendix.

Step 11 Identify Source and Target Document Levels

See Identify Source and Target Document Levels.

Identifying Source and Target Document Levels

After completing the map analysis, identify the document levels for both the source and target data.

A document level represents a collection of data that repeats. For the Application Open Interface tables or database views, each table represents a document level. A level is the parent in a parent-child relationship.

DTDs do not use document levels because the levels are implied based on usage. Refer to the tree diagram in the OAG definitions to get a sense of how the data is grouped. The tree diagram will also give you an idea of where additional occurrences of a datatype may be required.

Once you have identified the document levels for the source and target, proceed to relate the source data structure to the target data structure. This task is straightforward if the number of data levels in the source and target are identical, but can be difficult if the numbers are different. If the number of levels of the source is greater than the target number, you must collapse levels. If the number of levels of the source is less than the target number, you must expand levels.

Collapsing Levels

Collapsing levels is the mapping of multiple source levels to the same target level. For example, if your source is 3 levels and your target is 2 levels you can collapse the levels as shown in the following figure:

the picture is described in the document text

In the correct example above, the result of collapsing levels is that the data in Source Levels 2 and 3 are consolidated and mapped to Target Level 2. If there are two rows in Source Level 2 and three rows in Source Level 3, a total of six rows will be created in Target Level 2.

The incorrect example shows the collapsing of Source Levels 1 and 3 to Target Level 1, causing Source Level 3 to cross over Target Level 2.

Another option is to relate Source Levels 1 and 2 to Target Level 1 and relate Source Level 3 to Target Level 2, as shown in the correct example below. (Do not map Source Level 3 to Target Level 1, crossing over Target Level 2.)

the picture is described in the document text

Whichever option you choose, consider what it means to promote lower level detail data to a higher level. The source data may need to be aggregated to be meaningful at the higher level.

Expanding Levels

Expanding levels is the mapping of one source level to multiple target levels. For example, if your source is 2 levels and your target is 3 levels you can expand the levels as shown in the following figure:

the picture is described in the document text

The result of expanding levels, as shown in the correct example above, is that the data in Source Level 2 is distributed and mapped to Target Levels 2 and 3. If there are two rows in Source Level 2, two rows will be created in Target Level 2 and Target Level 3.

Do not expand Source Levels across Target Levels, as shown in the incorrect example above. Source Level 1 is incorrectly expanded to Target Levels 1 and 3, crossing over Target Level 2.

Another option, as shown in the correct example below, is to distribute Source Level 1 to Target Levels 1 and 2 and map Source Level 2 to Target level 3. (Do not map Source Level 1 to Target Levels 1 and 3, crossing over Target level 2, as shown in the incorrect example.)

the picture is described in the document text

Whichever option you choose, consider what it means to demote data from a higher level to a lower level of detail. The source data may need to be deaggregated to be meaningful at the lower level.

Level Expansion for Discontinuous Nodes

Level expansion is supported if the target expanded levels are all siblings of each other or if they are all children of the previous node. The following diagram shows an example of correct expansion of levels.

the picture is described in the document text

In the example above, Target Level 2 and Target Level 3 are siblings to each other and children of Target Level 1.

The following diagram shows an example of invalid level expansion:

the picture is described in the document text

In the example of invalid level expansion above, Target Level 2 and Target Level 3 are siblings to each other and children of Target Level 1. Target Level 4 is a sibling of Target Level 1, with no relationship to Target Levels 2 and 3.

See Discontinuous Nodes for more information on discontinuous nodes.

Another way to accommodate the data structure mismatch is to collapse or expand the database views or Application Open Interface tables and use the modified database views or application open interface table definitions to create the message map.

The resulting hierarchy mapping is defined using the Message Designer Level Mapping Tab.

Recommending DTD Additions or Changes to OAG

Oracle is a member of the Open Application Group's standards committee chartered with developing industry-independent XML standards. This group meets periodically to review recommendations and is responsible for publishing standards changes and additions.

During the map analysis process, you may discover that the needed fields are not represented in a DTD or that a needed DTD is not supported by OAG.

Whether you are recommending the creation of a brand new Business Object Document (BOD) and Document Type Definition (DTD) or additions or changes to an existing DTD, please present your recommendation in the OAG format and be prepared to identify the business case and justification. If you are making a recommendation to add or change an existing DTD, identify the DTD and version you are using. Please make sure your proposed DTD or DTD changes supports both the Application-to-Application (A2A) and Business-to-Business (B2B) scenarios.

If you would like Oracle to submit the request to OAG for you, enter an enhancement request. We will make the proposals to the OAG committee and report back to you. If you want to present your case directly to OAG, please let us know and we will include you in the meeting.

Special Considerations for Custom Messages

Once a document is extracted from the Oracle E-Business Suite, consider updating the application tables to indicate the document has been extracted. This may require adding columns to the appropriate tables. This may be important to the Oracle E-Business Suite for document status reporting or to manage the supply and demand data.

Updating the Oracle E-Business Suite application tables was necessary in the EDI world to prevent a document from being extracted more than once. In the XML Gateway model, documents are extracted based on an event trigger in the Oracle E-Business Suite (as the documents are created) as opposed to batch processing used in the EDI model.

For inbound messages, consider adding calls to application procedures (as an Action) to link the Application Open Interface API process to the downstream process.