XML and EDI wrapping to improve external business communication

Ruben Heerdink University of Twente

Electrical Engineering, Mathematics and Computer Science r.heerdink@student.utwente.nl

Abstract With the growing use of XML by smaller en medium sized companies in business to business communication, there is a need for larger companies to create an interface to communicate with these smaller companies. Because of the fact that most large companies using EDI to communicate, these companies want to use a simple and cheap solution for this communication problem. This paper make clear that it is possible to wrap EDI messages to XML messages and vice versa using the given wrapping model.

Keywords XML, EDI, cXML, ebXML, xCBL, business to business communication, wrapping

1. INTRODUCTION In the last few years XML (eXtensible Mark-up Language) has become a widespread used mark-up language to support structured data representations. One example is the support of e-business in business to business relations. However, there are many companies which don’t use XML for their e-business. These companies still use EDI (Electronic Data Interchange) technology. This technology was developed in the 1970’s based on an US Army idea and widespread implemented in the 1980’s by big companies [PSC03]. At this stage of the development of XML most people understand that XML has a lot of advantages in comparison with EDI. The great possibility to integrate XML based information in many in many environments is one of these advantages [PSC03]. Another advantage is the flexibility of the XML language [WOS00]. Another big advantage is the human readable format of the XML language [MED03, PSC03]. As a result of this, XML data can be viewed in normal internet browsers. Thereby, XML can be used to do business transactions using your normal browser [CHE01]. Our goal is to provide an uniform solution to make it possible to wrap EDI messages to XML messages and vice versa using a wrapping tool. This research will have a theoretical conceptual model for this wrapping tool as result based on EDI and XML

theories described in later chapters. In section 2 this paper describes the related research done in this area. Section 3 describes the problem statement where this research is based on. After describing the problem statement this paper describes the EDI technology in section 4 and the XML technology in section 5. These two sections will also describe the different standards in these technologies. Section 6 describes difficulties by wrapping EDI to XML and vice versa and how these difficulties can be over won. Based on the information in section 6 this paper will outline in section 7 an uniform conceptual action plan for wrapping EDI messages to XML messages and vice versa. The conclusions and future work can be found in section 8 and section 9.

2. RELATED WORK There has not been done any significant research on the wrapping of EDI and XML. The reason for this is that all the research is focused on the development of XML and the integration of XML and EDI in one mark-up language such as XML/EDI [ECP03]. The development of the XML/EDI mark-up language is described in several papers [MED03, CHE01]. The purpose of this mark-up language is to hold all the EDI information in XML message attributes [ECP03]. This is not ideal because it will lead to very complex XML messages. At this moment all the XML/EDI research is done, but this mark-up language have not over won the use of EDI in business to business communication. Knowing this, we can conclude that the use of this mark-up language was not a success in the business environment. In the last few years, as said earlier, most research is done on XML mark-up languages especially for the business to business communication [CUG04, MED03, RIT01]. Examples of these languages are cXML, ebXML and xCBL. These XML based mark-up languages will be described in chapter 5.

3. PROBLEM STATEMENT While developing the XML standard and all related markup languages, the focus on EDI environments was minimal Although, as said before, there are many companies which are using this expensive EDI technology and don’t want to do an investment in the development of a specialized XML solution for their e-business. Because of this reason there is a need for wrapping EDI messages to XML and vice versa [PSC03, WOS00]. Alongside these big companies which are using EDI to do e-business, there are a lot of smaller companies that have not the money to use this technology. These companies can use XML based messages to communicate with other companies.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission. 3rd Twente Student Conference on IT , Enschede 20 June, 2005 Copyright 2005, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science

The advantages of XML in comparison with EDI lead to a need by big companies for conversion of EDI messages to XML messages and vice versa [KOR03]. By wrapping EDI messages

the companies are able to communicate with smaller companies using XML, while they can still communicate with other companies using EDI. At this stage there are different XML mark-up standards used in business to business communication. Examples are ebXML, which is developed specially for the use in business-to-business communication and the cXML standard, this one is used in business-to-customer communications. In this paper will answer some research questions formulated below:

