1. 5/9/2000 EDI Messaging on ANX ® Presented by: Gary M. Morin BCE Emergis & Co-Chair Message Routing WG

2. A New Opportunity The connection of 500 large trading partners to ANX provides an excellent opportunity to move most if not all of your EDI traffic to ANX ®. Current users of EDI over ANX ® report huge increases in speed and reduced costs.

3. Choices Use traditional TCP/IP based file transfer protocols (FTP, TFTP, SMTP). Use IETF AS-1 (E-Mail) or AS-2 (HTTP) Use AIAG’s E5 or E5 2000 Message Routing Protocol.

4. Traditional TCP/IP TFTP – No Password Protection SMTP (E-Mail) –No Delivery receipt built in. –AS-1 Message Disposition Notification (MDN) requires extra processing steps.

5. FTP FTP –Currently in use by several large organizations. –No standard receipt notification. Custom receipts is worse than today’s Bisync world. –On the Internet side everything is sent in the clear.

6. IETF AS-2 Better than FTP, but there is only standard implementation guide currently available and it requires that messages be encrypted using PGP before they are sent. Over ANX ® this would be redundant.

7. AIAG E-5 Very similar to AS-2 but no extra encryption is needed. –Uses SSL for security over the Internet. –Uses built in IPSEC for security over ANX ® Being used today to send EDI to GM via the EDS Elite service.

8. E-5 2000 A major revision of the AIAG’s Guideline for Electronic Commerce Routing Over TCP/IP Networks (Document number E-5) Replaces the MIME based routing elements with XML based routing elements.

9. E-5 Requirements Reliable Secure Scaleable –OEM’s at 1 billion transactions/yr –Tier 1’s at 100,000 transactions/yr –Tier N at 12 transactions/yr Open

10. Reliable The fastest way to get your company in trouble with its customers is to drop some EDI transactions! The TP’s need to know immediately if the transaction failed.

11. Secure We have the IPSec security for ANX® based transactions. We needed a secure method for Public network (Internet) transactions. –E-5 and E-5 2000 work with SSL

12. Scaleable We have some of the biggest and the smallest companies in the world, (and everything in between) that need to interoperate. Conversion is going to be a real pain. We need to make it as easy as possible!

13. Open Can’t be tied to any particular vendor’s approach, there are just to many trading partners. Must be deployable on any platform. Standard “Off The Shelf” parts.

14. E-5 Behaviors Deliver –Sends a document to a TP Obtain –Picks up a document from a TP Retrieve –Picks up a document (requeue) List –Lists the contents of a mailbox Exit

15. E-5 Overview Server Client EDI App.

16. PushMe - PullYou If both parties have E-5 servers and automated clients then you never need to go to an EDI mail box ever again! Obtain and Retrieve functions exist for small mail box applications. We continue to map to the AIAG M-3 and M-5 Business Processes.

17. Why E-5 2000 There is ‘Open’ and there is “Open.” –Forced all “forms” to be the same Why make silicon life forms act like carbon life forms?

18. Changes in E-5 2000 Separate Silicon (machine) and Carbon (human) interfaces. (Faster) Single post to logon and to transfer data in Silicon. (Faster) Basic Authentication security (Standards) XML based routing elements (Standards) TP Callable API (Flexibility, Implementation)

19. Separate Interfaces Machines don’t need all of the interactive help so why make them go through the extra steps? You must have a human interface but we don’t specify what it looks like. No specific human interface is specified so “go knock yourself out”.

20. Single logon/post Sends the logon and the data in one package. Each E-5 behavior has it’s own URL Allows “stateless” operation so it is easy to implement a High Availability solution.

21. Basic Authentication Standards based HTTP logon. Supported by all of the big Web servers. We can move to a PKI when one is available and eliminate usernames and passwords.

22. XML based Routing Elements Routing data is in XML format. Easier to parse out the Information. Easy to move to the next step, XML based EDI.

23. TP Callable API “Have my server call your server.” Finally, a first cut at a “callable” implementation guide. Results sent back are in XML format Built in loop back to validate the setup. A logical next step, the call to a directory service (LDAP).

24. E-5 Stack Example MIME Boundary End EDI/Data MIME Boundary XML (routing info) MIME Boundary HTTP Headers Follows RFC 1867 Form-based File Upload Deliver Request

25. XML DTD’s for all XML documents are included in the specification. Adds tremendous flexibility in specifying EC documents and how they are to be routed. Provides us with some protocol independence. (SMTP, FTP, OFTP could now be used but there is no specification yet)

26. Example XML 123456 56789 Release 05/09/2000 application/EDI-X12 862 EDIGEN 12345

27. EDI/Data Package This can be literally any kind of electronic package not just EDI. –Much of the testing was done with MP3 music files. We support any MIME type so files can be “zipped” to reduce their size.

28. Other Stuff Standardized status messages. Date and Time specifications. Information about Date and Time Services. Sample Directory Schema. –Lets you know who and where to call. Silicon interface has a “Human” form used for testing purposes.

29. Current Status E-5 2000 was approved by the AIAG Board of Directory in March 2000. AIAG Document publication is imminent. Two organizations Michigan Blue Cross/ Blue Shield and Beaumont Hospital have agreed to pilot their X12 270-271 insurance verification process on V2000 starting this June over the ANX®

30. The Future Presented to ebXML for consideration as the standard transport. Michigan Blue Cross Blue Shield and Beaumont Hospital Testing in June 2000

31. Questions www.aiag.org www.efive.com Why E-5 document