Edi Ws Api White Paper

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 [email protected] Please refer partnership inquiries to [email protected]

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. PO Box 600, Indian Rocks Beach, FL 33785

(813) 426-3355 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 longstanding 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

12

WSDL 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