Introduction

This chapter contains implementation information about Oracle e-Commerce Gateway.

This chapter covers the following topics:

Purpose of the Implementation Manual

The Oracle e-Commerce Gateway Implementation Manual provides details to facilitate implementation of the product, and highlights additional actions to ensure a successful implementation.

While Oracle e-Commerce Gateway is in itself, a comprehensive product that will suit most customer's e-business integration requirements, most of the effort expended during an implementation cycle concerns defining, mapping, and balancing customer requirements against trading partner expectations. This guide includes implementation details, and contains an overview of the main points that should be taken into consideration during the course of an Oracle e-Commerce Gateway project.

This implementation manual provides the following:

Documentation

The following documentation for Oracle e-Commerce Gateway is available:

Oracle e-Commerce Gateway Overview

e-Business Integration

Oracle e-Commerce Gateway is a standards-based integration product for Oracle E-Business Suite. This integration product allows you to integrate Oracle E-Business Suite with applications residing inside or outside of your enterprise, communicating via the Intranet, Extranet, or the Internet.

Oracle e-Commerce Gateway evolved from the Oracle EDI Gateway product, focusing on Electronic Data Interchange (EDI) into a product focused on e-business integration. All the features and functions of Oracle EDI Gateway are retained and enhanced to create the Oracle e-Commerce Gateway product

Oracle e-Commerce Gateway supports seamless integration, streamlined implementation, and rule-based transaction processing to automate your business operations. The major features include:

Oracle e-Commerce Gateway is designed with an open and extensible architecture for easy integration with any third party application.

The product is designed with self-contained yet integrated modules focused on ease of implementation; you simply define the business rules and configuration parameters, then you can implement any of the prebuilt transactions.

Extensibility hooks are provided to integrate custom transactions and extend the Oracle e-Commerce Gateway supported transactions by incorporating data from non-Oracle applications data sources.

Configurable Integration Environment

Oracle e-Commerce Gateway supports configurations at the system, transaction, trading partner, and process levels giving you utmost control of your data, interface files, and business processes.

You can configure how data elements are validated and mapped, the structure and layout of an interface file, when a business process is initiated, and how it should proceed. Furthermore, you can control the behavior of a process if an exception is detected.

All rules are stored in a repository to support dynamic run-time message creation, automated process monitoring, and exception analysis. Using a single window, you can change a rule by changing the information stored in the Oracle e-Commerce Gateway repository. The updated rule takes effect at run-time without any code modifications.

System level configurations apply to all transactions, and include the following:

Transaction level configurations apply to a specific transaction, and include the following:

By defining the validation rules, you indicate how a transaction is to be validated, what constitutes an exception, and what action to take if an exception is detected. This ensures that only valid transactions are passed to Oracle e-Commerce Gateway for processing. Oracle e-Commerce Gateway supports the following validation and exception processing rules: The transaction exception rules include invalid trading partner, invalid Address, and Test/Production mode discrepancy.

The data validation rules and their descriptions are listed in the following table:

Data Validation Rules
Data Rule Description
Data Type Checking Compares the data types of the data in the file to the data type defined in Gateway transaction table.
Default if Null Moves a default value to the staging table column, if the field is NULL (blank) in the interface file.
Null Dependency Checks if the incoming data for a given column has a null dependency.
Predefined List Checks if the incoming data for a given column is equal to or not equal to a value in a predefined list in the Oracle e-Commerce Gateway.
Simple Lookup Checks if the incoming data for a given column is a valid value equal to the one found in the user-defined table and column that will be used in a SQL Select Statement.
Valueset Lookup Checks if the incoming data for a given column is a valid value in a standard Oracle Valueset.
Value is Required Checks if the incoming data for a given column has a non-null value, i.e. it cannot be blank.

Each rule is associated with an action taken when an exception is detected. The exception processing options are skip current document, log the violation and continue processing, or abort the entire run.

Another form of transaction configuration is performed on the transaction data, based on user-defined code conversion rules. The Oracle e-Commerce Gateway Code Conversion module supports the following:

An example of a one-to-one relationship is the conversion of a single Oracle code for unit of measure to a unit of measure code based on the ISO 9000 code list, the ASC X12 code list, or your private code list. An example of a one to many relationship is the conversion of a single Oracle code for payment terms to its ASC X12 components for discount percent, discount days, and net days.

