EDI is a method of transmitting business information over a network between business associates who agree to follow approved national or industry standards in translating and exchanging information. WebSphere Partner Gateway provides de-enveloping, transformation, and enveloping for the following EDI standards:
The following sections provide a brief overview of EDI interchanges that conform to the X12, EDIFACT, and UCS standards and of the transactions and groups that are contained within the interchanges. Also described are how XML and ROD documents and EDI interchanges are transformed.
An EDI interchange contains one or more business transactions. In X12 and related standards, a business transaction is called a transaction set. In EDIFACT and related standards, a business transaction is called a message. This document generally uses the term transaction or business transaction to refer to an X12 or UCS transaction set or an EDIFACT message.
EDI interchanges are composed of segments which in turn contain data elements. Data elements represent things such as a name, quantity, date, or time. A segment is a group of related data elements. Segments are identified by a segment name or segment tag, which appears at the beginning of the segment. (Data elements are not identified by name but are delimited by special separator characters reserved for this purpose.)
In some cases, it is useful to distinguish the detail or data segments in a transaction from other segments that are used for administrative purposes. The administrative segments are called control segments in X12 and service segments in EDIFACT. The envelope segments that delimit the boundaries of an EDI interchange are one example of these control or service segments.
EDI interchanges can contain three levels of segments. At each level, there is a header segment at the beginning and a trailer segment at the end.
An interchange always has an interchange header segment and an interchange trailer segment.
An interchange can contain one or more groups. A group in turn contains one or more related transactions. The group level is optional in EDIFACT but is required in X12 and related standards. When groups are present, there is a group header and a group trailer segment for each group.
A group (or an interchange, where groups are not present) contains one or more transactions. Each transaction has a transaction set header and a transaction set trailer.
A transaction represents a business document, such as a purchase order. The contents of the business document are represented by the detail segments between the transaction set header segment and the transaction set trailer segment.
Each EDI standard provides its own method for displaying the data within an interchange. The following table lists the segments for each of the three supported EDI standards.
Standard segment | X12 | UCS | EDIFACT |
---|---|---|---|
Interchange start | ISA | BG | UNB |
Interchange end | IEA | EG | UNZ |
Group start | GS | GS | UNG |
Group end | GE | GE | UNE |
Transaction start | ST | ST | UNH |
Transaction end | SE | SE | UNT |
Figure 22 shows an example of an X12 interchange and the segments that make up the interchange.
The Data Interchange Services client mapping specialist creates transformation maps that describe how to change a document in one format to a document in a different format. You can, for example, have a transformation map that changes an X12 transaction into an EDIFACT message. You can also transform an EDI transaction into an XML document or a record-oriented data document.
The transformation map can also create multiple documents from a single document. This type of map makes use of map chaining, which produces multiple outputs from a single translation. In map chaining, after a source document has been successfully translated into a target document, a subsequent map is used to translate the source document again to produce another target document. This can be repeated as many times as needed to produce as many documents as needed.
In addition to transformation maps, you can use functional acknowledgment maps and validation maps. Functional acknowledgment maps provide instructions on how to produce a functional acknowledgment, which notifies the sender of an EDI document that the document has arrived. Several EDI Standard functional acknowledgment maps are installed when WebSphere Partner Gateway is installed. See Functional acknowledgments for a list of these maps. Additional functional acknowledgment maps can be created by the Data Interchange Services client mapping specialist. WebSphere Partner Gateway generates a functional acknowledgement when an EDI transaction is validated and the EDI transaction has a functional acknowledgement map associated with it. The source document must be an EDI document.
WebSphere Partner Gateway provides a standard level of validation on the EDI document. If a functional acknowledgment is going to be generated, results from validation of an EDI document are saved. Validation maps are created to provide additional validation on an EDI document. The generation of a functional acknowledgment uses the functional acknowledgment map and the results from the validation of the EDI document. The functional acknowledgment map contains mapping commands that indicate how to use the validation results to create a specific functional acknowledgment. If a document is accepted for translation by the validation process, the appropriate data transformation map is used to translate the source document.