Export (0) Print
Expand All

Using EDI with Microsoft BizTalk Server 2000

Microsoft Corporation

January 2001

Summary: This article shows how Microsoft BizTalk Server 2000 adds value to companies that use electronic data interchange (EDI). It also shows how BizTalk Server adds value to smaller companies that don’t use EDI, but want to interoperate with companies that use EDI. The relative strengths and limitations of BizTalk Server and EDI are shown, and the article ends with a description of BizTalk Server limitations in its support of EDI in comparison with an EDI server. (14 printed pages)

Contents

Introduction
EDI Overview
Enhancing an EDI Environment by Using BizTalk Server
Using BizTalk Server in Smaller Companies
Translating and Transforming Documents
Comparing BizTalk Server with EDI Technology
Conclusion

Introduction

Many companies today use electronic data interchange (EDI) to exchange business documents. This article discusses how Microsoft® BizTalk™ Server 2000 can help both large businesses that are currently using EDI and smaller businesses that do not use EDI but that want to trade with these larger businesses.

BizTalk Server can help a company that uses EDI in the following ways:

  • Enabling enterprise application integration (EAI). BizTalk Server automates the exchange of internal business data.
  • Creating new relationships with smaller trading partners. BizTalk Server provides a cost-effective way to exchange electronic documents with companies that choose not to use EDI.
  • Facilitating future growth. BizTalk Server provides a cost-effective way to handle the expansion of a company’s messaging and document interchange requirements.

Smaller companies can benefit from BizTalk Server by using it to establish electronic document exchange relationships with larger companies that use both EDI and XML. A smaller company can also streamline its internal business processes by employing the EAI capabilities of BizTalk Server.

The ability of BizTalk Server to translate and transform documents is central to its EAI and document exchange capabilities. This article introduces BizTalk Editor and BizTalk Mapper, tools that help to direct the translation and transformation of EDI documents and other electronic documents. BizTalk Editor enables you to create and edit specifications (a BizTalk Server-specific schema). BizTalk Mapper uses specifications to map the structure of one document instance to the structure of another document instance.

This article also compares the relative strengths and weaknesses of BizTalk Server when compared with EDI technology.

EDI Overview

Electronic data interchange (EDI) is a set of standards for controlling the exchange of business documents (such as purchase orders and invoices) between computers. Businesses can use EDI to ensure that the documents they exchange are interpreted correctly, regardless of the platforms or internal applications they use. Because EDI enables electronic documents to move from one computer to another without the need for human intervention, it is faster, cheaper, and more accurate than the exchange of paper documents.

Standardization efforts for EDI formats began in the 1960s, led by the transportation industry. The need for a uniform standard that encompassed all industries prompted the creation of the Accredited Standards Committee (ASC) X12, sanctioned by the American National Standards Institute (ANSI), in 1979. The Accredited Standards Committee X12 created the EDI standard commonly referred to as X12, which was used primarily for American domestic trade. Meanwhile, the European community developed its own EDI standard called Guidelines on Trade Data Interchange (GTDI). A new standard that borrowed from both X12 and GTDI, called Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT), was developed at the United Nations. The International Organization for Standardization (ISO) adopted EDIFACT in 1987. Although in 1992 ASC X12 members approved the adoption of EDIFACT as the universal EDI standard, X12 continues to be a widely used EDI standard in North America.

Although EDI has been around for nearly forty years, it has not triggered an explosion in business-to-business electronic commerce. In fact, the number of businesses trading electronically today compared to those using phone or fax is limited. The reasons for this are numerous and include the following:

  • EDI server systems are typically expensive.
  • The EDI document format is somewhat cryptic.
  • EDI document transport was historically a value-added network (VAN) that incurred both an expensive setup fee and ongoing operational costs.

Enhancing an EDI Environment by Using BizTalk Server

Although many companies have long-term strategies that involve replacing their legacy infrastructure, a company that is heavily invested in EDI might not want to immediately discard its investment and replace it entirely with an XML-based BizTalk Server system. However, BizTalk Server can add a great deal of value to a company that chooses to continue using EDI in the short term. Areas where BizTalk Server can enhance the operations of a company that uses EDI include:

  • Enabling enterprise application integration.
  • Creating new relationships with smaller trading partners.
  • Facilitating future growth.