You can define a code conversion rule that applies to all transactions for all trading partners or one that is specific to a trading partner and transaction combination. For maximum flexibility, you can define up to five specific criteria per rule.

Intelligent search is used to identify the Oracle internal or external codes by performing the search using the maximum number of user-defined criteria then reducing the number of criteria by one until a match is found. If a match is not found, a default is used.

The final transaction configuration is related to the transaction layout. Oracle e-Commerce Gateway delivers seeded transaction layout definitions representing relevant business data from or to Oracle E-Business Suite The transaction layout definitions may be used as is, or customized to match the data you transmit to your trading partner. The transaction layout configuration options include change file structure, change record layout, change record attributes, and delete records.

In addition to the system and transaction level configurations, you may configure the trading partner attributes.

The trading partner is the entity you are doing business with and is the key link between Oracle e-Commerce Gateway and Oracle's suite of e-business products and between Oracle e-Commerce Gateway or any third party application. The third party application may be an EDI translator for EDI transactions or any other application internal or external to your enterprise. In addition to establishing these links, you can configure the trading partner attributes to indicate that a transaction is enabled or disabled for processing, and indicate the transaction status to be test or production for processing.

Trading Partners and Multiple Organizations

To support multiple organizations, you can associate trading partners with operating units linked to your responsibility during the trading partner group setups. This feature allows you to run trading partner reports and outbound transaction extract concurrent programs for a specified operating unit associated with your responsibility.

Oracle e-Commerce Gateway uses the concept of the security profile linked to your responsibility to control data access within multiple organizations. A security profile, defined based on organization hierarchies, consists of one or more operating units to which a user has access for inquiry, reporting, transaction, and data entry. This security profile is then associated with a user through his or her responsibility. This allows you to access data in multiple operating units without changing responsibility.

Three Processing Options

Once all the necessary system, transaction and trading partner level configurations are defined, and you are ready to initiate a transaction, Oracle e-Commerce Gateway supports three processing options:

Event-driven processing for time critical business transactions such as electronic payments or ship notices.

Schedule-based processing for less critical but routinely used business transactions such as purchase orders.

User-defined processing.

The processing option you select depends on the nature of your business and transaction criticality.

Once the transaction process is initiated, the run-time execution engine takes over and proceeds according to the system, transaction, and trading partner configurations you defined.

If necessary, a user-activated run-time execution log is available to assist with trouble shooting. This diagnostic tool supports multiple levels of trace details for both technical and non-technical analysts.

View Transaction Exceptions

The status of a transaction process and any reported exceptions may be viewed using a single “workbench style” window known as the View Staged Documents window. Summary or detailed inquires are supported using tree style navigation. Dynamic windows and drill-downs are provided to help analyze the cause of an exception.

Once the cause of the exception is identified and resolved, you have the option to submit the transaction for reprocessing or treat the exception as a warning by ignoring or deleting the exception.

The status inquiry, troubleshooting and reprocessing of transactions are all done in one single window, the View Staged Documents window.

Several reports facilitate the implementation process. Use the reports to view trading partner and code conversion data or review the seeded transaction layout definitions, and the contents of a data file.

Transaction List

Oracle e-Commerce Gateway is independent of all EDI standards and can be integrated with any upstream or downstream process via an ASCII file. It is this independence that enables you to select any EDI translator or third party application that best suits your business requirements.

Included in the Oracle e-Commerce Gateway product are many prebuilt business critical transactions, and integration configuration tools designed to streamline your implementation to easily transform your business to e-business.

The following table lists many of the transactions provided by Oracle e-Commerce Gateway including the direction of the transaction, a description of the transaction, and the base Oracle E-Business Suite application.