• How is data represented in EDI and XML messages?

• Which XML mark-up standard is best suitable for the conversion of EDI messages?

Based on the gathered information answers can be found for the following formulated research questions:

• What are possible methods for data wrapping from EDI and XML messages and which are suitable?

• Is it possible to define a uniform action plan for wrapping EDI and XML messages and describe this in a theoretical model?

The goal of the whole research process is to design a conceptual model of an uniform solution to wrap EDI to XML messages and vice versa. This developed conceptual model can be used in later research to create a real wrapping tool with the goal to get a cheap solution for companies to communicate with other companies or customers using XML technology without system changes. The aim of the first part of my research is to explain all the ins and outs of XML and EDI. This is important to prove the necessity of designing the described wrapping tool. Result of this study are theoretical chapters which will ground the rest of the research.

4. EDI This chapter focuses on EDI, the history, standards and working of this manner of electronic communication between different companies. The last paragraph of this chapter describe the representation of data in EDI messages.

4.1 History of EDI communication As told earlier EDI was developed in the 1970’s, but the ideas for electronic data interchange between different companies raised earlier. During the Berlin Airlift in the 1950’s, for the first time in history goods and services began to move faster than paperwork. Based on this a couple of U.S. Army Air Corps supply officers began thinking about a system which could support the delivery of goods and services in the same time. Their solution was to move the paperwork electronically to close the gap, it took time to implement this but in the 1970’s Electronic Data Interchange for the transportation and logistic industry was reality. During the mid-1980’s the automotive, electronics, chemical, manufacturing, grocery and retail sectors jumped on board and X12, the cross-industry EDI standard, became the electronic way of doing electronic business throughout North America and other parts of the world [PSC03]. Besides the X12 standard, which later was approved by the ANSI standardization organizations, the European Union developed the TRADACOMS standard which mainly is used in Great Brittan. Based on these developments the UN decided to develop an EDI standard, called UN/EDIFACT, which was proposed to supersede the other two standards [MED03].

4.2 Different EDI standards EDI standards refer tot standardized ways of describing data items and of grouping and presenting these data items in the

form of messages or trade information. EDI standards are therefore not communications protocols, and not part of the Open Systems Interconnection (OSI) seven layer model for data communications, although it may be helpful to view them as perhaps the eighth layer of this model [PRE88]. The importance of EDI standards can be illustrated considering companies which use EDI to communicate with different other companies. If each company use their own developed way of EDI messaging, all the other companies have to use this mark-up also. By using a industry wide standard the communication can be far more simple, this is illustrated in figure 1.

A

C

B

D

A

C

B

DEDI Standard

Figure 1: Complexity of use of in-house standards [PRE88] EDI standards have been structured with respect to a reference model, consisting of the following components: [PRE88]

• Data Element. Data elements provide the vocabulary of EDI, and identify those individual fields or items of data designed of a specific purpose.

• Segment. A segment is a functionally related group of data elements or composite data elements.

• Message. A message is a group of segments brought together for a specific purpose and sent electronically.

• Functional groups. These refer to groups of messages of the same type.

These different components will be important by reaching the goal of this research: formulating a conceptual model for wrapping EDI to XML and vice versa.

4.3 General working of EDI communication Figure 2 shows the EDI communication concept; the sender of an EDI document assembles the right information which has to be sent to their trade partner. This information will be translated by a EDI Translation System which transforms the data into a standardized EDI document mark-up. After creating the EDI document, this document is transmitted either trough a Value Added Network (VAN) or directly to the receiver’s EDI Translation System. The received document, in standardized EDI mark-up, is translated into document which are usable by the receiver’s Business Application System [HAK04].

Sender Receiver

Direct communication

BusinessApplication

System

BusinessApplication

SystemEDITranslation

System

EDITranslation

System