Enterprise Application Integration

Integrating with business partners is only one of the challenges that face businesses today. Equally important is the integration of internal business applications, such as accounting, inventory, and customer relationship management (CRM) systems.

EDI systems do not typically offer EAI infrastructure, and they support only a limited subset of possible electronic document formats other than EDI. One of the strengths of BizTalk Server is its ability to automate and streamline the flow of a company’s business data both internally and externally.

The following illustration shows a simplified representation of how a company that uses EDI might use its EDI server to exchange business documents.

Ee265737.ediandbts01(en-US,BTS.10).gif

Organization A’s EDI server sends and receives standard EDI documents to and from Organization B over a VAN. Each transaction over the VAN incurs an expense for Organization A. Organization A’s EDI server communicates with its accounting, inventory, and CRM applications either by manual data entry or by custom-built software.

The following illustration shows how a BizTalk Server hub can be added to this system to facilitate the integration of Organization A’s internal applications.

Ee265737.ediandbts02(en-US,BTS.10).gif

In this scenario, BizTalk Server becomes the hub of Organization A’s internal data exchange. The BizTalk Server hub provides an accurate and cost-effective way to automatically update the organization’s line-of-business applications when a transaction with Organization B occurs. The key to the success of this scenario is the ability of BizTalk Server to be the universal message gateway. BizTalk Server can automatically send data to Organization A’s internal applications in XML or flat-file format, or even in custom formats with the introduction of custom parsers and serializers. BizTalk Server uses the TCP/IP communication layer built into Microsoft® Windows® 2000, which is commonly used for communication between applications in an organization. With BizTalk Server these EAI processes can be put in place at costs far lower than would be possible by paying developers to create custom communications applications. BizTalk Server enables internal data exchange that is far more accurate and efficient than can ever be achieved by manual processes.

New Relationships with Smaller Trading Partners

BizTalk Server makes it easy for a company currently using EDI with trading partners to also exchange documents with smaller trading partners who cannot afford or do not want to use EDI. The following illustration shows how Organization A can add a new trading partner to its existing communications network.

Ee265737.ediandbts03(en-US,BTS.10).gif

Organization A’s BizTalk Server hub can electronically exchange business documents with Organization C using TCP/IP over the Internet. These documents can be delivered in a format that is easy for Organization C to use, such as XML. In this scenario both Organization A and Organization C enjoy the accuracy and efficiency of the automated exchange of electronic business documents. Neither company needs to incur the high costs of setting up a new EDI relationship or the ongoing expense of a VAN.

Future Growth

Organization A might find that it needs to set up new automated messaging with Organization B beyond what it has implemented with its EDI server. Organization A will find that the least expensive and most direct solution is to use its BizTalk Server hub for exchanging these new messages. In this way it bypasses its EDI server altogether. In time, Organization A might need to make more significant changes in its data-exchange relationship with Organization B. This would be an ideal time for Organization A to forgo its EDI server entirely and replace it with the BizTalk Server hub.

Using BizTalk Server in Smaller Companies

Many smaller companies could benefit from the exchange of electronic business documents with larger companies that use EDI, but they cannot justify the setup and operational costs associated with traditional EDI servers. BizTalk Server provides a cost-effective solution to this problem (and can also be leveraged with trading partners that use XML and other non-EDI formats). BizTalk Server enables a small company to automatically transform its business documents into an electronic format that an EDI server of a larger company can use. The following illustration shows such a relationship.

Ee265737.ediandbts04(en-US,BTS.10).gif

Organization D might be so small that it runs its entire business on Microsoft Office, or it might use another business tools suite that can read and write XML documents or provide adapters for BizTalk Server. BizTalk Server can process Organization D’s documents and transport them to and from the EDI server of Organization B. Organization D might have BizTalk Server and other business applications installed on a single computer, or it might be a larger company with business applications distributed across several computers. In either case, Organization D’s BizTalk Server hub can serve the dual purpose of exchanging EDI documents with Organization B and automatically integrating the flow of internal business data within the company.