Transaction List
X12 Trans. EDIFACT Message Direction Description Base Application
850 ORDERS outbound Purchase Orders from Oracle Purchasing
860 ORDCHG outbound Purchase Order Change Request from Oracle Purchasing
832 PRICAT inbound Price/Sales Catalog into Oracle Purchasing
843 QUOTES inbound Response to Request for Quotation into Oracle Purchasing
856 DESADV inbound Ship Notice/Manifest into Oracle Purchasing
857 no
equivalent		 inbound Shipment and Billing Notice into Oracle Purchasing and Payables
824 APERAK outbound Application Advice, diagnostic message used in response to the inbound ship notice, shipment/billing notice, and invoice transactions from Oracle Purchasing and Payables
830 DELFOR outbound Planning Schedule from Oracle Supplier Scheduling
862 DELJIT outbound Shipping Schedule from Oracle Supplier Scheduling
810 INVOIC inbound Invoice, includes data for the ASC X12 110, 210, 410, 880 transactions into Oracle Payables
820 PAYORD/
REMADV		 outbound Payment Orders / Remittance Advice from Oracle Payables
850 ORDERS inbound Purchase Orders into Oracle Order Management
875 ORDERS inbound Grocery Purchase Orders into Oracle Order Management
855 ORDRSP outbound Purchase Order Acknowledgments from Oracle Order Management
860 ORDCHG inbound Purchase Order Changes from Oracle Order Management
865 ORDRSP outbound Purchase Order Change Acknowledgments from Oracle Order Management
856 DESADV outbound Ship Notice/Manifest from Oracle Shipping Execution
830 DELFOR inbound Planning Schedule into Oracle Release Management
862 DELJIT inbound Shipping Schedule into Oracle Release Management
866 no
equivalent		 inbound Production Sequence into Oracle Release Management
810 INVOIC outbound Invoice, includes data for the ASC X12 110, 210, 410, 880 transactions from Oracle Receivables
812 CREADV/DEBADV outbound Credit Memo, Debit Memo from Oracle Receivables
N/A CUSDEC outbound Movement Statistics (INTRASTAT) from Oracle Inventory

The transactions in the following table are available with Oracle Process Manufacturing. The Inbound Purchase Order and Outbound Ship Notice/Manifest transactions are based on the Oracle Process Manufacturing data model and should be treated as different transactions even though they share the same name as their respective transactions in Oracle Order Management.

Transaction List Available with Oracle Process Manufacturing
X12 Trans. EDIFACT Message Direction Description Base Application
850 ORDERS inbound Purchase Order into Oracle Process Manufacturing
855 ORDRSP outbound Purchase Order Acknowledgment from Oracle Process Manufacturing
856 DESADV outbound Ship Notice/Manifest from Oracle Process Manufacturing

Processing Traditional EDI Transactions

Although Oracle e-Commerce Gateway has evolved into an e-business integrator, it continues to be the hub for processing high volume traditional EDI transactions.

The following section describes how traditional EDI transactions are processed through Oracle e-Commerce Gateway.

Interface Files between Oracle e-Commerce Gateway and Any Translator

ASCII files are passed between Oracle e-Commerce Gateway and any Translator for traditional EDI transaction processing.

For inbound transactions, the Translator copies the data from its position in the standard EDI transaction to its required position in the Oracle transaction interface file.

The reverse data mapping is done for outbound transactions. Oracle e-Commerce Gateway creates a transaction interface file of the data from the base Oracle E-Business Suite application. The Translator copies the data to its position in the chosen standard.

The following illustration shows sample data from an ASC X12 Purchase Order (850) transaction (on the right) and an Oracle e-Commerce Gateway outbound purchase order (POO) interface file (on the left).

Sample Interface File Between Oracle e-Commerce Gateway and Purchase Order

the picture is described in the document text

Oracle e-Commerce Gateway extracts outbound transaction data from application tables and loads inbound transactions into the base application Open Interface tables.

The components of the outbound transaction flow, as shown below are as follows: Oracle E-Business Suite > Oracle e-Commerce Gateway > Flat File > EDI Translator > EDI Message sent out.

Outbound Flow of a Transaction with Oracle e-Commerce Gateway

the picture is described in the document text

The components of the inbound transaction flow, as shown below, are as follows: EDI Message received > EDI Translator > Flat File > Oracle e-Commerce Gateway > Oracle Open Interface > Oracle E-Business Suite.

Inbound Flow of a Transaction with Oracle e-Commerce Gateway

the picture is described in the document text

Oracle e-Commerce Gateway resides between Oracle E-Business Suite and a translator and processes data using ASCII interface files.

The EDI Translator accommodates the EDI standards such as ASC X12 and EDIFACT, and monitors transmitting standard formatted data between Trading Partners. The format and content of this file can be adjusted using the Interface File Definition window within Oracle e-Commerce Gateway, though any changes must be implemented within the EDI Translator's data map and setup.

