Converting Custom EDI Message Types to XML with DataDirect XML Converters™
Stylus Studio® provides access to DataDirect XML Converters™ through the Stylus Studio® desktop. DataDirect XML Converters™ allow you to convert numerous file formats — EDI, CSV, dBase, to name just a few of the dozens of legacy file formats supported by DataDirect XML Converters™ — to XML and back. Great, if you're working with files that conform to documented EDI standards like EDIFACT, IATA, and X12. But what if your organization uses a customized EDI, that is, an extension (or restriction) to a standard EDI message type? Stylus Studio® has the answer.
Now, using Stylus Studio® and DataDirect XML Converters™, you can convert custom EDI message types to XML (and back!) for these EDI dialects:
Custom message types must be either EDIFACT- or X12-style messages, since the auto-detection feature of the DataDirect XML Converters™ engine depends on the initial segments of those dialects as well as on the general syntax of the document. You cannot, for example, create an HL7 EDI message, since HL7 is structurally different (it allows messages to span documents, it allows segments to be split and continued, it has a sub-field structure, and so on).
The process for converting an EDI file that includes a custom EDI message type to XML has the following steps:
In order to do this, you need to structure the document using one of two XML Schemas included in your Stylus Studio® installation,
For example, if you are converting
(click to enlarge)
Or, you can achieve the same result using Stylus Studio's converter: URL, like this:
See Example: Converting a Custom EDI Message Type with DataDirect XML Converters™ to see how to convert a custom EDI file to XML.
Stylus Studio includes two XML Schemas used to validate the XML document you use to define your custom EDI message type:
The ROOT Element
The root element of the custom EDI message type XML document is <edi>. Within the root element, you can define each of the following components: <message>, <segment>, <composite>, and <element>. When one component references another, it will always be in the form of a <use-...> element. For example, a <message> will have one or more <use-segment> elements within it, which will refer to the <segment>s defined elsewhere in the file.
Each EDI message is composed of one or more <message> elements (or messages). Within each message there are groups of segments, which can be nested, so each group can contain other groups, segments, or a mix. Within each segment there can be a mix of composite fields and elements, and composite fields are also made up of elements.
The <message> element will have a mandatory attribute, @name, which is the name of the EDI message. This must match what is found in the file in a UNH/UIH segment for EDIFACT, or in an ST segment for X12. Something like "ORDERS" or "811", for example.
The <message> element should also have a @title attribute, which sets the human-readable title. It can also have a child <description> element, which can contain an arbitrarily long description.
Next should be one or more <group> or <use-segment> elements. They can be mixed, although order does matter. The <use-segment> elements have three attributes:
The Group Element
The <group> element can contain one or more <group> and/or <use-segment> elements. The <group> element allows also an optional <description> element for documentation purposes.
Group elements also have two attributes, @count and @mandatory, which behave as described in The Message Element.
The Segement Element
The <segment> element, like messages, has @name and @title attributes. The name should be the name of the segment as it will appear in the EDI document, such as "NAD" or "F6X" or "ID1", for example. It also supports the optional <description> element.
Each <segment> contains one or more elements – either simple elements referred to by the <use-element> construct, or component elements referred to by the <use-composite> construct. The order is very significant. Both <use-element> and <use-composite> take two attributes, @name and @mandatory:
A <composite> element is like a
Composite names usually look like C???, E??? or S???, with the ??? being a three-digit number. While this is true for both X12 and EDIFACT, it is neither a rule nor a requirement.
An <element> describes the most basic component of an EDI message. Element names are typically numbers, although X12 has a number of elements in which the first character is the letter 'I' followed by a two-digit number. The name is in the mandatory @name attribute. The @title attribute is a human-readable description of the element's purpose.
The mandatory @type attribute describes the datatype. EDIFACT and X12 both use:
X12 expands on the list of types with these additional types:
The mandatory @maxLength attribute indicates how many characters at most can be in the value. The optional @minLength sets the minimum length. The default for the latter is "0".
Optionally, each element can have its values further constrained by an enumerated list. That list is denoted by a series of <item> elements within the <element>.
Each <item> has a @key attribute which holds the value that would appear in the EDI, and the text content of the <item> element is the description of that value.
For More Information
See Example: Creating a Custom EDI Message Type with DataDirect XML Converters™ to see how easy it is to create a custom EDI message type with DataDirect XML Converters™.
Tired of reading? Watch a video that shows how easy it is to use DataDirect XML Converters™ in a .NET application.
PURCHASE STYLUS STUDIO ONLINE TODAY!!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Learn XQuery in 10 Minutes!
Say goodbye to 10-minute abs, and say Hello to "Learn XQuery in Ten Minutes!", the world's fastest and easiest XQuery primer, now available for free!