Notice: This material is excerpted from Special Edition Using Microsoft Exchange Server, ISBN: 0-7897-0687-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Exchange is a powerful electronic mail messaging platform. As you have seen, many Independent Software Vendors (ISV) are developing third-party solutions to extend and enhance Exchange's core technology. A new area where Exchange has been gaining momentum is in Electronic Data Interchange (EDI). Exchange enables Microsoft to enter this high-end commerce transaction system running most corporations around the world.
EDI is a strategic direction for Microsoft. EDI over Exchange complements Microsoft's Internet commerce strategy to provide a completely integrated solution.
In this chapter, you learn the following:
What is EDI?
EDI is an architecture for providing electronic commerce between trading partners. Trading partners are business organizations who wish to share commerce data via electronic means. One example is that a grocery store chain and a food manufacturer could be trading partners. Using EDI, when the store needs to order more food for the shelves, the products and amounts can be shipped directly to the manufacturer for order processing and shipment. In figure 32.1, an example of an EDI data flow is displayed.
This figure shows an EDI dataflow diagram.
EDI is a complement to electronic mail as it promotes a paperless system. EDI applications today are complex, proprietary, archaic, and customized for specific systems and industries. Several standards have been drafted to define EDI in the marketplace. X.435 was specified in 1990. The x.435 standard is an extension to x.400 incorporating electronic commerce requirements. The original specification was to be used with x.400 P2 protocols which were standardized in 1984. X.435 today supports x.400 P22 protocols dated 1988.
Microsoft Exchange Server Message Transfer Agents (MTA's) are certified to this x.400 P22 protocol standard. This will ensure interoperability for customers. Only digital messaging MTA's have received this certification.
Using EDI requires an application environment. A typical EDI architecture will have an e-mail client communicating with the mail server, (see fig. 32.2). In this case, an Exchange server. The mail server must support x.400 or SMTP addressing and connections. This is handled through the use of a gateway product running on the mail system. Exchange offers x.400 and SMTP connectors built into the server software package.
This an example of an EDI architecture.
At the same time that mail is able to travel over x.400, EDI enabled applications must generate EDI data files or pre-formatted EDI data packages. These packages are then sent over the same exact x.400 or SMTP connections. Depending on the final destination of the message, it may pass through an additional gateway to reach an existing mail system or traverse a Value added Network (VAN) to reach a trading partner. Between the EDI application and the x.400 connector is an EDI server. Third party solution are being developed to leverage windows NT and Exchange to perform the function of EDI server. This EDI server is used to translate flat data files into EDI packages to be forwarded to the mail connectors. These products will be discussed later in this chapter.
EDI starts with a trading partner agreement between you and your trading partner. This is an agreement between companies as to the computer systems and technology to be used for the EDI dataflow. They must make a combined decision about the EDI standard to be used for the transactions, the information to be exchanged, the VAN, and scheduling of the information exchange.
The companies are ready to then create a document of an invoice in the business application and save the document in the system. The EDI translator automatically reformats the invoice into the agreed-upon EDI standard. The translator creates and wraps the document in an electronic envelope that has an ID for the target trading partner.
The communications portion can be part of the translation software or a separate gateway connector. In the case of Exchange, the EDI communication gateway begins to communicate on the network or over a dial-up line.
Once connected with the VAN, the envelope containing the document is then transmitted to the VAN messaging service. Several VANs today are beginning to support native Exchange formats to reduce the need for data format conversion. The VAN reads the ID on the envelope and distributes it to the correct mailbox.
The trading partner, similarly communicates over their network or over a dial-up line and downloads all of the contents of the mailbox. The EDI translator opens the envelope and translates the data from the agreed upon EDI standard format to the format to be read by their application. The process is complete when the companies' accounting department creates a check from the electronic invoice.
The key to EDI is to reuse the data by inputting the data only one time. The EDI and messaging systems handle the rest of the work. Data moves without intervention from the business application to the trading partner's application.
As you can see, EDI is a simple, yet extremely complex system. EDI translation software must integrate with EDI application software. It is important to rely upon industry standards to maintain this type of EDI relationship.
After defining the document in the business application, you use an EDI mapper to create a map or relationship of the business document. With the mapper, you describe or associate the relationship between the datafields in your business application and the selected EDI standards. The mapper or association manager is an integral part of the complete EDI solution.
If both the EDI translator and business application are on the same type of computer, the data will move faster and more easily from one process to another.
In an EDI deployment, several key elements are needed. The following list is an introduction into the key technology used in EDI:
The following is a list of the various terms used in the world of EDI. This list is an introduction to the basics of EDI. If you are considering using EDI to resolve business data management between you and a trading partner, please see http://www.microsoft.com/exchange for more information or contact your local Microsoft Consulting Services office to discuss your implementation in detail.
Common EDI terms:
ANSI. American National Standards Institute. A private, non-profit membership organization that coordinates the development and approval of voluntary consensus standards in the United States.
ANSI ASC X.12. ANSI Accredited Standards Committee X.12. The committee was chartered by ANSI in 1979 to develop uniform standards for the electronic interchange of business documents.
ECR. Efficient Consumer Response. Utilized in the Grocery Industry to determine consumer response to products, marketing, and promotions.
DEX/UCS. Direct Exchange UCS.
DISA. Data Interchange Standards Association Secretariat for ANSI ASC X12
DSD. Direct Store Delivery
EDI. Electronic Data Interchange. A generic term for computer-to-computer transmission.
EDIA. Electronic Data Interchange Association. This group wrote the original UCS and WINS standards; they currently act as Secretariat for the Ocean, Rail, Motor, and Air EDI standards. They also host the annual Pan American EDI conference—one of the world's largest.
EDICA. Electronic Data Interchange Council of Australia. The Australian EDI administrative organization.
EDICC. Electronic Data Interchange Council of Canada The Canadian EDI administrative organization
EDIFACT. EDI for Administration, Commerce and Trade. This is the International EDI Standard set by the UN and administered in the US by DISA.
EFT. Electronic Funds Transfer. The electronic transfer of funds from payer to payee through the banking system
Hub. Also known as sponsors, hubs are large companies, active in EDI, that strongly encourage their paper-based business partners to begin using EDI
ISO. International Standards Organization
JIT. Just-In-Time Manufacturing
NEX/UCS. Network Exchange UCS.
NRF. National Retail Federation
Proprietary Standards. Industry specific or company specific data formats that do not comply with ASC X.12 standards
Trading Partner. Vendor or other party with whom business is conducted
Transaction Set. A complete business document, for example, an invoice, a purchase order, or a remittance advice
VAN. Value added network
The EDI process is a very complex and integrated system to architect, configure, deploy, and coordinate. Because of the proprietary computer systems, the integration with a value added network provider (VAN) and the coordination of standards with the trading partners, the process can be detailed.
The process can be broken down into two components: the sending system and the receiving system.
The Sending system follows the data flow shown in figure 32.3
This is a complete EDI data flow diagram
The following is a step-by-step breakdown of an EDI dataflow. You will see the main steps in an actual dataflow. This is a technical overview of these steps. These steps can ba applied to any set of EDI trading partners.
1. Data is extracted from the corporate application in its native format. As the data is extracted, it is ordered into the message format. This file is saved on a record-based, user-constructed file. This file is called an Interface file.
2. The translation software processes parse through a table based on the message structure and Interface files specific for the EDI engagement. Translation software is the software that formats data into the specified EDI format. It is also used to extract data out of an EDI format. During the parsing process, data validation checks are made, codes are converted, partner profiles determined and then the data is formatted based on the EDIFACT syntax specification.
3. This file, the Interchange file, containing the formatted data is ready to be transmitted via the messaging transport via x.400 into the VAN.
4. Before sending the Interchange file, the data file is encapsulated with an envelope, defining the communication protocol and destination. The file is then transmitted. This process is called the Communications interface.
The Sending system follows the following data flow:
1. The Interchange file can be received directly or via the VAN. From the VAN, the trading partner will connect to the VAN and retrieve the data from a predefined mailbox. This requires special software to enable the trading partner to access a VAN mailbox. This is also handled in the communication interface.
2. The Interchange file is downloaded and the data is extracted out according to the message specification. Data validation is managed according to the known properties of the message. These are mandatory, conditional, range, and radix. The codes are then translated into a format used by this trading partner in-house.
3. The data sets are placed in a interface file for use in the in-house system. Additional data validation may be required in order to ensure data integrity.
4. The final step is to upload the data into the in-house system.
Exchange Integration with EDI
EDI typically relies on x.400 as the network transport and addressing scheme for conducting transactions. Exchange has x.400 built right into Exchange platform.
For x.400 support, Exchange can use x.25 protocols, or run over TCP/IP or connect with TP4. One example would be to use x.400 addressing and connectivity over an IP-based network. In this case, Exchange server could communicate with x.400 over the public Internet. The x.400 support is bundled into Exchange server (see fig. 32.4). This does not require a third-party gateway.
x.400 support in Exchange is built into the core product.
Microsoft Exchange's role is to provide a secure messaging transport over x.400 for delivering EDI documents. On the client side, several third-party developers have EDI enabled applications to work with MAPI and the Exchange client.
Currently, x.500 standards exist, however, most organizations have not deployed x.500-based global directory services. X.500 is an elaborate directory standard. Most vendors have their own x.500 interpretation, this includes Exchange, Digital's Mail Bus, Novell's NDS, and more. The interface that these x.500 vendors provide is via x.400. To clarify, you would use x.400 to communicate with a proprietary x.500 directory. X.500 standards are the core logic for today's business enterprise messaging systems.
The Exchange Message Transfer Agent is completely standards based. It is certified for 1984 and 1988 x.400 standards. This will maintain interoperability for customers, VANs and trading partners. With this level of certification, Microsoft is the first vendor to certify a product for both 1984 and 1988 standards.
Exchange is a powerful EDI platform for several reasons:
Third-Party EDI Application Support for Exchange
Several EDI software and service companies are developing Exchange EDI software tools to address data format translation from interface files to Interchange files. As well, there are EDI development toolkits available to build interfaces from legacy systems into Exchange.
The following is a list of independent software vendors (ISV) with EDI solutions for Exchange. The companies provide x.400 messaging services as well as EDI application development tools.
For more information about any of these technologies, you can contact Mpact Immedia at http://www.mpact.ca
For more information, you can contact EDISYS at +44-0-1296-330011
For more information, you can contact Isocor at http://www.isocor.com.
Exchange provides a robust messaging framework to build interfaces for EDI applications. As you have seen, several companies are providing EDI application software, as well VANs will provide native Exchange connectivity. EDI is a powerful way to extend and leverage the role of Exchange in the enterprise.
EDI is a very difficult subject to cover in just one chapter. If you are interested in learning more about EDI, you might like to read some EDI text books, as well as research how EDI can be interfaced with your legacy business application. From there, to understand the data extraction and translation process, before forwarding the data to the VAN. EDI solutions are very expensive and require special attention from application development to implementation. Make sure you discuss any EDI solution over with the application development specialists from your department.
This chapter has explained how Exchange can be used for EDI applications. The next chapter concludes this book on exchange, by providing some insight to the future of the product. For more information on extending Exchange services, see the following chapters:
Previous Chapter <-- Table of Contents --> Next Chapter
QUE Home Page
For technical support for our books and software contact email@example.com
Copyright ©1996, Que Corporation