3rd Party Network

Figure 2: EDI communication [HAK04]

When using VAN’s to communicate with other companies it is important to understand it’s pricing structure [CAN93]. These pricing structures make the use of EDI communication very expensive, because businesses have to pay for every character by example. The fact that EDI needs the use of special networks to communicate with other companies creates a need for a lower priced manner of B2B communication.

4.4 Data representation in EDI messages Electronic Data Interchange is intended to handle all aspects of business transactions. Because of this reason every EDI standard has standardized documents layouts for lots of business transactions. This paragraph describes the data representations in the two most used EDI standards: EDIFACT and X12. As described earlier every EDI message consists of one or more data elements, segments, messages and functional groups [PRE88]. In figure 3 an EDIFACT message layout is illustrated. By combining several layers of this illustration it is possible to build an EDIFACT message. The first two layers are EDI independent layers, these layers are providing the connection between two companies. The third layer describes the type of the message and what kind of content it holds. These descriptions are stored in the EDIFACT Directory Set.

Figure 3: Structure of a EDIFACT message The fourth layer holds information about the messages in the interchange. Because of the costs for sending these EDI messages it can be less expensive to send several different messages in one interchange. Each segment of a message has its own identifier which describes the data elements in this segment and each segment consists of one or more data elements. These tags are also stored in the EDIFACT Directory Set. An example of such an identifier is the ‘NAD’ identifier for a contact information segment. By example ‘NAD’ code C058 describes that this segment holds all the address information from the senders company. [SAM94] The data representation in X12 messages is very similar with the EDIFACT standard at content level, but there are some differences between the two standards. In figure 4 a X12 message structure is illustrated. This figure can be best compared with figure 3 by reading this figure from the right to the left and figure 3 from the top to the bottom. The main differences between the two standards are: [TAL93]

• EDIFACT uses composite data elements

• looping and nesting procedures are different

• 6 data elements types are defined in ANSI X12 while only three are defined in EDIFACT

• there is no provision in EDIFACT for optional fields

• EDIFACT allows for two levels of syntax. Nevertheless, the main functionality of both EDI standards is the same and these differences and may not lead to big problems.

Figure 4: Components of a X12 message

5. XML This chapter focuses on XML, the history, different standards and the working of XML communication. The end of this chapter focuses on the data representation in the different standards and conclude which XML standard is the best option to wrap EDI messages to.

5.1 History of XML communication In 1996, a team of experts led by Jon Bosak of Sun Microsystems and backed by the World Wide Web Consortium (W3C) began to work on a new standard to get a structured data representation. This new standard had to be simple, extensible and readable for both humans and computers. Finalized in February 1998, it was called XML (eXtensible Markup Language). Within the same year the commercial world stated to use XML [DAU00]. The design of XML is based on SGML (Standard Generalized Markup Language). SGML was standardized in 1986 and identifies document elements such as titles, tables and chapters. The XML standard maintains the SGML features of validation, structure and extensibility, while being simple to use, to learn and to implement. Important fact is that every developer can use his own tags [DAU00].

5.2 Different XML standards This paragraph describe some XML standards developed within the XML markup. These standards are developed to support business to business transactions, but with different purposes.

5.2.1 cXML cXML (Commerce XML) consists of an XML-based schema language and a protocol for online purchasing transactions. It targets business transactions that involve non-production Maintenance, Repair and Operating (MRO) goods and services. In a nutshell, cXML can be considered as a simplified XML and Internet-based version of EDI. cXML assumes the existence of intermediaries (E-commerce hubs) that act as trusted third parties between procurement systems and supplier systems. However, cXML does not prescribe intermediary architecture. [MED03] cXML supports two communication models: request-response and one-way. The request-response model provides for synchronous communication through HTTP. The one-way model provides for asynchronous communication through HTTP or other protocols. [MED03] At the content level cXML defines a set of XML DTDs (Document Type Definition) to describe procurement documents [MED03]. Every cXML document is divided in the two following different parts: [CUG04]

