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 the de facto integration technology for 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.

OrderManagementAPI

Order management API

 

 

 

 

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:

  1. Back-end system triggers a required update, such as an acknowledgement that an order was received or shipped.
  2. 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.
  3. Interface program accesses the customer’s Web API; the required data is transmitted.
Enterprise WebAPI customer

Enterprise Web API customer

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.

Enterprise use of WebAPI's

Enterprise use of Web APIs

 

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.

 

 

Phil Avelar is a Senior SCM consultant at Advanced Solutions, based in Chicago. He shares his passion for solving customers problems in his blog posts, industry articles and talks. When he’s not writing, he’s working with customers to develop and apply innovative solutions to common problems in the supply chain.

Pin It on Pinterest

Shares
Share This

Share This

Share this post with your friends!