An EDI Translator data map may be defined to produce a transaction according to the recommendations of any industry guideline such as UCS, EIDX, or AIAG. A data map may accommodate the data requirements of a single trading partner or many trading partners.

Oracle e-Commerce Gateway processes data via the transaction interface file that is received from or sent to the Translator. Oracle e-Commerce Gateway is independent of all standard formats since only the business data is found in the Oracle e-Commerce Gateway transaction interface files.

Oracle e-Commerce Gateway does not have communication software to transmit the standard formatted data between trading partners. Oracle e-Commerce Gateway relies on the Translator being connected to third party communication service providers to transmit data to, or receive data from, trading partners after the data is mapped to the desired standard format.

Outbound Process Flow

Oracle e-Commerce Gateway outbound transaction process creates interface data files to support any EDI Standard that is available from the Translator. Oracle e-Commerce Gateway collects all of the business data needed to map to a standard EDI transaction which the receiving Trading Partner can interpret properly into their receiving application using their equivalent of Oracle e-Commerce Gateway/Translator setup.

Oracle e-Commerce Gateway extracts the data from the base application tables, and optionally extracts data from other files/tables via extension tables. The use of extension tables requires the customization of standard code packages provided with Oracle e-Commerce Gateway.

Oracle e-Commerce Gateway does the following:

Inbound Process Flow

The inbound transaction flow is similar to the outbound transaction flow.

Oracle e-Commerce Gateway performs the following functions during an inbound transaction process after it receives an interface file from the EDI Translator or other process:

All the valid transactions are loaded into the application Open Interface tables where it is validated by Oracle Open Interface's Application Program Interfaces (APIs). Valid data is loaded into Oracle E-Business Suite application base tables.

Exception data is detected both in Oracle e-Commerce Gateway and Oracle E-Business Suite depending on the type of exception encountered. For example, Oracle e-Commerce Gateway would detect that the trading partner was not set up for a given transaction, whereas the base Oracle E-Business Suite application API would detect a duplicate invoice.

The application's standard error handling functions are used to identify, report, and resolve errors. Errors detected by the Translator are resolved by the error handling in that process. Reoccurring data errors that originate from the sender should be discussed with the trading partner for permanent corrections.

EDI Translators

The following section describes function performed by an EDI Translator in the processing of traditional EDI transactions.

The various standards for message formatting are both precise and potentially changing, in addition, there are many issues regarding the various addressing methods and communication protocols that may be used for the actual exchange of transactions. A formatting and communications interface is therefore required between Oracle e-Commerce Gateway and the external communications service. This interface software is called the EDI Translator. There are a number of specialist companies who operate in this area offering packages to address these requirements.

EDI Translators generally provide tools to map any interface data file format to any format including standard EDI transactions and messages, so data mapping to a standard like SPEC2000 should not be an issue with most Translator providers. They may not provide predefined data maps for all standards, but their software should provide a means to handle any-to-any data mapping.

Another key feature provided by the Translator is communication error and format checking to ensure that invalid messages are rejected and returned.

Translator software normally provides built in support for one or more of the EDI standards and communication methods. It may also offer support for pre-packaged extension products that include proprietary file formats.

EDI Translators perform the following main functions:

  1. Integrated Audit Trail.

    Provides an audit trail of transaction activity and profile updates.

  2. Trading Partner Identification.

    Trading partner identifications are maintained to define which transactions are enabled for test or production, which EDI standard and its version/release to map the data, define data for the electronic envelope, define the communications method to be used, etc.

  3. Standards Translation.

    Maintains ASC X12 and EDIFACT transaction tables for all versions/releases, XML, and other standards as needed.

  4. Data Mapping.

    Provide data mapping facilities between proprietary formats and the standards.

  5. Communications.

    Provides scripts to access popular VANs and VASPs, They also have the capability to send data over the Internet.

  6. Short-term Transaction Archival.

    Requeues transactions to transmit again as needed.

  7. Automatic Transaction Status Feedback to the Application

    Feedback is provided to Oracle E-Business Suite that transactions have confirmed receipts from trading partners or some other transmission status, e.g. buyers may wish to see a confirmation that a supplier received (or not) a specific order.

  8. Audit Transaction Archival.

    Maintains historical archival of data for audit purposes.