Newsgroups: bit.listserv.edi-l
Date:         Sun, 16 Aug 1992 15:21:58 -0700
From:         Bill Laidley <WLAIDLEY@BCSC02.BITNET>
Subject:      Application programming interfaces

 In recent discussions after work we've been bouncing around two ideas that I'd
 thought pass on to the network for comment.

 ** One **

 There is a growing trend in operating systems (like Windows and OS/2) and
 applications to provide an applications programming interface (known to the
 world as an API). An API allows an application to use another application to
 accomplish a task, rather than re-invent the wheel. It saves development time,
 other than the time required to built and document the API's (the
 documentation is crucial). Some examples- a REXX program running under OS/2
 which uses the Communications Manager API's to connect to an IBM mainframe
 running MVS and DB2, to download data to be processed on the PC and then send
 it as a fax to trading partners. Or a REXX program that uses OS/2 Database
 Manager API's to create a database, define the tables and load the tables from
 previously downloaded data. Or a REXX program that uses the Database Manager
 API's to allow it to evaluate the quality and consistency of the data and
 store the result in a table for later inspection. The examples are real- I did
 the last 2, I've seen the first one. The key thing I discovered (other than
 the need for excellent documentation) is that it is an incredibly effective
 way to build applications.

 There are 2 questions for EDI and API's:

 1. When are we going to see EDI translators which support API calls?
 2. Are we going to define a standard for the API interface?

 Question 1 I can answer. Today, but not on PC's to my knowledge. IBM's
 DataInterchange/MVS was designed from the ground up as a set of API modules.
 The DI/MVS application program that you run just calls the API modules.
 SoftCare Consulting's TradeLink is similar, but Unix based.

 Question 2 is more difficult. A number of organizations (like IBM, Microsoft
 and others) have been working on a defined set of API calls that accomplish
 specific tasks. This would allow an application vendor to develop a product
 that uses API's, and to not have to create many versions of the product to
 suit the differing API standards (unfortunately Microsoft has decided to
 pullout of the process and develop a separate standard - sometimes I wonder if
 Bill Gates has a problem with testosterone). If there was a defined API
 standard for EDI functions, application developers (applications like
 accounting, inventory, purchasing...) could develop integrated EDI
 applications, and the buyer purchases the EDI software as today- but does not
 have to worry about integration, as that is largely done by the application
 vendor. I think that it is a good idea, but who leads the charge? ANSI X12? A
 vendor association (is there one?)? A user group?

 ** Two **

 The other thing we were discussing (which fits in nicely with the API
 discussion above) was standards dictionaries in EDI packages. Rather than rely
 on the software vendor to supply new releases it would be nice to get them
 from the standards body (DISA for example) on disk, or via a network and be
 able to load them into your EDI software. This would require agreement on the
 format for the standards dictionaries, and for the vendors of EDI software to
 supply a utility to load the standards. Ideally the utility would allow you to
 load selectively- for example: only what was needed for specific transactions
 in a specific version (eg. 850 & 855 in version 2.4). This approach should
 reduce annual maintenance fees to vendors- since they would notbe acting as
 agents for DISA, and increase DISA's revenues. The net cost to EDI users would
 likely remain the same, but more under your control.

 Footnote for those wondering why the dictionary discussion... we use Supply
 Tech products on PC's and on an IBM mainframe. The releases we use (mainframe
 is 1.2, PC is 2.4) both ship with dictionaries which are X12 version 2.1. If
 you need something more up to date you enter it by hand- which is tedious,
 error prone and a damn nuisance. There are other redeeming qualities, but I do
 wish they took a different approach on dictionaries.

 Regards, Bill Laidley
 EDI Expert Team
 BC Systems Corp. Vancouver (604) 660-9705
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU