I’ve seen a lot of articles lately about the great coming of Web APIs and how they’ll replace standard EDI communications. In the age of Amazon, we can all agree there is a need to upgrade EDI technology, which has been around since the 1960s. But replacing it will not happen anytime soon. Amazon, in fact, is one of the largest users of EDI, and mandates it for partner communications. This also will not change anytime soon.
What is a Web API?
A web service/Web API is a collection of services that are openly exposed and used by other applications. Web services are currently the de facto integration technology for new integration projects. They simplify the ability to expose data and services to other applications. They also allow near real-time updates across supply chain systems. The reality, though, is that most APIs are developed in isolation, without input from external partners. They address the specific data requirements of the development company. This works if you’re accessing a unique service. For example, if I want to integrate distance calculations into an application, it makes sense to access a Web API for Google Maps. But does it make sense for EDI?
Here’s how it works
A typical Web API is made up of a group of methods to interact with a customer’s systems. The example below is a customer purchase order management API. The customer has exposed a few methods. For example, with OrderConfirm, we can confirm receipt and acceptance of purchase orders from customers.
This is integrated with an interface program that accesses the customer’s Web API. The purpose is to extract the information we need from the back-end system and put it into the expected format for the Web API. The system workflow looks like this:
- Back-end system triggers a required update, such as an acknowledgement that an order was received or shipped.
- Interface program uses transformation logic (code or a higher-level mapping logic) to transform data into a specific format and document structure, as required by the customer’s API.
- Interface program accesses the customer’s API; which transmits the required data.
Not a real-world solution
But in the real world, most customers have numerous trading partners. So imagine the above scenario if each customer had their own Web API.
Even with tools to manage APIs more effectively, I still treat each one as a one-off customer integration or point-to-point interface.
The importance of standards
The real benefit of EDI is not the technology. Instead, it is the industry standards that have been defined for partner transactions. This eliminates the need for one-off solutions for every customer. Web APIs will not become mainstream until industry standards are created. And that is many years away.
Phillip Avelar is a Managing partner at Advanced Solutions, based in Chicago. He works with SAP enterprises to optimize their supply chains, increase productivity and challenges the status quo. He shares his passion for solving customers problems in his blog posts, industry articles and conference talks.