• Header. Contains authentication information and addressing.

• Request or Response data. Contains a specific request or response and the information to be passed.

The most commonly used types of cXML documents are the following: [CUG04]

• Catalogs

• PunchOut

• Purchase Orders Catalogs are documents which describe products and services which offered by a supplier. By retrieving these documents clients can use the information in their own system. PunchOut messages make it possible to interact directly with back-end systems using an internet marketplace for example. The purchase order messages are comparable with EDI messages: direct order communication with a supplier. The main difference is the flexibility of cXML by using purchase orders. [CUG04]

5.2.2 ebXML ebXML (Electronic Business XML) aims at defining a set of specifications for enabling B2B interactions among companies of any size. The basic part of the ebXML infrastructure is the repository. This repository stores important information about business and their products. The most important feature of the ebXML messaging service is that it does not rely on a specific transport protocol. [MED03] At the content layer, companies interact with other companies by using business documents. A business document is a set of information components that are interchanged as part of a business process [MED03]. Business documents are composed of three types of components:

• Core components. Contains information that’s are re-usable across industries.

• Domain components. Contains information from the domain library and is specific for industries or business.

• Business information objects. Contains information from the business information library and is specific for industries or business.

At the business process layer, ebXML defines a business process specification schema available in UML and XML versions. ebXML provides a set of common business process specifications that are shared by multiple industries. These specifications, stored in the business library, can be used by companies to build customized business processes and interactions. [MED03]

5.2.3 xCBL xCBL (XML Common Business Library) is a more ambitious effort that not only aims at data exchange but also at supporting E-business applications. Consequently xCBL offers a richer semantics than cXML by introducing an additional layer between XML and xCBL, the so-called schema language SOX. A schema language is a metagrammar for defining the syntactic structure and partial semantics of XML document types. This can be used to partially incorporate semantical features into a language like XML. [RIT01] xCBL consists of a set of XML core documents that are used to represent common interactions in business transactions. It does not target vertical industry domains, but it attempts to provide a generic framework for describing the content of core business documents. The main motivation for establishing core business documents is that some concepts are common to all business domains and thus can be expressed in a common format. Examples of such core documents are: purchase orders, invoices, date, time and currencies. [MED03]

5.3 Working of XML communication Figure 5 shows the XML communication concept. A sender collect the data which he wants to send. An XML Translation System puts this information in an XML file and sends it directly over the internet to the receiver. At the receivers side an XML Translation System will translate the XML document in normal data which can be used in their Business Application System. The concept is comparable with the communication concept of EDI messages. The most important difference is the communication over the internet. Communication over the internet is a lot cheaper then over special networks, this makes doing business using XML also a lot cheaper.

Sender Receiver

Internet

BusinessApplication

System

BusinessApplication

SystemXMLTranslation

System

XMLTranslation

System Figure 5: Communication by using XML

5.4 Data representation in XML messages XML documents are commonly stored in text files that ends with the extension .xml although this is not a requirement of XML. Any text editor can be used to create an XML document, many software packages also allow data to be saved as XML

documents [DEI01]. Figure 6 shows the content of an XML document.

Document

ElementElement

Attribute

Element

Attribute Attribute

Attribute

Attribute

ProcessingInstruction

Figure 6: Structure of a XML document

Most XML documents contain a processing instruction, this is a link to a file which defines the data in the XML document. By example: cXML has a lot of DTDs which describes the content and processing of the data in a cXML message. All XML documents must contain exactly one root element. The root element contains all other elements of the XML document [DEI01]. An element can contain one or more attributes, describing data or other content. The most important in the markup of XML documents is that every element of attribute is nested below the root element. The use of elements and attributes makes XML very flexible because these elements and attributes describe the content they are holding.

