General Anodyne Enterprises, Ltd. uses a legacy EDI system to record and transmit corporate data, and they now wish to use XML so they can communicate and work with data more easily across the enterprise. Unfortunately, they use a variant of the EDIFACT NAD (Name and Address) C059 composite element, so their EDI does not comply with the published standard, which is shown in the following table from the Stylus Studio web site.
As seen here, the C059 composite element contains four instances of the 3042 element, each of which is used to record part of an address. Notice that the first 3042 element is required (shown as M for "mandatory" in the table above).
Rendered as XML, a typical address compliant with the EDIFACT standard for NAD C059 composite elements might look like this:
Based on the standard, the following address is also valid EDI because it contains the required first instance (shown as
However, General Anodyne Enterprises, Ltd. has decided to omit the first two fields from their address scheme, as they typically refer to locations using the facility and building names on their plants' campuses. An example follows:
(empty) (empty) WEST ORCHARD FACILITY IMPLEMENTS AND DEVICES DIVISION
If this EDI fragment could be converted to XML, the address might be rendered as:
Of course, this is not conformant with the EDIFACT standard for NAD C059 composite elements as it is missing the mandatory 3042 element,
DataDirect XML Converters™ provides a mechanism you can use to instruct the XML Converters engine about the differences in the EDI it is trying to convert to XML.
In our example, we want to let the XML Converters engine know that the first 3042 element is optional. We do this by constructing an XML document, using an XML editor like Stylus Studio 2007 XML Enterprise Suite, for example.
In this document, which contains only the composite element we are interested in redefining (C059), we retain the four 3042 elements, but the
mandatory attribute for the first of them has been set to
"false", because we do not want it to be required.
To understand how to compose this XML, we used the
CustomEDI-extend.xsd XML Schema provided with the DataDirect XML Converters™. Of course, we validated our XML against this XML Schema to be sure that it was valid.
Once we have a valid XML document describing General Anodyne Enterprises, Ltd.'s extension to the EDIFACT NAD segment standard, we can invoke the XML Converter for EDI. In addition to the EDI file we wish to convert to XML, we also specify the URL for our XML document. The XML Converter engine needs this document in order to understand how General Anodyne Enterprises, Ltd.'s NAD C059 composite element differs from that defined in the EDI standard. All other aspects of the EDIFACT standard remain intact and are enforced by the XML Converters engine.
So, to convert anodyne_edi.edi to XML, we invoke the XML Converter for EDI like this in Java:
And like this in C#:
In both examples, the
user property is used to specify the URL of our XML document.
Following is a sample of the EDI file we want to convert to XML using the DataDirect XML Converter for EDI, with the NAD segment that represents the variance from the EDIFACT standard highlighted:
As you can see in the following illustration that shows the converted EDI file, our XML document contains only <NAD0503> and <NAD0504> elements, and not the <NAD0501> otherwise required by the EDIFACT standard for NAD C059 composite elements.
Using DataDirect XML Converters™ custom EDI message type tools, you can easily manage proprietary EDI formats and convert them to XML.
Tired of reading? Watch a video that shows how easy it is to use DataDirect XML Converters™ in a .NET application.