EDI Background

This section presents an overview of Electronic Data Interchange (EDI), the various EDI standards, and BEA's EDI Integration. It includes the following topics:

• What Is EDI?

• EDI Standards

• BEA WebLogic EDI Integration Architecture

 

---

What Is EDI?

Electronic Data Interchange (EDI) is a set of common data format standards developed in the U.S. and Western Europe in the late 1970s. The goal of the American National Standards Institute (ANSI), which sponsored the initial creation of what became the X12 set of EDI standards, was to establish a group of nationally recognized data formats that:

• Were hardware independent

• Were unambiguous, such that they could be used by all trading partners

• Reduced the amount of labor-intensive work required to exchange data (for example, by eliminating the need for data re-entry

• Allowed the sender of the data to control the exchange, and to know whether and when the recipient received the transaction

After sponsoring the initial definition of the standards, ANSI created the Accredited Standards Committee (ASC) to maintain and develop the X12 standard. The resulting X12 standards define the data formats and encoding rules used for a wide variety of business transactions, including order placement and processing, shipping and receiving, invoicing, payment, and many more.

To create a single international EDI standard, the United Nations/ Economic Commission for Europe (UN/ECE) Working Party on Facilitation of International Trade Procedures created the UN/EDIFACT family of standards. The EDIFACT syntax was adopted by the International Standards Organization (ISO) in 1987.

The X12 and EDIFACT standards provide equivalent functionality. The X12 standards are older and more mature; they provide functionality not yet available in EDIFACT. Much of this unavailable functionality is, however, under development for the EDIFACT standards.

The differences between X12 and EDIFACT arise primarily from their underlying data structures, such as data elements and data segments. There is no one-to-one correspondence between X12 and EDIFACT data elements; multiple X12 data elements may be needed to represent a single EDIFACT data element.

Architecture Overview

The X12 and EDIFACT standards are hierarchical sets of message element structures. At the bottom of each hierarchy, simple data structures are combined to form more complex data structures. The top of each message structure hierarchy is populated by information units exchanged by trading partners.

Different hierarchies and data structures are defined for different data sets. For example, an X12 997 message (a Functional Acknowledgment) is quite different from an X12 810 message (an Invoice), and the requirements for both are different from those for an X12 130 message (a Student Educational Record, or transcript).

Message Structure

At the base of each EDI standard is a dictionary of simple data elements. A simple data element represents the smallest named item in an X12 or EDIFACT standard, such as a qualifier, a value, or a description.

Examples of simple data elements include:

• Invoice date

• Weight capacity

• Exchange rate

• Hazardous material classification

• Unit of measurement code (such as pounds, dozens, cubic feet, gallons, and so on)

The X12 standard also defines a composite data element. A composite data element is a set of simple data elements that represents a single named item. For example, in an X12 130 message, the composite data element C002, which is used to identify the actions to be performed on a piece of paperwork, comprises five simple data elements. Each simple data element is a code identifying one required action.

Data elements are grouped into functionally related units called data segments. An example of a data segment is the address of a geographic location, which includes the data elements for a city name, a state or province code, a postal code, and a country code. Data segments are defined in the X12 segment directory, which lists the data elements, in the required order, that make up each data segment.

Data segments are grouped, in turn, into transaction sets. A transaction set is the smallest meaningful set of information exchanged by trading partners. It represents a common business document, such as a purchase order or invoice. Most transaction sets are divided into three areas (called tables), each of which corresponds to a part of a printed document:

• Table 1, the Transaction Set Header, is the heading area, in which information pertinent to the entire transaction is placed.

• Table 2, the detail area, is composed of one or more data segments. For example, the line items for a purchase order are placed in the detail area.

• Table 3, the Transaction Set Trailer, is the summary area, which contains information such as the number of data segments used in a transaction set.

  Figure 1-1 Structure of a Transaction Set

  
   

Although a transaction set represents a printed document, it is not the information unit exchanged in an EDI transaction. Similar transaction sets are arranged into functional groups. For example, if Company A sends Company B two Requests for Quotations (RFQs) and five Purchase Orders (POs), the two RFQs are combined into one functional group, and the five POs are combined into another. All functional groups destined for a particular trading partner are then combined into an information unit called an EDI interchange. It is these interchanges that are transmitted between trading partners.

With the advent of readily-available high-speed networking, many EDI systems have moved to real-time EDI interchange, in which each transaction set is transmitted to a trading partner, if possible, as it arrives at the EDI system as a separate EDI interchange. In older systems, transaction sets are batched together and transmitted as one or more composite EDI interchanges. Because of the breadth and depth of EDI penetration into the e-commerce marketplace, you may encounter both situations with your trading partners.

The functional groups of an interchange are wrapped within an interchange header and trailer. The header provides control information:

• Sender and receiver of the interchange

• Date and time of the interchange

• Standard and version of the interchange

• Authorization and security information

• Unique control number by which the interchange can be tracked.

The trailer ends the interchange. It provides the total number of functional groups in the interchange, and it repeats the unique interchange control number identified in the header.

The following illustration shows how all of this is put together to form an X12 EDI message. EDIFACT and TRADACOMS messages use similar, though not identical, message structures.

Figure 1-2 X12 Message Structure

 

Differences with Other E-Commerce Standards

E-commerce standards other than EDI, such as RosettaNet and BizTalk, are designed to take advantage of state-of-the-are technology, but they are not completely free of restrictions.

Generally, these e-commerce standards require the following:

• Use of HTTP and/or HTTPS as the standard transport protocol

• Use of XML to package data

• Real-time access to trading partners

• Structure that supports delivery of one transaction per datagram

In addition, because these standards are relatively new, they are generally restricted to a small industry segment, with a relatively limited number of transaction messages available. At the same time, other e-commerce standards evolve relatively quickly, adding new functionality rapidly.

In contrast, EDI offers a wide variety of established standards, including the three most common: X12, EDIFACT, and TRADACOMS. These standards provide a wide variety of transaction types, addressing a broad variety of industry and government segments.

 

---

EDI Standards

Currently, there are three primary EDI standards: X12, EDIFACT, and TRADACOMS.

X12

The X12 standard is maintained by the ANSI Accredited Standards Committee (http://www.x12.org/). It is used primarily within the U.S. and North America. The U.S. Federal government has chartered the National Institute of Standards and Technology to maintain a Federal registry of all EDI implementation standards as they are used by the Federal government. For details, visit the following Web site: http://snad.ncsl.nist.gov/dartg/edi/fededi.html.

New releases of the X12 standard, offering technical updates and new EDI transactions, are published regularly.

EDIFACT

The EDIFACT standard is maintained by the United Nations/Economic Commission for Europe (UN/ECE) and the International Standards Organization (http://www.unece.org/trade/untdid). The EDIFACT standard is used primarily within Europe.

TRADACOMS

The TRADACOMS standard was developed and is maintained by the ANA (Article Numbering Association). It is used primarily in the U.K. retail industry.

 

---

BEA WebLogic EDI Integration Architecture

BEA provides optional EDI support through two components: the BEA WebLogic Adapter for Power.Enterprise! (delivered with BEA WebLogic Platform) and BEA EDI Connect for WebLogic Integration (purchased separately as Power.Enterprise!).

Note: The BEA WebLogic Adapter for Power.Enterprise! supports both the 3.0 and 3.1 versions of Power.Enterprise!.

Figure  1-3 illustrates how the BEA WebLogic Adapter for Power.Enterprise! and BEA EDI Connect for WebLogic Integration combine to put WebLogic Integration to work with your trading partners' EDI systems.

Figure 1-3 BEA EDI Integration Architecture

 

BEA WebLogic Adapter for Power.Enterprise!

The BEA WebLogic Adapter for Power.Enterprise! provides a gateway between WebLogic Integration and the Power.Enterprise! software. Using standard application integration events and services that you define with BEA WebLogic technology, BEA WebLogic Adapter for Power.Enterprise! allows you to:

• Exchange XML documents with your trading partner via Power.Enterprise!

• Receive documents from a trading partner via Power.Enterprise!

BEA EDI Connect for WebLogic Integration

BEA EDI Connect for WebLogic Integration (purchased separately) is a suite of three components:

• Power.Server!

• Power.Map!

• Power.Manager!

These components enable you to define your EDI-to-XML document maps, manage your trading partner relationships, and handle the transmission and receipt of EDI messages.