We come across legacy issues all the time, but they are legacies of dramatically differing qualities. We of course encounter those new to EDI transit; these souls are often wrestling with the EDI documents and all the fun that brings. We also encounter old blades, EDI experts that have a list of wants and grievances that for some reason, have not been addressed by their standard tool sets.
For new and old blades of the EDI world, we seek to answer the most pressing questions that address their legacy issues, such as…why an EDI API, why ARR (All Routes Reachable), why is this single point of attachment via Standard Web Services superior to FTP, AS2, hubs, etc.
Ok, you asked, you got it. The short version:
Superiority of an API to FTP and other methods:
The ECGridOS Web Services API integrates tightly with application code, or is easily invoked by integration services that import WSDL functions. Since the EDI functions that are controlled by ECGridOS are called by your program, you can build in all of the functions that have traditionally been configured via external systems. Whereas FTP file status is potentially available to a programmer, the control of the EDI parcel is really not under your program’s control. ECGridOS manages the entire life cycle of EDI peering, sending and receiving. ECGridOS also has functions for getting tracking and manifests for reporting delivery.
All of these functions can be invoked from the user or admin code, therefore obviating the requirement to check an external system for status or configuration.
What is so special about ARR and SPA? (All Routes via a Single Program Attachment):
For those working in an IDE or SOA /ESB environment , who are eager to deploy custom EDI transit functions with totally transparent routing, ECGridOS is the only API in town. Loren Data Corp is all about robust routing – we are VAN partners, not competitors. We provide complimentary per use attachments and transit brokering for your application code, we do not sell or service major ERP and integration servers. (although, SAP and the like can use ECGridOS, as with any similar Web Services function).
ECGridOS will often be used in concert with VAN services on the upstream side; so you see, while Loren Data brokers wholesale transit for VANs, we also provide custom software developers with the same robust routing transparency via a per connection model. We help you integrate at a more fundamental applications level. So, go ahead and take EDI to new markets, make new connectors, create hybrid internet and commerce applications, and leave the routing to us.
- For vendors that provide connector-ware for GL and inventory – ISV’s, I am looking at you – ECGridOS is a better way to manage EDI messaging.
- Platform providers: SAAS, PAAS, SOA, ESB – there is no doubt that EDI messaging should be a default feature of your hosted service.
As most platform vendors have been concentrating on data translation, and most of these platforms have add on’s for EDI mapping and translation, the next step is to make EDI global transit as ubiquitous a messaging feature as email. ECGridOS does just that – it is the last program attachment you will need for EDI communications.
In summary, for those delivering custom code, connectors, and per-use attachments to global commerce, the era of the EDI communications API is here, and is superior to other external methods of managing EDI messages. Loren Data, as the provider of this service, brings over a decade of experience in inter-network routing to the ECGridOS API, removing the burden of configuring multiple VAN, AS2, or FTP interfaces, while greatly facilitating relaible trading partner connections.
Tags: API, E-Commerce, EDI, Electronic Data Interchange, VAN
