When I first started working in EDI, back in the early 90’s, the systems we implemented seemed quite miraculous. Imagine, not having to re-key your customers orders and sending invoices without printing anything. It was a total game changer at the time, but pretty mundane now.
As time passed, technology improved and high speed lines started to replace dial-up modems. Transmission and receipt times were slashed, making it possible to do even more with EDI
Then, AS2 came along and suddenly businesses were no longer dependant on the value added networks to move messages from one place to another, costs dropped and even more EDI became cost-effective.
In recent years, the scope of EDI has changed radically. The established standards like X.12, EDIFACT and TRADACOMS are still very widely used but other things like XML, JSON, CSV and spreadsheets are now in the mix, and being used in very creative ways to further reduce costs and increase efficiencies.
We’ve also seen the rise of APIs, Application Program Interfaces, that allow systems to exchange a far broader range of transactions in a cost-effective way.
Their potential benefits for EDI have been, and will continue to be, enormous. The ways in which APIs can used has expanded the overall scope of EDI into areas that couldn’t have been imagined back in the 90’s, and the resulting cost reductions have made EDI accessible to more and more businesses.
Developments like this, and the possibilities they enable, make working in EDI continually challenging and rewarding, the goal of which is always to do more, do it better and do it cheaper.
In the early days of API development, the dominant technology was called SOAP (Simple Object Access Protocol). It was very successful in many areas of business, solved a huge number of problems and allowed designers to create systems with an unprecedented level of automated integration.
Although the “S” stood for “Simple”, there was room for improvement. Some SOAP transactions could be quite challenging to comprehend if we’re honest.
More recently, REST (Representational State Transfer) has proved to be a more accessible option than SOAP. It too has been very successful and is now generally seen as the preferred option for designers and developers who need to integrate systems quickly and reliably.
Today, all major applications like Xero, NetSuite and Dynamics 365 Business Central provide REST options that open up all sorts of possibilities for systems integration.
Similarly, the on-line marketplaces like Amazon and eBay provide REST interfaces that can be used to automate virtually all interactions with them.
Combining REST technologies with an EDI system that’s designed to take full advantage of them (ZEDI for example) has made automating business processes more functional and cost-effective than ever before.
For the purposes of system integration, APIs can be further divided into “Application APIs” and “Marketplace APIs”.
Both of these are subjects of other videos but in brief, an application API is used to interact with a system used by your business, such as an ERP, and a marketplace API is used to work with companies like Amazon, Shopify and eBay.
Increasingly, we’ve been working with a third category of API, those that are operated by your customers and suppliers. These “Partner APIs” are used to connect your business systems with those used by your trading partners. A recent example is a motor manufacturer that imports raw materials from overseas. It needs to get PDFs of import documents from their forwarder, and post them directly into their business system. To do this, they provide the forwarder with an API that allows its EDI system to automate the delivery of those PDFs.
For more information, there are two other videos you may like to watch. The first talks about the use and benefits of application APIs, and the other discusses marketplace APIs.
Thank you.