5.5 Best XML standard to wrap to To get a clear wrapping tool which is simple and cheap it is important to wrap EDI messages to one XML format. At this manner every company has to implement only one XML reader to communicate with business which are using EDI. Based on the information about the different XML standards developed for use in B2B environments, cXML is the most attractive one to wrap to. Reasons are the simple markup and the flexible way content can be used. By developing the conceptual model for EDI to XML wrapping and vice versa I will only look at cXML.

6. WRAPPING DIFFICULTIES This chapter describe how the wrapping tool can wrap EDI to XML and vice versa based on identifiers also know as field names. These identifiers describe the content of a field that holds by example business contact information.

6.1 Identifier mapping To make wrapping possible it must be sure that there are corresponding field identifiers in EDI and cXML. Based on some language dictionary files I have created a table with some

examples of possible mappings between EDI and cXML. This information can be found in table 1.

Table 1. Mapping EDI-cXML field names

EDI cXML

NAD ShipTo

NAD BillTo

CTA Contact

FTX Comments

NAD SupplierOrderInfo

As you can see there are different cXML identifiers which have the same EDI identifier. Reason for this is the completely different idea behind both message types. The three ‘NAD’ identifiers describe the same kind of information: contact information. In EDI, the translator looks where an identifier is placed, based on this it can see which kind of contact information it must be.

6.2 Identifier storage All the identifiers are stored in a central database. This database hold all the links between EDI identifiers and cXML field names. By querying the database using an EDI identifier it will respond with all possible mappings. This response is directly the difficulty in the storage of the identifiers: how does the system know which cXML identifier corresponds with the EDI identifier. As seen in table 1, an address field in EDI has always the same identifier. There is a way to solve this problem, the solution is to store also the EDI header in the database. Every EDI message holds its own message type header, so it is possible to use this header. Using this header it is clear which cXML field name correspond to by example an EDI address field. Table 2 shows a row from the mapping database. The first column in this table is the database unique row identifier. The second column is an EDI field identifier and the third column describe the accompanying message type. Column four and five describe also the field identifier and accompanying message type, but in case of a cXML message.

Table 2. Example row from database

#1 NAD C058 ShipTo Order

The solution explained above will work also in the other direction. By storing the cXML DTD type in the database it is possible to retrieve the right EDI identifier.

7. WRAPPING STEP BY STEP This chapter describes how an EDI message can be wrapped to an XML message. This wrapping process from EDI messages to XML messages is visualized in figure 7 and described below. The wrapping of XML messages to EDI messages is nearly comparable. All information is described as attributes in cXML and tags in EDI. By using this information it is possible to wrap to both sides. Because of the nearly comparable wrapping procedure I will only describe the wrapping of EDI to XML. This text is written from the wrapping tool point of view.

EDI data dictionary

EDI message XML message

Wrap tool

cXML DTD database

1

54

8

7

63

2EDI header

EDI field names Message

type

cXML DTD

Mapping database

EDI field names cXML field

names

Step 7 – Receiving cXML DTD

Figure 7: Working of the wrapping tool

Step 1 – Sending EDI message A company that wants to send a message to another company first creates their own EDI message. This happens in the same way as described in paragraph 4.3. The data that has to be sent will be translated by a EDI Translation System and after translation it must be sent to the wrapping tool instead of sending it directly to another company.

Step 2 – Sending EDI header When the EDI message arrives at the wrapping tool, this tool will read the message and pick up the header of the message. This header content will be sent to the EDI data dictionary.

Step 3 – Receiving EDI field names The EDI data dictionary receives the header content from the wrapping tool and searches in the dictionary for the field names which corresponds with this header. All the field names corresponding to the header will be sent back to the wrapping tool.

Step 4 – Sending EDI field names The wrapping tool receives all the field names which describe the content of the received EDI message. Directly after receiving these field names the wrapping tool sends these field names with the EDI header to a mapping database where all EDI field names are mapped to a corresponding cXML attribute name.

Step 5 – Receiving cXML field names The database returns the cXML field names and message type corresponding to the EDI field names which are used in the received EDI message. In paragraph 6.2 is described how these field names are stored in the database.

