This chapter contains information about Oracle e-Commerce Gateway implementation.
This chapter covers the following topics:
To successfully implement the Oracle e-Commerce Gateway and enable specific transactions within the product, the implementer needs to have certain knowledge and experience beyond the Oracle e-Commerce Gateway. This section describes those additional requirements.
If traditional EDI transactions are being implemented, the following must be understood:
Understand Standard Components
Implementers must be familiar with all EDI standards components, i.e., segments, elements, and code values that make up EDI transactions for which the E-Commerce Gateway interface is being implemented. Implementers must know which elements in an EDI transaction correspond with fields in an Oracle E-Commerce Gateway interface file to be able to assist with Translator software mapping. Implementers must be familiar with codes (qualifiers) that are used to identify data elements in an EDI transaction.
Understand Characteristics of the EDI Transaction
Implementers must be familiar with the characteristics of an EDI transaction.
For example, the ASC X12 standard Purchase Order 850 transaction has a three level structure: Header, Item, and Shipments. The Oracle Order Management Order Import open interface has a two level structure: header and the combined Item/Shipments. Each combination of the Item and Shipment in the transaction must be combined to create an item record in the transaction interface file.
Understand the Data Mapping Requirements
Implementers should review the client's data mapping requirements to identify elements for which there is no corresponding field in the Oracle E-Commerce Gateway transaction interface file. For example, the Trading Partner may send data at the detail line level in a purchase order transaction that identifies their warehouse bin/bulk location. The Trading Partner requires the supplier to print this data on a label and apply the label to each carton associated with the detail line item. This carton label facilitates the Trading Partner's receiving process.
If necessary, it is recommended that the EDI implementation team include an application specialist in the relevant transaction area.
Attend an Oracle e-Commerce Gateway Course
Implementers should attend an Oracle e-Commerce Gateway course. They must understand all the features including profile setups, process rules, column rules, trading partner definitions, and code conversion for setting up the product.
Understand Trading Partner Setups
It is essential that the relationship between Translator and EDI Location Codes be completely understood. Also a policy should be put in place with the customer so an administrator can easily maintain the trading partner setup screens given only basic data about the Trading Partner, Location, and permissible transactions.
Understand General Code Conversion Setups
The Code Conversion capabilities of the Oracle e-Commerce Gateway can provide a comprehensive set of criteria to convert internal Oracle codes, site codes, payment codes etc. to/from the terms used by the Trading Partners. These conversions can be undertaken globally or based upon specific criteria using up to five keys - see the Oracle e-Commerce Gateway User's Guide for more details. Conversion requirements should be carefully planned and kept as simple as possible to avoid over complex situations requiring burdensome maintenance.
Understand Extension tables (for Outbound Transactions)
Implementers should understand or have access to a developer who understands PL/SQL and how data is stored in the database. They can determine feasibility of changes, how to make those changes without disturbing the existing routines, and how to make them in such a way that the changes can be easily adapted when patches are installed. This also applies to inbound transactions when additional routines are needed to make the data put into the interface tables by the Oracle e-Commerce Gateway compatible with the import process and/or the customer's needs.
A basic knowledge of the table structure of the relevant Oracle E-Business Suite and Oracle e-Commerce Gateway is a big advantage if any custom work is contemplated.
Know the Transient Data in the Oracle E-Business Suite
The Oracle E-Business Suite produces data as needed by the application. They may not retain data in the tables that is calculated because the numbers used to produce the calculation (number of units and discount percentage in the example below) may change each time the application is run. The data is printed on a permanent paper document. Because EDI is a substitute for the paper document, this data must be computed and stored in the outgoing file. The implementer must allow for this by defining a field in the EDI extension table and the code to populate it.
Know the Functionality of the Oracle E-Business Suite
Verify that the Oracle E-Business Suite performs the function expected by the transaction.
Know the Required Fields and Default Data
Know the required fields in the transaction interface file and the application open interface and know the defaults defined in the Oracle e-Commerce Gateway for the transaction
The open interface tables require certain fields to be populated to properly process the incoming data. Because it is not known whether the data is available on the source system, a default value can be used so that processing can continue. Required fields and default values are dependent on how the application is configured to handle keyboard entry in setup. It is also very important that the base application is set up with the data that it is expecting.
For standard transactions, an e-Commerce environment must be installed. Generally the following must be done in the Translator specifically and the e-Commerce environment generally.
This document does not discuss the detail of installing Translators or the operation of Translators.
Each company must install a Translator to processes traditional standard transactions such as ASC X12 transactions and EDIFACT messages. They must review its system requirements, and its integration requirements with the Oracle e-Commerce Gateway.
The ability to configure the Translator to suit different formats is also a consideration to facilitate any changes that may be required from updates to the Oracle e-Commerce Gateway. These changes may be in the form of new or additional transactions, changes in the customer's business requirements, and changes occasioned by new or existing trading partners. If the Translator is difficult to update or configure, this may impact the successful, timely outcome of an EDI implementation.
Another consideration is whether or not the Translator is running on the same server as the Oracle e-Commerce Gateway. In some cases, the Translator has been installed on a separate machine, for example a mainframe. When this is the case, it is necessary to allow for file transfer requirements and scheduling to/from the Translator. In some instances a file transfer to/from a mainframe may require that the file be of fixed length. In this case. the variable nature of the files used by the Oracle e-Commerce Gateway may pose problems of padding (for outbound transactions) and interface file definition (for inbound transactions).
Trading Partner Definitions
Translators have criteria for defining trading partners, that is different from the trading partner definitions used in the Oracle e-Commerce Gateway.
The Translator setup requires identifying the following:
Sender and receiver identification codes for the electronic envelopes.
The EDI standard and its version/release or data dictionary for traditional EDI transactions.
The transaction's data map used to map data between the source data file and the standard transaction.
Which code conversion sets are to be used for the transaction for the trading partner.
Communication method.
Communication service provider.
The Oracle e-Commerce Gateway requires the Translator's identification code for its trading partner definition in the transaction interface file on the Control Record 0010. It is defined at the ‘Translator Code' in the trading partner setup in the Trading Partner Detain tab in the Trading Partner setup.
Code Conversion
Like the Oracle e-Commerce Gateway, Translators provide for code conversion between the value defined in the base Oracle E-Business Suite application and the values required by the EDI standard or the trading partner. Code conversion is performed on specific data elements. You can use the Oracle e-Commerce Gateway for some data elements and the Translator on other data elements. You should decide where it is most efficient for your implementations, bearing in mind how easy it will be in the future to add, edit, or delete conversions in the Oracle e-Commerce Gateway or the Translator.
Data Mapping
Review the Oracle e-Commerce Gateway transaction interface files and the EDI standard transaction to determine where the data is positioned in the EDI standard transaction. If transaction data maps already exist, they provides a good starting point since the standard transaction portion of the data map can be copied from the existing data map. You will need to substitute its mapped position defined in the Oracle e-Commerce Gateway transaction interface file.
Some Translators provide a base data map for the Oracle e-Commerce Gateway transaction interface file. These base data maps are currently based on the initial release 11. They are not likely to be ‘plug and play' data maps. Note that the Translator providers may charge additional license or service fees for these pre-configured data maps.
The base data maps most likely need customization for the following reasons:
Whether the internal or external code(s) are available in the interface file (if you used code conversion)
System or business requirements
Trading partners requirements
The base data maps may also need changes if software patches add or change data element positions in the transaction interface file and you accept new records after the seed data reconciliation review.
The following reports may facilitate your data map reviews. Run the reports as needed:
Transaction Record Layout report to see the transaction interface file
Transaction Data File report to see data from a file against its transaction interface file layout
The following process should be followed after a patch is applied. This process attempts to restore the record layout to the layout as defined before the latest patches were applied. Review the log from this process to see the impact of the patch and the reconstructed transaction record layout:
Seed Data Reconciliation process
For outbound transactions, if data cannot be found in the transaction interface file as defined by the Oracle e-Commerce Gateway, supplemental data may be found in user defined flexfields or the user defined transaction extension tables. Data may also be mapped to transaction flexfields for inbound transactions. Custom code is required to populate the transaction extension tables if that option is used for outbound transactions.
If there are still gaps in the data, determine the best way to address data or functional gaps. Two alternatives may be followed for inbound transactions:
Custom modifications may be necessary in the base application
This applies to outbound transactions: there may be the case where the transaction passed all the validation in the Oracle e-Commerce Gateway, but the application open interface may still require additional data. Write custom code to add data to the transactions in the application open interface tables. This custom code is executed after the Oracle e-Commerce Gateway wrote the transactions to the application open interface table but before the application open interface executes.
For inbound transactions, modifications should be made similarly to those made to populate the extension tables.
Transaction Processing
The Oracle e-Commerce Gateway creates transactions by the following methods:
A transaction is initiated by an event in the base application.
The base application initiates a request within Concurrent manager with key data from the transaction to write the transaction to a transaction interface file.
Created by a scheduled request within Concurrent Manager.
Usually the request extracts all eligible transactions that are ready to be extracted.
You can limit the transactions selected by entering selection parameters in the request.
Set up appropriate transaction interface file detection in the file directory. The file directory is defined in the initial application setup for all transactions in the System Profile Options in the Oracle e-Commerce Gateway. The Translator needs to be able to access the interface file.
Follow your file backup and archive procedures and practices that may also need to consider local fiscal requirements.
Determine the frequency that the Oracle e-Commerce Gateway files are processed through the Translator. Ideally, you should put completed transaction files either in another directory or under other file names so that the Translator cannot access the file until the Oracle e-Commerce Gateway is finished with it.
Ensure that the order in which the processes are performed - e.g. for outbound transactions, Oracle e-Commerce Gateway processing, file transfer, archive, or Translator - fits in with the local environment and other processes being performed around the Oracle e-Commerce Gateway.
Transaction Testing
Create test acceptance criteria to test the transactions.
Bear in mind that each trading partner may have its own requirements and therefore one size may not fit all. Customization may extend to a lower level than just the transaction type. This may increase the time required for both development and testing. Trading partner and customer are not synonymous! For example, if a chain of ten retail stores allows each store to require some sort of different data on a transaction, then there are ten trading partner data maps, not one data map. Another example is a trading partner in California where the state may require additional hazardous material data for shipping.
First test internally to validate initial mapping, conversions, settings and interaction between the Oracle e-Commerce Gateway and Translator, e.g.
Interface file testing into/out of the Oracle e-Commerce Gateway
Interaction testing to/from the Translator
Interaction testing along the path between the applications and the Translator output/input
Verify and compare the data passed to/from the applications with the EDI transaction file into/out of the Translator.
Nominate test Trading Partners for the initial transaction outbound/inbound and obtain their agreement to be test sites.
Where the number of trading partners is large, it may be necessary to take a phase testing approach, that is:
An initial small set of test trading partners to validate correct mapping, and identify any initial issues caused by new mapping specifications and/or software.
A second, larger set of trading partners to verify the fixes implemented as a result of the initial trading partner testing.
Final testing with the total trading partner community, or move directly to production status.
It is important that acceptance of correct operation at each stage be documented before proceeding to the next stage of testing.
The process of sending and receiving an e-commerce transaction is relatively simple. As with all simple concepts however, there is usually a lot of work to do in mapping customer, trading partner, and Translator requirements to ensure that each stage has the required data in the correct fields. Most of the implementation time is taken in these tasks.
The checklist for the issues involved in a standard Oracle e-Commerce Gateway implementation can be summarized as:
Data mapping requirements
Trading Partner setups
General Code Conversion setups
Extension tables (for outbound transactions)
Standards to be used for transactions
Relevant functionality in the Oracle E-Business Suite
Required fields and defaults on transaction interface file and application Open Interface
Customer's setup and procedures for using the applications
Changes in procedures or business rules within the application relating to e-Commerce
Specific implementation rules negotiated with the Trading Partners
Capabilities of the Translator in creating and using the transaction interface file
Method for file transfer between the Translator and Oracle e-Commerce Gateway
The planning process includes the following:
Develop project plans
Investigate and understand the business impact of each transaction
Identify customization requirements
Coordinate the Translator interface
Collate all setup data
Write transaction or message specifications
Produce Test Plans
Develop transaction archiving policies
Coordinate testing with Trading Partners
The scope of a project depends on the knowledge of the implementers, number of Trading partner sites to define, number of Transactions implemented, and the number of data maps needed in the Translator.
A simple project is one that involves one supported transaction, few trading partners, and minimal code conversion.
Setup includes the hardware setup and software installation of the prebuilt products. It does not address the changes that may be needed for code conversion and customization which are part of the Modification phase. Also, Modification may either come before Testing (since the need for changes are identified in the Definition phase), or there may be another Testing phase after Modification. A good minimum guideline for this second phase would be one day of testing for each day of modification.
The following table represents a project timeline for a simple implementation project. The resources for the project are the Customer EDI Implementer and an Experienced Oracle e-Commerce Gateway Implementer. An "X" indicates that the resource participates in that phase of the project:
| Phase | Time (Days) | Customer EDI Implentor | Experienced Oracle e-Commerce Gateway Implementor |
|---|---|---|---|
| Training | 2 | X | X |
| Project Definition | 10 | X | X |
| Setups | 2 | X | X |
| Testing | 10 | X | X |
| Modification | TBD | X | X |
| Moving to Production Status | 5 | X | N/A |
| Production Status/Ongoing Support | 15 | X | X |