A Web Services API for Accessible EDI Communications Services

Alan D. Wilensky, Analyst1

bizQuirk Product Sector Strategies

Abstract

The world of supply chain e-commerce is a vital business sector, drawing together partners of disparate size, connecting
enterprise systems, and putting tangible goods in motion across global trading communities. EDI (electronic data
interchange) is a key enabling technology for global commerce. Once the sole province of enterprise systems, EDI is
progressing with increased SME 2 adoption of the technology. While a lower entry hurdle is encouraging, challenges
abound for most small and medium businesses attempting to successfully adopt EDI.

The premise of this paper is that EDI is better implemented via a Web Services API. By affording a more a la carte model
of global EDI transit, as opposed to monolithic, externally configured, per connection models currently in vogue,
integrators and programmers can deliver the precise functionality required. In other words, EDI communications can be
built in, rather than added on. Particularly in the area of custom software and systems integration, architectures that
implement single attachment points under software control are a more elegant and lightweight methodology.

The EDI gap today is evinced in a lack of standardized tools, and an industry-wide mindset that can only be described as
provincial. A survey of web e-commerce tools for supply chain and partner management seems like a parade of the
ponderous, closed, and costly. This lack of openness and ready deploy-ability directly affects the mid market’s ability to
rapidly adopt solutions that enable their trading partner processes and relationships.

Although a number of products and services have emerged to ease trading partners across the interconnection abyss,
most of these solutions seem to deliver connectivity at the expense of flexibility and reach. While hub and P2P
architectures are certainly innovative, they seem to reinforce practices that result in increasing the logical distance
between potential trading partners, and in some cases, inhibit their serendipitous discovery3 . In our global system of EDI
communications, the author feels that the industry should be maximizing opportunities for peer trading relationships, not
attenuating them.

In this monograph, the author will examine one major aspect of EDI commerce - the transit of EDI documents between
trading partners. The lack of tools and API’s for enabling EDI communications within custom and OEM applications is a
sore point dogging the developer and integrator communities. The ability to ‘build in’ EDI communications as an
embedded function should be a standard tool in every e-commerce programmer’s bag of tricks. Actually, it should be no
trick at all to configure and send EDI messages.

About the author:

Alan Wilensky is a principal analyst with bizQuirk LLC, product sector analysts for industrial, technical, and vertical
software systems. Loren Data has retained Bizquirk for contract product management and industry relations advisory
services.

Please refer developer inquiries to developers@ecgrid.com

Please refer partnership inquiries to tgould@ld.com

1 Monograph commissioned by Loren Data Corp.

2 Small and medium business /enterprise
3 For example, via trading partner ID directories -living entities that grow with a network

Loren Data Corp. (813) 426-3355

PO Box 600, Indian Rocks Beach, FL 33785 www.LD.com
Loren Data Corp. Opens Global EDI Routing to Developers via a Web Services API

Loren Data Corp’s ECGridOS is a Web Services API that bridges the EDI implementation gap.
ECGridOS provides global EDI document carriage via a WS standard interface, can be used al a
carte4, at low cost, and presents virtually no barrier to rapid technical implementation.

The leading product focus at Loren Data Corp is better partner processes using EDI as a catalyst for
change. In addition to the ECGridOS API, Loren Data’s product road map plots a course for services
that facilitate the creation of trading partner relations via open directories, inter-partner process
management using BPM, and the applications of new technologies for automated EDI data
reconciliation.

2 or More Words about EDI

For the uninitiated, without taking a major detour, EDI is the intermediate format of record for
business documents exchanged between computer systems5. Just as small businesses have relied
on paper records for purchase orders and more complex industry manifests, the ANSI X126 standard
expands and standardizes the scope of such documents and their reliable carriage.

X12 covers a lot of ground, and there has been much progress made in abstracting complexity out of
the implementation. The push to increase X12 availability while decreasing complexity has converged
with a push to get EDI into the hands of ever smaller businesses. In order to facilitate trade with larger
upstream partners, the industry has struggled to offer simpler solutions for the SME, while leaving mid
systems integration to the wolves. Summary - standardized business documents are good. Complex
and voluminous specs and tools are bad. Lets take a closer look:

There are numerous systems (and tools) for the production, modification, consumption, and
integration of EDI documents with capital line of business systems (SAP, Oracle, other accounting
and inventory management). Conversely, There are very few tools, systems, or options for
unbundling EDI global transit from the ponderous world of big solutions, long contracts, or the
alternative of rather insubstantial retail EDI communications services7 .