Step 6 – Sending cXML message type Based on the received cXML field names and the message type the wrapping tool know which cXML message type must be sent to represent the EDI message data in XML format. This message type is sent to the cXML DTD database.

The cXML DTD database receives the message type. With this message type the DTD database can return an XML DTD which describes exactly the content of a cXML message.

Step 8 – Sending cXML message With the cXML DTD it is possible for the wrapping tool to translate the EDI message in a cXML message. Based ont the information form step 3 and step 7 the wrapping tool can copy the content from the EDI message to the cXML message.

8. CONCLUSION The use of XML in business-to-business makes electronic business communication also available for smaller companies. As described in the first chapters, big companies are still using EDI to communicate with suppliers and clients. They will not investigate in new XML implementations to support the new sort of business-to-business communication. This makes it hard for smaller companies to do electronic business with those bigger companies. Based on the research done in this paper there can be concluded that it is possible for big companies to communicate with smaller companies by using the old EDI interfaces. The conceptual wrapping model, proposed in this paper, can wrap EDI messages to cXML and vice versa. Also, based on this conceptual model, smaller companies can send electronic orders to big companies by using cXML based messages. Another big advantage of this model is that cXML supports electronic business via the internet. By using the wrapping tool it is possible to receive orders done on the internet in EDI messages.

9. FUTURE RESEARCH This paper describes a theoretical conceptual model of a wrapping tool which can wrap EDI messages to XML messages and vice versa. This model is the first model which describes the wrapping tool and in a very early stage of a possible development process. In the future there has to be done much more research on the mapping of EDI tags and cXML attribute names. This mapping is one of the most important factors in the development of a wrapping tool.

Although, based on this paper it must be possible to implement a simple wrapper which can do some wrapping on simple EDI tags and cXML attribute names

REFERENCES [CAN93] Cannon, E. EDI GUIDE: A step by step

approach,Van Nostrand Reinhold, New York, 1993 [CHE01] Chen, D. and Chung, J.

Internet Based Electronic Business Framework Applications and Business to Business Standards ISEC 2001, LNCS 2040, pp. 158-169, 2001

[CUG04] cXML working group cXML User Guide http://xml.cxml.org/schemas/cXML/1.1.010/cXMLUsersGuide.pdf

[DAU00] Daum, B. and Scheller, M. Success with Electronic Business, Pearson Education, London, 2000

[DEI01] Deitel, H. M. et al. XML How to program, Prentice hall, New Jersey, 2001

[ECP03] Electronic Commerce Promotion Council of Japan Internet EDI (XML/EDI) introduction guidebook

[HAK04] Hakvoort, R. ebXML and its impact on conventional Business Information Systems 1st Twente Student Conference on IT, Enschede 14 June 2004

[KOR03] Korhonen, R. and Salminen, A. Visualization of EDI messages: Facing the problems in the use of XML

Proceedings of the 5th international conference on Electronic commerce, 465-472, 2003.

[MED03] Medjahed, B. et al. Business-to-business interactions: issues and enabling technologies The VLDB Journal (2003) 12: 59–85.

[PRE88] Preston, M. What is EDI, NCC Publications, Manchester, 1988.

[PSC03] PSC Group, LLC.. Is XML More Than EDI With Different Letters? www.psclistens.com

[RIT01] Rittgen, P. Process-oriented EDI The 9th European Conference on Information Systems Bled, Slovenia, June 27-29, 2001

[SAM94] van der Vlist, P. et al. EDI in de transportsector, Samsom Bedrijfsinformatie, Alphen aan den Rijn, 1994

[TAL93] Tallim, P. and Zeeman, J. Electronic Data Interchange: An Overview of EDI Standards for Libraries UDT Series on Data Communication Technologies and Standards for Libraries

[WOS00] Wöß, W. XML and Meta Data Based EDI for Small Enterprises DEXA 2000, LNCS 1873, pp. 357−365, 2000.