Webservices for Electronic Data Interchange
WS-EDI is the ability to treat existing electronic data interchange (EDI) technology as webservices. The philosophy behind WS-EDI is simple: Organizations should spend their information technology budgets on expanding their capabilities, leveraging their existing investments rather than replacing systems that work.
The primary purpose of WS-EDI is to enable programmers to handle EDI data using common XML parsers. WS-EDI provides a representation of EDI messages in XML. There are several levels of representation to accommodate the various parsing and handling requirements.
WS-EDI provides a one-to-one representation of EDI in XML. Before we explain WS-EDI, we will provide an overview of EDI. Readers who are familiar with EDI should feel free to move ahead to the next section.
There is a general and a specific meaning to the term EDI. The general meaning of EDI is any formatted exchange of text data between organizations. This general meaning can include any proprietary fixed-width or delimited format. The specific meaning of EDI is the standard data format specified by the ANSI X12 committee or UN EDIFACT committee.
WS-EDI is focused on the specific meaning of EDI. That is, WS-EDI provides a one-to-one representation of X12 and EDIFACT documents in XML.
Segments
EDI documents are comprised of a series of records called segments. Every segment begins with a segment identifier, also called a segment code. The segments are delimited. A special character or characters designate where one segment ends and another begins. Usually segment delimiters include a line return, so we usually think of a segment as a line of an EDI document.
The following X12 EDI document fragment contains eight (8) segments. Each segment is sepearted by a tilda (~) character and a line return. The first characters of each segment is the segment code. So in this example, the first segment is an ST segment, the second is a BEG segment, the third, fourth and fifth segments are REF segments, and so on.
... ST*850*397822~ BEG*00*RE*1234**980208~ REF*AH*M109~ REF*DP*641~ REF*IA*000100685~ DTM*010*970918~ N1*BY*92*1287~ N1*ST*92*87447~ ...
Segment codes are usually two or three letters long. They always begin with a letter but may contain numbers, as in “DTM” and “N1″.
Elements
A segment is comprised of a series of elements. These elements are delimited by a special character called a element seperator. In the X12 EDI document fragment above, the element seperator is the asterisk (*) character. The ST, REF and DTM segments each have two elements, the N1 segments have three elements each and the BEG segment has four elements.
The segment code specifies what the elements in the segment represent. For instance, the first element of an DTM segment is date/time qualifier and the second element is the date. The first element of a REF segment is the reference identification qualifier and the second element is the reference identifier. We refer to elements by their sequence within the segment. For example, we refer to the first element within a REF segment as element REF01, the second as REF02, and so forth.
Elements have codes as well to enable reuse in segments. The first element of an X12 DTM segment is X12 element 374 and the second is element 373. In segment that includes a date will use the 373 element. So we would say that DTM01 is an element 374 and DTM02 is an element 373.
Many elements in EDI rely on two-letter or three-letter codes to represent their values. This approach is especially common for qualifiers, like the date/time qualifier and the reference identification qualifier. For instance, in the example above, the value 010 for a date/time qualifier means “Requested Ship”. A value of 080 would mean “Purchase Order Received”, 012 would mean “Terms Discount Due”, and so forth. Within X12, there are more than 1,100 different values with assigned meanings for the date/time qualifier alone. The reference identification qualifier has a completely different set of meanings assigned to its values.
Composites
A segment may also contain a composite element. A composite element is simply an element of elements. Composite elements are especially common in EDIFACT.
Composite elements are delimited exactly like elements. The elements within a composite element are delimited by another special character called a composite seperator.
The following EDIFACT segment contains two composite elements. The segment seperator is the apostrophe (’) character, the element seperator is the plus (+) character, and the composite seperator is the colon (:) character.
EQD+RR+X:::+1:::X+2+1+5'
The first element, EQD01, has a value of “RR”. EQD02 has a value of “X:::”, EQD03 is “1:::X”, EQD04 is “2″, EQD05 is “1″ and EQD06 is “5″. EQD02 and EQD03 are both composite elements. We know this because they contain the composite seperator (:).
EQD02 is a composite element that contains four elements. The first element within the EQD02 composite element has value “X”. The other three values are blank.
EQD03 has a value of “1:::X”, which is also a composite element. The first element within the composite has value “1″, the next two elements are blank, and the fourth element has value “X”.
Advanced structures
EDI experts may be wondering why we have not mentioned loops, interchanges and functional groups. These advanced EDI structures are implied within the EDI document, that is, they are interpreted from the segments within EDI document. The loops, interchanges and functional groups do not actually exist physically in the document. The EDI document is physically only a list of segments. As such, the minimum necessary XML representation of an EDI document does not need loops, interchanges and functional groups.
Not to fear, however. WS-EDI does provide these advanced structures. We will discuss them in the Level 2 and Level 4 representations.
This page has the following sub pages.
Leave a Reply
You must be logged in to post a comment.