Translating and Transforming Documents

A key strength of BizTalk Server is its ability to accept input in a wide variety of document formats, map that input into almost any document structure, and then output the new document structure into a wide variety of document formats. XML is central to the translation and transformation capabilities of BizTalk Server, which is in large part what makes BizTalk Server such a powerful tool for enterprise application integration and business-to-business electronic commerce.

The following illustration and accompanying list show how BizTalk Server internally processes a document.

Ee265737.ediandbts05(en-US,BTS.10).gif

  1. The incoming document instance is sent to BizTalk Server.
  2. The parser uses the source specification associated with the incoming document instance to translate the incoming document instance to XML (if it is not already in this format). The source specification is created in BizTalk Editor.
  3. The XML file is transformed by an XSLT map into another XML file of the desired structure (nodes in the incoming XML file are mapped to nodes in the outgoing XML file). The XSLT map is created in BizTalk Mapper.
  4. The serializer uses the destination specification associated with the outgoing document instance to translate the outgoing XML file to the outgoing document instance (if it is not already in this format). The destination specification is created in BizTalk Editor.
  5. BizTalk Server outputs the outgoing document instance and transports it to a destination.

The parsers and serializers included with BizTalk Server can translate XML, EDI (X12 and EDIFACT), and flat files (delimited and positional). Parsers and serializers for other formats might be available in the future. For more information, go to the Microsoft BizTalk Server 2000 Web site (www.microsoft.com/biztalk).

If you create your own parsers and serializers, BizTalk Server can translate files of any format. Regardless of the format of an incoming document instance, BizTalk Server translates it to an XML file so that the XSLT map can transform the incoming document structure into the structure necessary for the outgoing document. Even if a BizTalk Server hub inputs and outputs EDI documents, internally these documents are translated to XML. This enables BizTalk Server to take advantage of the power and flexibility of XML when transforming documents from one structure to another.

BizTalk Editor

BizTalk Editor enables you to create the specifications used by BizTalk Server to translate document formats to and from XML, and to create the maps that transform the translated XML files from one structure to another. The following illustration shows an EDI purchase-order specification based on an X12_4010_850 schema displayed in BizTalk Editor. The hierarchical structure of a document is displayed in the left pane of BizTalk Editor, regardless of whether the document format is XML, EDI, or flat-file. The right pane contains tabs that display property settings for the nodes in the document hierarchy.

Ee265737.ediandbts06(en-US,BTS.10).gif

A specification that is based on an industry standard schema, such as the X12_4010_850 schema, is a subset of that standard schema. For example, the specification in the illustration is a subset of the X12_4010_850 schema because the nodes that ordinarily exist between the CUR and ITD nodes have been removed. With BizTalk Editor you can create a new document specification based on a standard X12 or EDIFACT template and remove the nodes that you don’t need.

BizTalk Mapper

With no coding, you can use BizTalk Mapper to create XSLT maps that BizTalk Server uses to transform the structure of an incoming document instance to the structure of an outgoing document instance. The source specification in a map is associated with the incoming document, and the destination specification is associated with the outgoing document. The following illustration shows an X12-based purchase-order specification that is mapped to a purchase order specification with a different structure. This map represents the document transformation from the incoming EDI document to the XML format acceptable for the accounting application in Organization A. The display is format independent—in this case the document displayed in the left pane is an EDI file, while the document displayed in the right pane is an XML file.

Ee265737.ediandbts07(en-US,BTS.10).gif

The illustration shows links from five nodes in the source specification to five corresponding nodes in the destination specification. If you viewed this map in BizTalk Mapper, you could see the remainder of the specifications by scrolling and by expanding nodes in the specifications. BizTalk Mapper uses built-in, reusable functions called functoids to enable more complex transformations than the simple links shown here.

BizTalk Mapper has a grid preview function that is useful for navigating to a particular subsection of a complex map, such as might be required when mapping EDI documents.

Comparing BizTalk Server with EDI Technology