There are likewise few processes for automating the establishment of trading partner technical
relations and peerage. The EDI implementation guides of major retail and industrial buyers are
legendary for their opacity and stentorian tone. Such Byzantine processes of enabling EDI
connections between partners of unequal size has left us with an industry of specialists and a cohort
of privileged resellers.

4 Flat rate monthly and annual unlimited licenses are available.

5 and increasingly, humans
6 See www.x12.org
7 Services Bureaus, outsourcing, web based EDI mail boxes, FTP - all with options for integration
EDI services that are conveyed to an even partially disenfranchised population of small and mid-sized
trading partners seems a less than effective strategy for growth of the industry. More open and
transparent models for communications and partner processes would enhance the uptake of EDI and
stimulate opportunities for technical services at all levels.

EDI the ANSI document & EDI the system of global trading partners.

These two worlds are joined by a legacy, not by technical requirements.

There are numerous alternatives for sending EDI to a trading partner. The predominant methods
remain the VANs,8 commerce hubs, peer to peer methods9, and hosted solutions. All of these have a
place in the pantheon of global commerce.

EDI partner setups vex the large and small enterprise alike; the difference in achieving operational
success seems to lie in a larger enterprise’s ability to resource up and absorb pain.

EDI partner setup issues are addressed at various points along the solution provider value chain,
including outsourcing EDI, retail mailbox services, and numerous reseller packaged options10. On the
other end of the spectrum, we have major IT vendor gateways (IBM WebSphere PG) and VANs
(Sterling, et al) proffering major supply chain integration regimes, while the SME is often priced out of
the market due to their customization requirements, or alternatively are buried in a plethora of
compromises.

The lower end options often seem an anticlimactic afterthought, inflexible, almost engineered to
persuade a mid-end client to reconsider higher-end solutions. The artificial merger of EDI
communications and EDI Big-Co integration consulting has resulted in an, ‘all you can eat or starve’,
mentality that falls far short of serving the market in all of its wonderful complexity.

Smorgasbord, Starvation, or a Golden Mean?

A domino had to fall in favor of appropriately sized options for freelance developers and systems
integrators wishing to add EDI transit to their toolset. Loren Data therefore adapted the Web Services
Remote procedure calling standards to their ECGrid EDI communications repertoire.

The ability to produce EDI from CLOB 11 system data sources is a fairly common add-on in most
IDE’s. There are numerous X12 EDI formating and mapping objects being offered as code libraries.
Free tools also abound on forums such as Source Forge. In short, things have never been better for

8 value added networks

9 EDI over Internet
10 Fax Form EDI gateways, Postal mail to EDI, voice to EDI
11 capital line of business
EDI document production and consumption.

For the world of partner communications, the state of the industry is less than ideal, particularly for
the custom programming constituency. Summing up our interim analysis, then:

On the too much goodness side, we have major vertical software and EDI partner gateways
purveyed by Value Added Networks. These are powerful systems that take a soup to nuts approach
to EDI production and routing. The conjoining of EDI documents and transit routing is one of legacy;
they are in this case inseparable by convention, not technical requirements.

Furthermore, the commitments that come with these large solutions loom as large as their branding
suggests, and the communications services thus afforded are purchased dearly, by the kilo character
- an anachronism in a flat rate world of e-commerce. Still, these solutions are established and
venerated by major manufacturers and distributors that require power and flexibility.

On the side of scarcity, we have EDI services resellers who provide Web Based forms, service
bureaus, numerous application specific connectors for GL, mid inventory, and further numerous
vertical market applications. All of these serve a market segmentation purpose, and for those whose
needs fit the tools, all is well.

The ISV, Developer, and OEM market for EDI communications

Yet, a void permeates the custom software industry. Their complaint is that feasting on major EDI
gateways or starving on FTP connections is just not satisfactory for their professional purposes.
These industry anchors and journeymen have few problems connecting to data sources, coding
within the ERP IDE, or formating and producing EDI under program control. Their gripe is long-
standing and legendary, “Let us call and connect to the world of global trade from within our
applications”.

Some of these plaints come from deep within the OEM tools and capital software vendors. These
grand forges of software excellence really want to call, connect, and send EDI. The mid-ware shops,
too, want to call, connect, send, track, and report.

What is missing is an al a carte method for programmers to directly invoke EDI transit functions. For
these services to become a reality, it took many long years of toil for one company to create a system
of global interconnects between major commerce providers, and only then, to refine and offer such a
service that made perfect sense to custom software developers.

Loren Data and ECGrid + Web Services = ECGridOS

Loren Data’s ECGrid is an EDI message gateway and services broker providing routes and peer
connections amongst marquee electronic commerce network providers.

