EDI to XML: A Practical Approach
Accessing or creating EDI messages as XML
By: Carlo Innocenti
Sep. 11, 2008 11:45 AM
A Practical Approach
One simple yet powerful way to make most existing XQuery and XSLT engines able to process EDI as XML is to make the processor able to access non-XML data through custom URI resolvers. What is a URI resolver? When an application tries to access a resource referenced as, for example, file:///c:/myFolder/myDocument.xml or http://myServer/myFolder/myDocument.xml, what happens under the cover is that the standard URI resolver understands that “file:” identifies a resource on your local file system and retrieves the file myDocument.xml in the myFolder directory, or “http:” identifies a request to access a resource through the HTTP protocol and it connects to myServer to GET myfolder/myDocument.xml.
That mechanism is extensible. You can, for example, create and use a custom URI resolver that knows how to deal with a specific URI scheme. For example, if your application references a URI, such as converter:EDI?file:///c:/myMessage.edi, the custom URI resolver will know that what the application is requesting is to retrieve an XML interpretation of the EDI message myMessage.edi.
That’s quite a powerful mechanism; applications can leverage it to do what we described above: give XQuery or XSLT processors the ability to handle both XML and non-XML data transparently as if everything was in fact XML.
For example, an XQuery could be in charge of retrieving all the book orders received as part of an incoming EDI message from a business partner and return them in an XML format required by your application. Assume the EDI incoming message looks like Listing 1 and that the XQuery processing the EDI message looks like Listing 2. The result of such XQuery would be something like Listing 3.
As you can see, the XQuery doesn’t know about the fact that you’re querying an EDI message to generate XML. From the XQuery point of view, you’re dealing strictly with XML.
A similar extension can apply on the output side. Suppose I want to answer my business partner using an EDI message (since that’s all that partner can process); of course I’d like to be able to just deal with the generation of the proper response in XML terms, and then assume that what the business partner gets is actually EDI.
You can do that, for example, by extending the concept of output method. Both XQuery and XSLT already support the ability to instruct the processor to serialize the result of their processing not only as XML, but also as HTML, XHTML, or event text. What if you were able to tell your XQuery processor: “serialize the result as EDI?” Your application would be able to focus on the fact that it’s dealing with querying and creating XML, but its result would in fact be EDI.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week