DESIGN AND DEVELOPMENT OF A VISUAL EDIFACT/XML TRANSLATOR ARCHITECTURE

Transcription

1 DESIGN AND DEVELOPMENT OF A VISUAL EDIFACT/XML TRANSLATOR ARCHITECTURE Mauro R. Nunes [email protected] September, 2000 (updated information at Abstract This whitepaper purposes an EDI translator architecture, which is the core of an EDI system. The EDI concept is introduced and also the current standards are analysed with an attempt to forecast future trends. After studying existing translator architectures the Visual EDIFACT/XML TRAnslator Architecture (VEXTRA) is designed and tested. 1 Introduction Nowadays organisations are facing new challenges that derive from changes in the competitive situation, information technology and value systems (Wigand et al., 1997). The changes in the competitive situation are mainly due to the globalisation of markets and to customer driven business which demands higher quality and lower prices. Wigand et al. (1997) also explains that the change in the information technology carries an implicit innovative potential at the product and process level for business and society. This innovation enables important features like co-operative work, integration or globalisation. Because of these drivers of change, organisations need new organisational structures (business strategies) in order to react effectively and efficiently to new business opportunities and threats (Bradley, 1993). Different business strategies are possible and frequently include seeking a vertical integration in the industry or a joint partnership with external entities (like suppliers or distributors). They go beyond the traditional organisational structures and boundaries, transforming into boundary-less organisations. In fact, the traditional value chains are evolving into electronic inter-organisational value chains that are only possible due to the new communication technologies (Benjamin & Wigand, 1995). DeSanctis et al. (1999) also see technology as the key feature to enable inter-dependent organisations that rely on technology to build the symbiotic relationships. To implement the electronic value chain, business communication must be reliable, fast and integrated. But, this is difficult to achieve due to the frequent incompatibilities between the different hardware and software in the organisations, a problem known as interoperability (Bradley, 1993). Therefore, exchanging standard electronic messages between different business units or partners is a possible solution for the communication problem. This is the essence of Electronic Data Interchange (EDI) that is a set of syntactic and semantic rules, based on standards, which enable the electronic communication between two entities. 1

2 1 EDI There are many definitions of EDI but the definition adopted by the International Data Exchange Association is one of the most widely accepted definitions of EDI: EDI is the transfer of structured data, by agreed message standards, from computer to computer, by electronic means. EDI is normally used in a context of business to business (B2B) transactions where trading partners agree on a protocol of co-operation in order to maximise business efficiency. Nevertheless, it is also possible to have EDI in a context of business to customer (B2C) where a customer sends an order that is automatically added to the ordering system. (Segev et al., 1997) Generically an EDI system is composed by and EDI Translator and an EDI Messenger (Figure 1 illustrates this system). The EDI Translator is responsible for encoding a message in a particular format (under some message standard) and has to retrieve all the required information from the client system either through a flat file (text file) or an interface database. The EDI Messenger is only responsible for sending an EDI file to a destination EDI partner through an electronic communication channel. Information System A ODBC data EDI Messenger Communication Channel Flat file data EDI Translator EDI File Figure 1 Generic EDI System Because the EDI process is bi-directional the EDI partner will have a similar system, which in some cases can be only one application responsible for translating and sending messages. EDI has a wide range of applications that can vary considerably between industrial sectors. However, as described in VANGUARD (1989b), these applications can be grouped by the type of provided service and industry: Transaction services in retail, manufacturing, travel, insurance and banking. Information services in finance. 2

3 1.1 Benefits In general, the main benefits of an EDI system are: Reduce paper work and administrative costs Because human intervention in the process is reduced. Increase efficiency Redundant process steps are eliminated and critical tasks can be automated. Improve quality of service Humans are more susceptible to input errors in the system. Transaction services have been one of the leading factors for the need of EDI systems. This is mainly due to the intrinsic characteristics of EDI in terms of system integration, speed and reliability of communications. 1.2 Constraints Despite all the benefits obtained from the use of EDI in a business there are some constraints that have slowed the wide spread of EDI systems. Some of these constraints are: Potential customer scepticism Customers have to be convinced of the specific benefits to their business in order to justify the implementation costs of an EDI system. Possible change in business structures or practices Normally an EDI system will require the business practices to be re-organised to reduce inefficiencies. But, sometimes the problem has repercussions that reach the business structure. This is often a barrier to the introduction of EDI, because companies are not willing to change. Technofear There is a general lack of familiarity with IT in companies and a basic apprehension regarding new technology. Managers often follow a strategy of wait and see if the technology is really being used in the business sector. Decision-making structures Within large companies there is often a lack of authority for decisions about EDI. Managers of Information Technology (IT) departments are frequently not necessarily in a position to grasp the strategic significance of EDI. On the other hand, senior management may have a limited understanding of how EDI operates in a technical sense and delegate that decision to the IT specialist. Implementation costs The implementation costs of an EDI project can be so high that only big companies can afford it. Standards uncertainty The multiplicity of standards and the lack of a truly world-wide accepted standard has slowed down the decision for an EDI solution. 1.3 EDI Solutions Like in any information systems project if a company wants to start using EDI it has two solutions (Segev et al., 1997): MAKE IT Using the company s know-how and resources to design and develop the EDI solution. Despite of the initial reduced costs of this solution (because it uses resources already in the company) it is the most risky, due to the uncertainty of the outcome of such a project. Normally, it is an approach only for major companies that want a solution tailored to its needs. BUY IT This is the most used solution, because despite of the higher initial cost the company is buying a software package already fully tested, implemented in the market and with maintenance contract. However, there is always the danger that the package is not suitable for the company s specific needs and has to be adapted. 3

4 A new solution that has been becoming more popular is the RENT IT, which is considered to be a more cautious approach to EDI mainly because one of the main advantages is if the system in not suitable, the company can always change to another product. The other main advantages of the RENT IT solution are: Low initial and set-up cost - because normally the system is based in the EDI supplier and only a link is created to the client or even if a full implementation is required in the premises of the client. traffic charging The client company can have several pricing options to choose from normally proportional to the number of messages that the system exchanges. Low maintenance cost The maintenance service is done by the EDI supplier that is responsible to ensure a continuos service with backup systems. With the technological advances of the Internet some EDI suppliers (like Peregrine 1 ) are offering RENT IT products totally based on the Internet in order to maximise availability to EDI clients (easy to set up an Internet connection) and reduce the linking costs (low cost connections). 2 EDI Standards As stated in the definition of EDI, standards must be used to ensure the communication between two trading partners. EDI standards have been evolving in a constant adaptation to the always-changing user requirements. It is difficult to exactly date chronologically the history of the standards mainly because they were normally set by a group of companies (user groups) from a specific industry and in different countries. Therefore, the best way to describe the EDI standards history is to start with the existing standards and then explain their origins. These are (VANGUARD, 1989): 2.1 TRADACOMS The Article Number Association (ANA) in response to UK user demand developed Trading Data Communications. ANA is controlled and funded by its members, whose principal role is the administration of the international article numbering and bar coding in the UK. ANA established a Working Party to address the issue of defining one set of data communications standards that could be used in a wide range of trade applications. This was the TRADACOMS project and it involved designing widely acceptable electronic formats to common business transactions. The TRADACOMS Working Party decided to develop an UK specific message standard because they faced a multiplicity of industry specific needs, pressure for a multi-industry message standard and that the distinctive features of each country economy were too complex to handle. Nevertheless, they worked with the national trade facilitation body Simpler Trade Procedures Board (SITPRO) in order to ensure that the message standard was based on an established and internationally recognised and supported system of syntax rules. In November 1982 was published Trading Data Communications: Standards for Electronic Data Exchange and it represented a very significant milestone in the development of EDI in the UK. TRADACOMS is today the most widely used standard in this country. 2.2 ANSI X12 EDI This is a standard developed in the United States by the Accredited Standards Committee X12 of the American National Standards Institute (ANSI) with the objective of unifying the 1 4

5 different user groups standards that already existed. This objective was served by the development of a national generic standard that was called simply EDI. In 1985, ANSI a UN/ECE (UN Economic Commission for Europe) commission which reviewed the possibilities of trying to establish a universal standard. In July 1988, ANSI X12 questioned its members on the transition to a universal standard (EDIFACT), the answer was positive and the US EDI user community is convinced of the desirability of using generic standards with the widest applicability. ANSI X12 has already reorganised its structure to incorporate EDIFACT representation and policy setting. 2.3 ODETTE Organisation for Data Exchange by Tele Transmission in Europe is an organisation of European automotive industry companies that have developed their own standards. These standards were implemented across Europe with a good acceptability. But, ODETTE is firmly committed to the UN/EDIFACT process and has already released a new version of messages that are based on the EDIFACT syntax. 2.3 SWIFT Society for Worldwide InterBank Funds Tranfer is an organisation owned by a consortium of the world s international banks. This is the world-wide industry standard in international banking and is also aiming to interface with EDIFACT. 2.4 EDIFACT In 1985 the United Nations (UN) decided to develop a single universal standard, which resulted in the Electronic Data Interchange for Administration, Commerce and Trade (EDIFACT) standard. EDIFACT has the approval of the International Standardisation Organisation (ISO) and offers a comprehensive support to all EDI needs. There has been a global acceptance of this standard and many user group specific standards converged to EDIFACT with some exceptions, especially in countries such as USA, Canada and UK. The previous standards are either the past or the present in the EDI standards history, the future however is still unclear and there is only the possibility to follow some general predictions of what it will reserve. The next section tries to open a window into the future and predicts the next EDI standard. 2.5 Future The most common reason to justify the limitation of the widespread use of EDI has been the implementation costs. Mainly because, normally to have an EDI system it would be required to buy or develop the EDI translator, to integrate the translator with the company s system, and to establish a communications network among trading partners. (Segev et al., 1997). However, with the evolution of the Internet in the last 5 years it is now possible to have an Internet connection at very low cost. EDI vendors are now realising about the potential use of this medium for EDI and are developing new solutions (less expensive) or adapting the current applications that are based on Value Added-Networks (VANs) to allow Internet access (also known as WebEDI). We must bear in mind that the main use of EDI as been in a context of Business to Business (B2B) where powerful companies have forced suppliers to adopt EDI systems. Normally, they used either a specific industry message format (like ODETTE to the automotive industry) or a more common used standard like EDIFACT or ANSI X12. On the other hand, in the context of Business to Customer (B2C), which is an emerging concept that means not only the traditional order by a customer but also the possibility for checking quotations or stock availability in real-time. This is increasing with the electronic commerce, where customers are constantly searching for the best price and are demanding for automatic ways to do it. 5

6 Because there is not a universal acceptation of a single EDI standard (Chute, 1996) there is a need for a standard that is open and accessible to all, capable of covering a wide range of business needs. It also needs to be extensible (to cover future business requirements) and to incorporate new technologies and requirements as they emerge. The extensible Markup Language (XML) has been proclaimed to be the answer for the above needs by providing a freely available, widely transportable, methodology for wellcontrolled data interchange (Bryan, 1998). 2.6 XML It is a subset of the Standard Generalized Markup Language (SGML) and was developed by the World Wide Web Consortium (W3C in According to the XML/EDI group (Bryan, 1998), XML provides an ideal methodology for electronic business because: Allows the clear identification of the role and syntax of each piece of interchanged data, which is both machine and human interpretable. The source of each shared structure is accessible using an Internet Uniform Resource Locator (URL). There is the option to identify which pieces of information should occur in each interchanged set of data and, if required, the order of individual fields. Metadata fields that can be used to identify who is responsible for creating, transmitting, receiving and processing each message. Although XML was not created specifically for EDI it is considered to be the future of EDI in particular for the Internet business transactions. Because XML is very recent it is considered to be a work in progress by the W3C and at moment there are several recommendations being prepared that will certainly have an impact in how XML will be in the future. Nevertheless, the potential for EDI is present and so in the next section both EDIFACT and XML are explained in more detail and are also compared through advantages and disadvantages for an EDI implementation. In the end of the section it is discussed if only one should be selected or if a combined system is more suitable. 3 EDIFACT vs XML When comparing EDIFACT with XML, one can observe that in general the strength of the first is the weakness of the second and vice versa. The following table (Table 1) compares EDIFACT and XML through a set of EDI related characteristics. Characteristic EDIFACT XML Flexibility Very difficult to go beyond the standard specifications. It tries to cover all the business needs and changes take a long time to get into standard. Portability Easy to transfer between heterogeneous networks because messages are based on text using ISO approved characters. Self-Describing Tools The segment coding system can be confusing, but an EDIFACT decoder needs to have all the codes in order to process the message and check the validity. Due to the EDIFACT encoding rules and syntax it is more Very flexible with many applications and possibility for easy adaptation to new business needs. Too much flexibility, in some cases leads to incompatibilities. Easy to transfer between heterogeneous networks because messages are based on text using Unicode characters. Each XML document carries a structural description of its contents with it in the form of the element tags. For validity checks the DTD must be available. Due to the nature of XML it is easy to develop general-purpose tools to 6

7 complicated to developed tools. But, EDI vendors already have a wide range of applications available. Robustness Depends on the EDIFACT translator because the standard provides several mechanisms for error detection and handling. Security Human Readability Size It has been implemented in VANs where security is a primary concern. Not very easy because there is still some encoding in the segments. Tries to save space with the coding techniques and redundant information. Complexity Some of the features in the Standard can be quite complex and can take more time to understand. Costs Requires specific translators that normally belong to an EDI package of communication and integration Endorsement tools. The costs are high. It has the support of the UN and it is an ISO approved standard. create, edit, display documents. Again this characteristic will depend on the application that is reading the document. XML allows error detection, although with DTDs it is difficult to verify the datatype. XML is primarily directed to the Internet where security is still questioned. The tag system allows a better readability because it is more descriptive. Because of the descriptive nature of XML, documents are bigger when compared to an equivalent EDIFACT message. The encoding system is intuitive, and the tagging system is very familiar to the Internet community. Theoretically any Internet browser in the future will be able to read XML and XML parsers are freely available. So, estimate costs are low. It is still a W3C recommendation, but as number of support grows it may reach the Standard level. Table 1 Contrast between EDIFACT and XML The main advantages of EDIFACT are that it is an official standard with the ISO approval, the availability of proven EDI tools and robustness. On the other hand, XML main advantages are the high flexibility, the describing nature of the documents and the potential low costs on XML based EDI solutions. These two possible solutions are next discussed on the light of an EDI implementation in order to reach a decision of each one should be used in the translator. 3.1 Discussion of EDIFACT vs XML One of the pitfalls of XML for EDI is that it does not define how information will be structured, or what it can mean. It is the user that defines the tags and their semantics, giving structure and meaning to the data. (Worden, 2000) Currently each specific industry is developing their own XML vocabulary or message definitions such as FIN-XML for financial transactions, or C-XML for diverse commercial transactions. Therefore, there is a common language (XML) but with different dialects, which turns the dream of a universal standard almost impossible. The XML community has noticed this problem and there have been several initiatives to create XML repositories for XML message definitions. Some of these initiatives are the BizTalk ( promoted by Microsoft and partners, the UN-backed ebxml ( initiative and the XML/EDI group ( Unfortunately, as Worden (2000) points out the future of these attempts seems very grim due to the difficulty of establishing a common model to all business information, agreed across all 7

8 countries and industry sectors, to act as an interlingua for all XML translations. It also points out, that in the mean time each company can establish its own model of business information based on the specific business needs, and perform all XML translations via this mode. An alternative solution is to use the rich semantics of a well-established EDI standard (like EDIFACT) in conjunction with the syntax of the XML. (Martin et al., 2000) The XML/EDIFACT group ( is developing this solution and the initial results are encouraging with the release of an EDIFACT to XML translator, which turns any wellconstructed EDIFACT message into XML. So, joining EDIFACT with XML will merge the benefits from each individual approach and the created synergy will reduce any possible downside. Creating a translator that can handle EDIFACT messages and also export or import them in XML format has several advantages: Standard importance EDIFACT is still the de facto EDI Standard and many companies are either using it or in the process of changing to it. Legacy Systems If a company wants to receive XML messages and has an EDI system based on EDIFACT, the translator can do the bridging task if the messages is based on the agreed EDIFACT message. Expansion Any document created by an XML application based on the EDIFACT syntax can be read by the translator, which means that new trading partners do not need a large EDI structure to start sending and receiving messages. Therefore, to benefit from these advantages the proposed EDI translator seeks to integrate EDIFACT and XML. This is explained in detail in the next section where the EDIFACT/XML architecture is defined after the study of typical EDI architectures. 4 Translator Architecture 4.1 Generic Architecture EDIFACT messages do not need to be created manually, to do this task EDI companies have developed EDIFACT translators that make the interface between an organisation s information system and the standard. These translators have all the EDIFACT encoding and decoding rules, which are followed strictly, in order to generate compatible messages between different vendor translators. The most common way to make the interface between a translator and an information system is through flat files that are tagged in a format known by the two systems. Figure 2 illustrates this process: Information System Flat file EDIFACT translator EDIFACT file Figure 2 Interface between an EDIFACT translator and an Information System After creating the EDIFACT file it is sent to the corresponding trading partner, normally through a VAN, this task is normally done by a specific communication system and not by the translator. The process is bi-directional and supports multiple message types and partners. The generic architecture of an EDIFACT translator can be divided into three layers: 1. Interface Responsible for the user and system interface. 2. Operational Groups all the operations in a translator such as message configuration, parameterisation or creation. 8

9 3. Knowledge Contains all the information necessary for the operational layer such as the structure of messages including the system segments, segments, composite elements, data elements or code lists. These layers are hierarchically organised, as shown in figure 3. Figure 3 Hierarchical layer organisation of a generic EDIFACT translator Please note that most of the information concerning the architecture of EDI translators is commercially sensitive. This information is very difficult to find and so the following architectures have some features that are based on the most logical architecture that could support it. 4.2 Traditional Architecture Interface Operational Knowledge The traditional architecture of an EDIFACT translator is shown in Figure 4. INTERFACE Directory Information Structure Display Element Edition Interactive or Automatic OPERATIONAL Directory Import/ Parsing Configuration A Param. AB EDIFACT translator ABC Knowledge Source KNOWLEDGE A Structured files B Custom C Element Meaning Log File UN/EDIFACT Directory In-house file structure In-house file data EDIFACT Figure 4 Traditional EDIFACT translator architecture The architecture of an EDIFACT translator starts with the import or parsing of the UN/EDIFACT directory, so it can have all the information in structured files (with a format specific to the translator). This information is then used to configure a custom message based on the standard template. 9

10 Next, each element in the Custom must be given a meaning or a source for the data to be included in the message. Generally, it is done through the linking of an element and a specific marker in the in-house file format generated by the company s information system. The last step is the normal translator operation of creating or decoding EDIFACT messages from or to the in-house file format. 4.3 XML Based Architecture This is the emerging EDIFACT translator, based on the XML features. Figure 5 depicts the basic architecture of this translator. This architecture is based on the Extensible Data Interchange (XLI) framework developed by Tim Weitzel and Peter Buxmann from the Institute of Information Systems at J. W. Goethe University. (Weitzel & Buxmann, 2000) INTERFACE Visual Structure Visual Structure Automatic OPERATIONAL EDIFACT Structure Mapping XML Structure Mapping EDI translator ABCD Knowledge Source KNOWLEDGE A B EDIFACT XML message Import structure Template C XML document template D XML Export template ODBC ODBC UN/EDIFACT In-house file structure DB structure In-house file structure In-house file data DB data EDIFACT or XML Figure 5 XML based translator architecture This translator architecture is not a true EDIFACT translator, because it only makes the mapping between an EDIFACT message structure and an in-house format. It relies heavily on the XML flexibility either to create new XML documents or to create Import/Export templates. It can start either with the EDIFACT structure mapping or with the XML structure mapping in order to generate Import/Export templates to an in-house file format or to a relational database through an ODBC (Open Database Connectivity) connection. The ODBC connection enables the direct connection with the company s information system allowing an easier integration between the two systems. This alternative to the traditional flat file interface is one of the advantages of this architecture, because it reduces the need to create specific file parser on the company side. 10

11 This architecture is very flexible because it does not depend on a specific standard and any of the XML documents can be easily altered to meet the business specific needs. The EDIFACT features are very limited because the translator just makes the message more human readable by changing the EDIFACT structure to XML. 4.4 Proposed Architecture The architecture for the Visual EDIFACT/XML Translator (VEXTRA) is a combination of the previous architectures, although it has some particular features like in the Knowledge layer where the structured information is kept in a relational database. Figure 6 shows the architecture. INTERFACE Directory Information Structure Display Visual Structure Interactive or Automatic OPERATIONAL Directory Import/ Parsing Configuration A Param. AB EDIFACT translator + XML/EDIFACT translator ABC Knowledge Source KNOWLEDGE A Relational Database B Custom C ODBC ODBC ODBC Element Meaning Log File ODBC ODBC UN/EDIFACT Directory In-house file structure XML DB structure In-house file data XML DB data EDIFACT or XML/EDIFACT Figure 6 Visual EDIFACT/XML translator architecture Before going into a detailed analysis of the architecture some conceptual ideas must be clarified in order to justify some of the architecture options. These ideas derive from the research on the EDI subject and from personal experience: Visual Interface Since the early stages of this project was felt the need for a visual interface both to the EDIFACT standard and to some critical operations of the translator such as message configuration and parameterisation. Flat file in XML The structure of XML is ideal for the interface through flat file between the translator and an in-house system. XML/EDIFACT messages As explained in section 2.4, in order to enable an interface between non-edifact compliant EDI systems the descriptive nature of an XML/EDIFACT is very appropriate because there is only the need for an XML parser to make the interface. Relational Database The EDIFACT standard is characterised by the relationships between messages, segments, composites, data elements and code lists. Therefore, a relational database seems to be the most suitable way to store this information and, most important, to allow a more efficient and direct access to it through the Structured Query Language (SQL). 11

12 ODBC connectivity The wide use of relational databases in the in-house systems enables the direct database integration with the translator through ODBC as an alternative for the traditional flat file technique. ODBC is the de facto industry standard for accessing heterogeneous SQL databases (Connolly et al., 1999). VEXTRA architecture is now explained in detail, according to each specific operation: Directory Import/Parsing EDIFACT directories are distributed in individual text files structured to allow the parsing to extract information. This operation requires developing a parser application to each individual file and to create the relational database, which will be the base for the Knowledge layer. Therefore, three tasks are required: 1. Database Design The EDIFACT standard must be closely analysed in order to determine the right structure for the relational database. 2. Parser Development Each file has a specific structure that must be understood before the development of a parser, in practice each file will have a parser. 3. Interface Definition A visual interface for directory maintenance and for the EDIFACT standard must be defined. Configuration This operation has the objective of creating a custom EDIFACT message based on the structure or template defined on the standard. It is the user that configures the custom message in a very interactive process. The Knowledge layer must support the structure of multiple custom messages. The following tasks are required: 1. Database Design The custom message must also be stored in the relational database at the Knowledge layer. So, the particular needs of the message configuration exercise must be defined. 2. Interface Definition Interactive interface of a message template and custom message structure, where segments can be removed or added. 3. Configuration Operations The segment Add and Remove operations must be implemented in the Operational Layer. Parameterisation Each data element in an EDIFACT message must have a meaning or a source from where the translator has to read the data. This process is also often called structure mapping and the data source can be, in this architecture, either from an XML flat file or a relational database. Some of the elements contain a static value for all the messages and do not need a connection to a specific data field. In order to implement this operation the following tasks are needed: 1. Database Design The relational model must be able to cover the mapping information from a specific message. The information structure will consist of a unique element identifier and the source field from where to read the data (XML tag or table field). Some data elements can be a constant value. 2. Interface Definition Visually the user will need to see the custom message structure and the database or XML flat file structure, so it can then add or remove the connection between a data element and a field. 3. Parameterisation Operations - The Add and Remove connection operations must be implemented in the Operational Layer, as well as the operation of attributing a constant value to a data element. An XML structure parser will also need to be implemented so that its structure can be visualised in the Interface Layer. The structure of the relational database must also be extracted. 12

13 EDIFACT Translator This operation will generate the EDIFACT message based on the standard encoding rules and all the information kept in the Knowledge layer from the custom message structure to the mapping information. Basically, it will follow the message structure, gather the external information of each data element and according to the EDIFACT encoding rules create an EDIFACT message. It will also read an EDIFACT message that will be verified against the expected structure and the information in each data element is extracted and exported either to an XML flat file or to a relational database. To implement this operation the following tasks are required: 1. XML parser To extract the data from the XML flat file that contains the information to be encoded in the EDIFACT message. 2. Database access Operations to access specific table fields in a relational database through ODBC, so the data can be extracted and included in the EDIFACT message. 3. Encoding & Decoding function The function that writes/reads an EDIFACT message based on the encoding rules and with validation of a received message conformity to an expected message structure. 4. Log File The encoding and decoding function is crucial and any error or abnormality must be written in a log file for posterior analysis. XML/EDIFACT Translator This operation will enable the translation between EDIFACT messages and XML based in the recommendations of the XML/EDIFACT group. This group released a DTD for the XML representation of an EDIFACT message, which will be followed. Please note that, when writing, this functionality will be used after the EDIFACT message is created and will also be an option for the user either to create only and EDIFACT message, an XML/EDIFACT message or both. When reading the translator will have and XML/EDIFACT document as input and will generate the corresponding EDIFACT message. In order to implement this functionality the following tasks are required: 1. Encoding & Decoding function - The function that writes/reads an XML/EDIFACT document based on the encoding rules and with validation of document conformity to the DTD. To test if the proposed VEXTRA architecture is valid (suitable for a real implementation) a prototype was developed following the previous recommended tasks. 5 Prototype Before implementing the development environment was studied in terms of the most suitable development tool and storage system. In the first Visual Basic 6.0 was select against two other alternatives (Visual C++ and Java), mainly because it provided a rapid application development in a Windows environment. In the storage system a relational database system was selected against a file system after listing the advantages and disadvantages of each system, confirming the initial architecture option. In order to use the relational database a design exercise was conducted to define a structure model that could be implemented in any DBMS. This exercise followed a database design methodology with three main phases Conceptual, Logical and Physical Design. It was also defined that the prototype should use MS Access DBMS as the relational database system mainly due to the native connectivity with VB6 and accessibility. Although not so powerful as other relational DBMSs (i.e. Oracle or SQL Server) that are suitable for professional applications, it allowed testing that the proposed relational model was suitable. Another design exercise consisted in modelling the translator class system to map a message structure in memory and to isolate the encoding and decoding functions. This proved useful 13

14 because it allowed reusability of code and to divide the translator algorithm into simpler tasks, which facilitated the development. The developed prototype consists in a Windows application with four modules Directory Manager, Configuration, Parameterisation and Operational Menu. It presents a visual interface to the EDIFACT standard where the directory text files are parsed in order to extract the required information, which is cross-referenced and displayed with a search facility. It also enables a visual and interactive interface for the processes of message configuration and parameterisation being able to translate any message to which it has been configured. Figure 7 illustrates the Operational Menu screen. Figure 7 Operational Menu Screen Unfortunately, due to mainly a time constraint it was not possible to develop all the features in the VEXTRA architecture. The features that were not developed (future work) are the reading and writing of an in-house file structure in XML and the XML/EDIFACT translator (consequently the reading and writing of XML/EDIFACT messages). The Log system was only partially developed. These features were left out because the logical task approach was from left to right in the architecture due to the sequential knowledge source, which means that (for example) the EDIFACT Translator could not be developed without developing the previous features of Directory Import/Parsing, Configuration and Parameterisation. Testing involved two stages in which the prototype was first subjected to sample data and after having a stable version it was subjected to real data. The tests provided a useful test bed for discovering logic errors and mistakes in the code especially when using real data. In order to test the prototype outside the development bench and to demonstrate its flexibility, it was developed an Internet link that simulates an on-line ordering system in which an order form is filled and is converted into an EDIFACT message. This link was installed in VEXTRA s website ( that was developed for promoting the project and to be a repository of information about EDI. The site 14

15 traffic analysis has demonstrated that there is an interest in this area world-wide and that it is appealing in terms of structure, design and content. Furthermore, it shows that VEXTRA architecture has a potential interest for a real implementation. 6 Conclusions EDI systems rely on standards, agreed between the trading partners, to ensure the compatibility between different systems. However, it is difficult to elect a truly universal standard used world-wide because some are specific to a country or industry. But, the most important in terms of usage are ANSI X12 and EDIFACT in particular the last one that has the endorsement of the UN and the approval of the ISO. However, the trend over the last decade on EDI standards has been for a convergence to the EDIFACT standard, but still far from a global acceptance. Because, of this lack of a universal standard the EDI community has elected XML as the future of EDI in particular for Internet business communications. XML in theory would be very suitable for EDI due to its high flexibility, describing nature and potential low costs on XML based EDI solutions. But, in practice the high flexibility and pour semantics are strong constraints for a uniquely XML based translator because each specific industry is developing their own vocabulary or message definitions. The XML community has perceived the previous problem and has been trying to solve the solve it either by creating repositories for XML message definitions or to use the rich semantics of a well-established EDI standard (like EDIFACT) in conjunction with the syntax of XML. The last solution has been considered the most likely to succeed because it will merge the benefits of EDIFACT and XML plus the advantages of keeping the EDIFACT standard that is de facto EDI standard, compatibility with legacy systems and easy expansion. After developing and testing the prototype it is possible to conclude that the development environment was appropriate enabling a rapid application development with complex interface features that otherwise would have limited the project. In particular, VB6 proved to be suitable for the prototype development enabling fast code prototyping and interactivity with immediate display of results. In a global perspective the prototype proved that VEXTRA s architecture is suitable for a real implementation and is flexible enough for further developments and enhancements mainly due to the level of functionality achieved that enabled the prototype to translate any EDIFACT message to which it was configured. Because VEXTRA architecture is based on a layer system (three-tiered) the impact of changes in one layer does not greatly affect the remaining layers, which transforms the architecture into a framework from where new systems can be designed. This project represents more than just the development of an EDI translator, it is a study that seeks to develop a transparent EDIFACT/XML platform for e-business (B2B or B2C) in which VEXTRA is a technological requirement. Undoubtedly, the future will show new breakthroughs in the communications technology (particularly on the Internet) that will create new opportunities for further research and development in the EDI area. 15

16 References Benjamin, Robert and Wigand, Rolf (1995) Electronic Markets and Virtual Value Chains on the Information Superhighway, in Sloan Management Review, p.p Bradley, Stephen et al. (1993) Globalization, Technology and Competition, Harvard Business School Press. Bryan, Martin (1998) Guidelines for using XML for Electronic Data Interchange, XML/EDI Group Chute, Alan (1996) The Mythical Value of EDI Standards. Connolly, Thomas (1999) Database Systems A Pratical Approach to Design, Implementation, and Management, 2 nd Edition, Addison-Wesley. DeSanctis, Gerardine et al. (1999) Interdependence in Virtual Organisations in Trends in Organizational Behaviour Vol. 6 The Virtual Organization, Wiley. Segev, Arie et al. (1997) Internet-Based EDI Strategy, Working Paper 10-21, Fisher Center of Management and Information Technology, University of California Berkeley; VANGUARD (1989) EDI Standards: a guide for Existing and Prospective Users in Profiting from Electronic Trade, the Department for Enterprise. VANGUARD (1989b) The economic effects of value-added and data services in Profiting from Electronic Trade, the Department for Enterprise. Weitzel, Tim & Buxmann, Peter (2000) A communication architecture for the digital economy, Institute of Information Systems - J. W. Goethe University. Westarp, F. v. & Weitzel, T. & Buxmann, P. & König, W. (1999): The Status Quo and the Future of EDI, in Proceedings of the 1999 European Conference on Information Systems (ECIS 99), Wigand, Rolf & Picot, Arnold & Reichwald, Ralf (1997) Information, Organization and Management, Wiley. Worden, Robert (2000) XML E-Business Standards: Promises and Pitfalls, O'Reilly & Associates, Inc. 16