ECGrid grew out of CEO Todd Gould’s lengthy experience in Federal EDI and inventory acquisition
systems. His work evolved over the years, eventually resulting in a functional model of reliable
messaging and interconnection services that are considered best in class for trusted, accountable
EDI message delivery. Volume EDI handlers use Loren’s ECGrid; its success is a testament to Todd’s
organization and the technology that sustains this small, well run business. This quality of trust by
one’s peers at the highest technical echelon can’t be purchased with a pallet of 1U servers.

The ECGrid system provides network operations tailored to the needs of primary EDI transit
providers. Loren Data and its ECGrid infrastructure is, however, as much an expression of
experience and the long-standing business relationships that grew over the course of building a
company that services the EDI industry with distinction.

ECGridOS is the Programmer’s Gateway to Loren Data’s ECGrid.

Based on the W3C Web Services standards, these 90 odd calls can be consumed by any
programmer, using any popular development environment or software framework. In a surprisingly
deft example, I was shown how the daily business of EDI transit could be glued into almost any
program or capital line system with a handful of API calls.

Fancier footwork, live message status reporting and such, will require the programmer to use more of
the toolkit, but in no way are any of the ECGridOS calls arcane. ECgridOS calls are wrapped in
standard WSDL12 (Web services description language) for instant importation into Visual Studio,
Eclipse, or any IDE. The ECGridOS on-line documents allow for live, interactive calls via web forms,
which are perfect for testing and debugging.

Without bogging down in the technical minutia of the functions, ECGridOS is divided into the following
families of calls:

System Access & User Management

Provides login/logout and other basic system access functionality.
Network/Mailbox Management
Create and maintain Networks and Mailboxes
Trading Partner ID Management
Add, edit, delete and manage all aspects of Trading Partners assigned to a specific Network/Mailbox.
Interconnect Management
Create and manage Interconnects between IDs throughout the ECGrid Network.
Carbon Copy Management
Manage Carbon Copy interchanges for Trading Partner pairs.
Parcel Management
Send and receive mailbags, interchanges and other payloads over the ECGrid Network.
Reports
Status, Stats, and Information

12WSDL is expressed as a URI, a string, essentially that references the function calls for importation into a developer’s
toolset
The strategic impact of a Web Services API for Global EDI Transit

Sometimes a technical tool or service is so simple and manifestly useful, that an analyst’s verbiage
only serves to obfuscate the glow. Hopefully, the author has slightly dispelled the darkness that has
settled over such an opaque subject as EDI.

With the advent of ECGridOS, programmers can deliver EDI transit services within their applications,
integrate EDI functions with their native UI, and exercise total control over the carriage of the data
they choose to send and receive. OEM capital software vendors and vertical ISV’s, as well as VARs,
can now make a choice to build in EDI services and convey these services to multiple clients, over
the course of many projects.

This is an entirely new method of invoking EDI messaging services within application software code,
and represents an initial, foundational step in a product roadmap that Todd and Loren Data are taking
to market.

Putting the control of EDI messaging into the hands of developers, integrators, and OEMS should set
the stage for a more democratic application of EDI as an integral part of the workaday systems we all
use; from on-line accounting, to all those simple (and not so simple) fragmentary and industry specific
solutions.

EDI as bolted on, as an external system or afterthought, is no longer mandatory. It seems that we can
look forward to more integrated solutions coming from top ERP vendors, as well as from local
integration shops contracting one-off projects. If Todd can get ECGridOS into the mainstream, there is
a definite possibility that this is just the first step toward making EDI as widespread as the shopping
cart API has become in web commerce.

More Information on Loren Data:

www.ld.com

More Information on ECGridOS

http://ecgridos.net
Technical Specifications

Standards:

 SOAP v1.2 RMI via HTTP

WDSL Services Wrapper for quick implementation in most IDE's (Visual Studio, NetBeans, Eclipse)

 ECGridOS System Key Parameters:

 Interconnected VANs and ECSPs: 44

Direct Connects (Major Hubs): 45

 
Subscriber QIDs 16,493
System Routes 39,636

v1 (World-Wide EDI) launched 1997

v2 (ECGrid) launched 2001

Average transit < 15s

Data Channels: FTP, SFTP, HTTPS, AS2, Web Services

Channel Security: IPSec, SSL, SSH

 

API Calls Grouped by EDI Functions:

System Access & User Management

Network/Mailbox Management

Trading Partner ID Management

Interconnect Management

Carbon Copy Management

Parcel Management

Reports

Total Number of API Calls - 90

Typical number of calls to get started with ECGrid OS - 12

See ECGridOS API documentation online for simple explanations and code samples

Email Loren Data Developer support to get a free and functional test account