EDI Connect User's Guide

CHAPTER 1

Welcome to exteNd Composer and EDI User Interface

 
Top of page

Before You Begin

Welcome to the EDI Connect Guide. This Guide is a companion to the exteNd Composer User's Guide, which details how to use all the features of Composer, except the Connect Component Editors. So, if you haven't looked at the User's Guide yet, please familiarize yourself with it before using this Guide.

exteNd Composer provides separate Component Editors for each Connect. The special features of each component editor are described in separate Guides like this one.

If you have been using exteNd Composer, and are familiar with the core component editor (the XML Map Component Editor), then this Guide should get you started with the EDI Component Editor.

Before you can begin working with the EDI Connect you must have installed it into your existing exteNd Composer. Likewise, before you can run any Services built with this connector in the Composer Enterprise Server environment, you must have already installed the server-side software for this connector into Composer Enterprise Server.

NOTE:   To be successful with this Component Editor, you must be familiar with the EDI environment and the applications that you want to XML-enable.

 
Top of page

About exteNd Composer Connects

exteNd Composer is built upon a simple hub and spoke architecture. The hub is a robust XML transformation engine that accepts requests via XML documents, performs transformation processes on those documents and interfaces with XML-enabled applications, and returns an XML response document. The spokes, or Connects, are plug-in modules that "XML- enable" sources of data that are not XML aware, bringing their data into the hub for processing as XML. These data sources can be anything from legacy applications to Message Queues to HTML pages.

exteNd Composer Connects can be categorized by the integration strategy each one employs to XML enable an information source. The integration strategies are a reflection of the major divisions used in modern systems designs for Internet-based computing architectures. Depending on your B2B needs and the architecture of your legacy applications, exteNd Composer can integrate your business systems at the User Interface, Program Logic, or Data levels.

Figure 1-1

 
Top of page

What is EDI?

EDI stands for Electronic Data Interchange, a standardized electronic format for interchange of information between computer applications. An EDI transaction involves extracting data from a computer, translating the data into an appropriate EDI format, transmitting the payload, translating and interpreting the received transmission, and importing the data into the receiving application (where the data can undergo further processing). EDI extends to all trade and trade related activities. Three main areas of activity include commerce, transport and government.

Rules for the encoding of business data in EDI format are contained in two specifications: ANSI X.12 and EDIFACT. Typically, EDI documents relevant to specific business operations (such as purchase orders, invoices, etc.) are encoded as EDI documents, which are grouped together into a unit called an interchange. One or more interchanges can be grouped to form an interchange set, which is the unit of transmission. Individual interchanges will conform to a single standard (EDIFACT or ANSI X.12), but interchange sets may contain interchanges of diverse types.

EDIFACT is a set of standards and guidelines for the electronic interchange of structured data, approved and published by the United Nations Economic Commission for Europe. The standard is published in the United Nations Trade Data Interchange Directory (UNTDID). Further information about EDIFACT can be found at http://www.unece.org/trade/untdid.

ANSI X.12 comprises the set of EDI specifications maintained by members of Committee X.12 of the American National Standards Institute. ANSI is a private, non-profit organization responsible for the development and approval of voluntary consensus standards in North America. Its membership includes over 1000 well-known companies and organizations.

Further information about ANSI X.12 can be found at http://www.disa.org, the web site of the Data Interchange Standards Organization.

 
Top of section

HL7 Support

The Health Level Seven (HL7) is a standard for EDI in all healthcare environments, especially hospitals. HL7 Standard defines the messages as they are exchanged among application entities and the procedures used to exchange them. It operates at the seventh level of the ISO model for Open System Interconnection (OSI). HL7 conforms to the requirements of ANSI. The HL7 structure contains one document per interchange with data fields combined into segments separated by segment separator characters. Further information about HL7 can be found at http://www.hl7.org, the web site of the Health Level Seven Standard for electronic data exchange in all healthcare environments.

 
Top of section

SAP Support

SAP (Service Access Point) supports the EDI process by providing EDI-enabled applications capable of sending and receiving IDoc messages. IDocs are SAP's proprietary format for exchanging data between business applications.IDocs are based on EDI standards, closer to EDIFACT standards than ANSIX12. IDoc format is compatible with most EDI standards. IDoc structure consists of several segments and segments consisting of several data fields. One IDoc contains one document per interchange with a fixed length of field sequences. Further information about SAP and EDI can be found at http://www.geocities.com/sap_edi, the web site of the SAP R3 Electronic Data Interchange.

 
Top of page

What is XML?

XML stands for Extensible Markup Language and is a World Wide Web Consortium (WWW3) recommendation that defines data meaning rather than its presentation. XML is a subset dialect of the Standard Generalized Markup Language (SGML), which was developed to interchange technical documentation and other forms of technical data.

XML works by allowing users to define a set of tags that are embedded into a file that contains the information being communicated. The tags, which have starting and ending forms, explains exactly what the data in the tagged section of the document is intended to mean. Each set of tags is defined in a a separate file in the form of a document type definition (DTD).

XML has provided increased structure to the Web and is being widely used. Now XML is being used with EDI.

 
Top of section

Combining XML Structure with EDI Rules

In XML, each document is an object and each element of the document is an object. These objects are defined in the DTD. By using the XML tag set, EDI "objects" can be either passed or reference other stored objects. The "rules" of EDI can be applied to objects via the Document Object Model (DOM). By using the DOM, XML/EDI documents are able to combine the content, the rules that control the transaction and the view in one file/transaction.

exteNd Composer lets you build XML documents, navigate within their structure, and add, modify, or delete elements and content. Anything found within an XML document can be manipulated using a DOM method. Composer supports all DOM methods recommended by WWW3. For more information on DOM, refer to the section, Creating an XML Map Component in the exteNd Composer's User Guide.

 
Top of page

Why change from EDI to XML EDI?

There are a variety of reasons to make a transition from the traditional EDI to XML-based EDI. Some of these reasons are listed below.

The benefits of XML-enabled EDI include:

 
Top of page

What is the EDI Connect?

The EDI Connect extracts the messages from an EDI transmission into XML or converts from XML to a given standard. These rules are contained in two specifications: ANSI X.12 and EDIFACT. Refer to Appendix A for a brief list of segment-header mnemonics for ANSI X.12 and Appendix B for similar mnemonics pertaining to EDIFACT transmissions.

For an Inbound EDI transmission, the input to the connector is an XML document that has the entire transmission in a CDATA node. For an outbound EDI transmission, the connector has the capability to format an EDI transmission in a given node in an XML document, again wrapped as CDATA.

The encapsulation of rules for transformation is stored as XML files (the so-called "metadata" for the EDI). These files are divided into two categories: interchange processing XML and document processing XML. The Interchange processing XML files describe how to parse an EDI transmission. Interchange Processing is automatic and requires you to tell the connector to process the interchange. The Document-processing XML metadata describes how to parse an individual document. Document Processing requires you to identify the metadata to use.

When the component editor is active and EDI actions are taking place, the Native Environment Pane displays the raw content of the EDI transmission, with the current document segment (pertinent to the current action) highlighted in blue. See below. If you set a breakpoint, then perform animation, the Native Environment Pane will only refresh after the breakpoint is reached by stepping into the next action.

 
Top of page

What Applications Can You Build Using the EDI User Interface Component Editor?

The EDI User Interface Component Editor allows you to extend any XML integration you are building to include any of your business applications that support EDI-based interactions (See exteNd Composer User's Guide for more information.)



Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...