As explained earlier in this article, BizTalk Server offers functionality and advantages that EDI technology cannot provide. For anyone currently using EDI who is considering deploying BizTalk Server in their business, it is important to understand the strengths and limitations of both EDI and BizTalk Server.

EDI Strengths

  • Currently deployed in many businesses. EDI is a long-established standard, and many large businesses currently use it successfully.
  • Uses agreed-upon standards. EDI standards are recognized by everyone who uses EDI.
  • Standards are fairly rigid. Rigid standards require conformity.

EDI Limitations

  • High cost. EDI systems are costly to set up and maintain. Hiring and retaining EDI experts is expensive.
  • Value-added networks (VANs). Many companies that use EDI use VANs to exchange documents. VANs are expensive to set up and incur costs each time they are used.
  • Document format is not easily human-readable. It is difficult for a person to read an EDI document.
  • Not well suited for enterprise application integration (EAI). An EDI server handles connections outside the business. BizTalk Server handles connections both outside the business and within the business.
  • Many industry-specific subvariations of standard documents. In some industries, such as the automotive and aerospace industries, EDI document standards have been extended for industry-specific purposes. This can cause document translation difficulties between variants of standard EDI documents given the expectation for rigid standards interpretation.

BizTalk Server Strengths

  • Uses XML as a foundation. BizTalk Server uses XML to translate and transform documents regardless of the document format required for input and output. This creates an extremely flexible environment for document exchange both now and in the future. XML as a document format has the following advantages:
    • XML is self-describing and creates documents that are relatively easy for people to read. This makes it easier for a person unfamiliar with a particular BizTalk Server installation to become familiar with it.
    • XML experts are plentiful, and they are less expensive than EDI experts.
    • XML is very flexible and extensible.
  • Easy setup and maintenance. BizTalk Server systems are easier to set up and maintain than EDI systems.
  • Many schemas available. There is a large and growing library of schemas available to users of BizTalk Server. For more information about this schema library, go to the Microsoft BizTalk Server 2000 Web site (www.microsoft.com/biztalk).
  • Enterprise application integration. BizTalk Server handles enterprise application integration, and does it very well. For more information about case studies on BizTalk Server for EAI, go to the Microsoft BizTalk Server 2000 Web site (www.microsoft.com/biztalk).
  • Orchestration capabilities. In addition to the universal messaging capabilities described in this article, BizTalk Server has powerful orchestration capabilities. BizTalk Orchestration enables the user to design and execute long-running, loosely coupled business transactions.

BizTalk Server Limitations in its Support of EDI

BizTalk Server supports EDI formats and receipting. While many customers have found that this is sufficient for interoperating with EDI-based systems, true EDI servers have functionality that is not available in BizTalk Server at the time of release. Following are limitations in BizTalk Server support of EDI. Included are approaches to using the BizTalk Server extensibility model and consulting to overcome many of these limitations. In a number of cases consultants have already implemented these features for customers, but currently there is no example code available to demonstrate these features. These solutions will add processing time to document throughput.

Outbound Batching

  • Limitation. Although BizTalk Server can process aggregate collections of EDI documents, it cannot produce them.
  • Solution. Include a predelivery batching routine on the outbound side of BizTalk Server, and a debatching routine on the inbound side of BizTalk Server. This is to accommodate aggregate responses to transmittals batched outside BizTalk Server.
  • Effort Required. A low to medium level of effort is required to implement a solution.

Segment Compound “Tags”

  • Limitation. Currently, the source tag identifier is the only mechanism in BizTalk Server by which instance data is matched to schema-defined structure. BizTalk Server cannot resolve parsing operations when the source tag identifier in the document instance, by itself, is not sufficient for determining a structure match in the schema. An example of this might occur with the HL segments in an X12 856 advanced ship notice, where field data other than the source tag identifier adds hierarchical context to the meaning of the record’s tag (“HL” in this case).
  • Solution. Create new EDI parsers that perform parsing look-ahead logic to consider not only the tag but also the content qualifiers of various EDI segments.
  • Effort Required. A high level of effort is required to implement a solution.

