Overview of Oracle EDI Gateway
Oracle Applications provides users with the ability to conduct business electronically between trading partners based on the Electronic Commerce standards and methodology. One form of Electronic Commerce is Electronic Data Interchange (EDI).
EDI is an electronic exchange of information between trading partners. Data files are exchanged in a standard format to minimize manual effort, speed data processing, and ensure accuracy.
The EDI Gateway performs the following functions:
- define trading partner groups and trading partner locations
- enable transactions for trading partners
- provide location code conversion between trading partner location codes and codes used in Oracle Applications
- provide general code conversion between trading partner codes or standard codes
- define interface data files so that application data can interface with EDI translators
- extract application data, format, and write to data files (outbound transactions)
- import data or converted codes into application open interface tables so that application program interfaces (API) can validate and update Oracle application tables (inbound transactions)
How Oracle EDI Gateway Works with Other Oracle Applications
Oracle Applications are designed with an open architecture for easy integration with EDI translators and electronic transmission products to provide a seamless solution. Oracle Applications utilize the Oracle EDI Gateway to integrate with EDI translator software. EDI translation software packages integrate with an electronic transmission service to provide a closed-loop between Oracle Applications and the trading partner's application.
The Oracle Applications for Manufacturing, Distribution, and Financials are EDI-enabled using the Oracle EDI Gateway product. The Oracle EDI Gateway product augments the existing standard paper document capabilities of Oracle Applications, or adds functionality where no corresponding paper documents exist.
A common EDI implementation is via ASCII data files in a batch environment. Data from the sending application is extracted into an application data file. The application data file is received by the translation software which translates it into the an EDI standard both trading partners agree upon. Then the EDI data file is placed on a network for transmission to the receiving application. The receiving application's EDI translator receives the EDI data file from the network and begins the file processing in reverse sequence. The translator translates the EDI data file and creates an application data file meaningful to the receiving application. The receiving application receives the application data file for processing and imports the data into the application.
The following figure illustrates the outbound EDI Gateway transaction flow:
Figure 1 - 1.
The following figure illustrates the inbound EDI Gateway transaction flow:
Figure 1 - 2.
Oracle EDI Gateway Product Architecture
With an open architecture, Oracle Applications allows you to choose the best translation and electronic transmission service for your business requirements. You can use a commercially available EDI translator and transmission provider or use a proprietary solution. The Oracle Applications and the Oracle EDI Gateway places no restriction on your choices.
Product Components for All Transactions
The Oracle EDI product architecture consists of the following features for both outbound and inbound EDI transactions.
Trading Partner Definition
Used for both inbound and outbound transactions to define trading partner locations within a trading partner group. By defining a trading partner, you do the following:
- establish a link to the location or business entity defined in the Oracle Applications
- establish a link to the trading partner definition in the EDI translator.
Code Conversion Definition
Used for both inbound and outbound transactions to convert general codes between the sending and receiving systems. This can be used to convert Oracle Applications codes to EDI standard codes or user-defined codes.
Flexfields (attributes) are user-defined fields in the Oracle Applications. They are found in both inbound and outbound transactions.
You have to modify the general EDI translator data maps or templates to use flexfields.
Product Components for Outbound Transactions
The Oracle EDI Gateway product architecture consists of the following components for outbound transactions:
Oracle Applications Concurrent Program Manager
Used for outbound transactions to initiate data extraction programs that create interface data files that are passed to the EDI translator for processing the data into the desired EDI standard.
Stored Procedures to Prevent Duplicate Extraction
Used with outbound transactions to provide encapsulated application logic to record the EDI transaction in the Oracle application. For example, the Oracle Purchasing tables are updated to reflect the extraction of purchase order data. This prevents the same data from being extracted again.
Transaction-specific Extension Tables
Used with outbound transactions to temporarily store user-supplied data or data from a non-Oracle Applications source that is required by target EDI documents. See: Extensible EDI Gateway Architecture.
Transaction-specific Interface Tables
Used with outbound transactions to temporarily store data extracted from the Oracle Applications, including converted codes and data copied from customized extension tables.
Transaction-specific Database Views
Used with outbound transactions to provide encapsulated data selection logic for the target EDI transaction. You enter selection criteria, using Standard Request Submission, to launch individual extract programs.
Interface Tables Table
Used with outbound transactions to store the starting record identifier of each section of the output file and to track which transaction-specific interface and extension tables are related. The data extract program uses this information to write the next sequential identifier at the beginning of each record in the data file.
Interface Columns Table
Used with outbound transactions to store the assigned location of each data element within the data file. The data extract program uses this information to write data to the correct position in the data file.
Data Extract Programs
Used with outbound transactions to create a standard ASCII data file format that can be mapped to any standard. The data file contains data from Oracle Applications, converted codes from EDI Gateway tables, and descriptive flexfields defined in both EDI Gateway and the Oracle applications.
The EDI Gateway extension tables are used to hold outbound data from tables that are outside the Oracle application. These extension tables are installed with EDI Gateway. However, you must define and populate the table columns if you want to use these tables.
Each transaction interface table has one extension table per interface table for the given transaction. The extension tables share the same base interface table name as the transaction with an "_X" suffix. For example, the primary interface table ECE_DSNO_ORDERS has the extension table ECE_DSNO_ORDERS_X.
Some Oracle Applications have additional application tables for vertical industry solutions. These additional tables are detected in the EDI Gateway by reading system setup tables. If industry-specific tables are detected, their data, along with customer-defined extension table data, is copied to the EDI Gateway extension tables during the data extraction for outbound transactions.
Note: EDI extension tables are not used with inbound transactions.
Product Components for Inbound Transactions
The Oracle EDI Gateway product architecture consists of the following components for inbound transactions:
Oracle Applications Concurrent Program Manager
Used for inbound transactions to initiate data load programs that import interface data files from the EDI translator to EDI Gateway for processing into Oracle Applications.
Data Load Programs
Used with inbound transactions to load the Oracle Applications open interfaces from a standard ASCII data file. The data load program converts external codes in the file to internal codes found in the code conversion tables. The internal codes found in the code conversion tables or found in the internal fields as populated by the EDI translator are loaded into the application open interface tables.
Oracle Applications Open Interface
Used with inbound transactions. The application open interface consists of temporary interface tables and an application open interface API. The temporary interface tables are used to store the data loaded by the data load programs. The API is used to validate the data in the temporary interface tables and populate the Oracle Application tables. See: Running the Import Program for Inbound Transactions. Error detection, reporting, correction, and recovery are addressed by the respective Oracle Applications.
EDI Standards Supported
The Oracle EDI Gateway product is designed to support any EDI standard supported by EDI translation software; it is not tailored to any specific EDI standard.
EDI Transaction Support
The following transactions are supported:
Extensible EDI Gateway Architecture