Envelope Creation

  • Limitation. BizTalk Server cannot populate custom envelopes. Nor can BizTalk Server deviate from the EDI-based envelopes that it provides, in the case where it is necessary to use optional fields on the envelope.
  • Solution. Develop a predelivery process to add content to envelopes. This might involve having BizTalk Server build an envelope, and then populating the envelope in the add-on process. Alternatively, the add-on process could create and populate the record. In either case, the data could be from the BizTalk Messaging Management database, a private add-on database, or both.
  • Effort Required. A medium level of effort is required to implement a solution.

Functional Acknowledgments

  • Limitation. There are four limitations in this area:
    • BizTalk Server parsers cannot take advantage of the range of EDI batching or aggregation functionality that an EDI server can. For example, BizTalk Server is unable to reject an entire group based on individual document failure within the group.
    • Detail does not include the field level, so it is often impossible to know, for example, which field failed validation.
    • The validation step stops at the first error.
    • BizTalk Server provides no notification or other action when receipts become overdue.
  • Solution. There are no solutions for the first three limitations. To solve the last limitation, you must set up stored procedures as Microsoft® SQL Server™ jobs. The purpose of this is to sweep the tracking database periodically to look for overdue receipts and to perform notification as needed.
  • Effort Required. A low to medium level of effort is required to implement a solution.

EDI Data Types

  • Limitation. When creating a specification in BizTalk Editor, you cannot specify EDI data types for X12 document field contents. This limitation is most significant in custom data types that have to do with explicit or implied decimal placement and the number of digits before and after the decimal.
  • Solution. There is no solution for this limitation within the context of BizTalk Server.

Envelope Mapping

  • Limitation. BizTalk Server cannot map data from envelopes.
  • Solution. There is no solution for this limitation within the context of BizTalk Server.

Binary Segment Content

  • Limitation. BizTalk Server cannot specify a maximum size for a binary field if that maximum is in excess of 32-bit MAXINT.
  • Solution. There is no solution for this limitation within the context of BizTalk Server.

Control Number Enforcement

  • Limitation. There is no way for BizTalk Server to know when duplicate items are submitted for processing except through the use of the BizTalk Framework.
  • Solution. Develop a preprocess that scans all data in the tracking database (or in a replicated warehouse of all historic tracking data) to verify the uniqueness of received data prior to submitting it to BizTalk Messaging.
  • Effort Required. A medium level of effort is required to implement a solution.

Floating Segments

  • Limitation. BizTalk Server does not support floating segments. Segments defined in schemas are fixed to specific locations in the data according to where the schema explicitly places them.
  • Solution. There is no solution for this limitation within the context of BizTalk Server.

VAN Integration

  • Limitation. There are two limitations in this area:
    • BizTalk Server has no built-in VAN transport components for sending or receiving data.
    • BizTalk Server has no mechanism for entering VAN sender and receiver status reports into a tracking database.
  • Solution. Develop application integration components (AICs) to serve as the transport mechanism to interact with a VAN. There might also be a need to create tables related to the tracking database that would hold VAN sender and receiver status reports. This is because there is also a foreign key relationship between the new tables and existing tracking tables.
  • Effort Required. A medium to high level of effort is required to implement a solution.

Envelope Data Viewing

  • Limitation. It is not possible to see envelopes in BizTalk Document Tracking, other than by viewing the parent interchange for documents being searched.
  • Solution. Modify the BizTalk Document Tracking user interface so that the envelopes are optionally displayed with the individual work items.
  • Effort Required. A high level of effort is required to implement a solution.

Conclusion

BizTalk Server can add value to any company that needs to automate its internal data flow or automate the exchange of business documents with other companies. This includes companies that use EDI as well as companies that don’t use EDI but need to do so to build business relationships with EDI-based companies. Although BizTalk Server is not an EDI server, it enables you to use EDI and other formats for business-to-business integration as well as EAI. BizTalk Server provides a very powerful and flexible framework to move your enterprise forward.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This Article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2001 Microsoft Corporation. All rights reserved.

Microsoft, BizTalk, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft