EDI (Electronic Data Interchange) is a proven technology since early 1980s for the exchange of information between enterprises and organizations. EDI formats such as EDIFACT, ebXML and EDIG@S are the standards for data exchange in major industrial sectors such as transport and logistics, distribution, manufacturing and utilities. The use of EDI is particularly prevalent in supply chain processes.
EDI provides a strict framework for well-coded business processes where all parties agree on specific formats for business documents to be exchanged such as invoices, purchase orders, shipment notices. EDI also defines advanced rules for dealing with content, and the relationships between items in a document – such as an invoice number or the amount billed.
EDI exchanges, historically present in the supply chain industry, allow for a solid structuring of data, especially for B2B exchanges. However, EDI is not fit for integrating different vertical software tools (CAD / CAM, PLM, MES, etc.) that are not natively designed to communicate with one another, nor with the millions of IOT objects, nor with the sensors, manufacturing robots, and the products in the course of production which in the future will be equipped with communication mechanisms.
APIs (Application Programming Interface) allow new types of interaction and transactions by exposing the functionality and services of an application to the outside world. The applications can thus consume the services of each other, giving rise to a data exchange.
The concept of APIs is not new. Over the past decades, software has used APIs to integrate modularly into an information system. The recent introduction of the Representational State Transfer (REST) protocol has made it possible to provide API services to the outside world of mobile and cloud applications. Via APIs, customers, partners and employees now have access to business and data services at any time on any device and from any source.
A communication approach by APIs is a good way to respond to new communication requirements for both B2B and A2A settings. Given the volume of data and the disparity of systems involved, efficient data flows within vast industrial ecosystems (tools, machines, production lines spread over several geographical sites, production and logistics entities, etc.) requires a well thought-out rationalization.
An ideal remedy in this case would be to consolidate the integration and exchange environment into a single system that governs the flow of both EDI and API data transactions. Such a system would allow centralized visibility across all data streams, accurate monitoring of enterprise performance, and enhanced security. It would also make it possible to monetize data by ensuring that client and partner commitments are visible and measurable.
The following table highlights the differences and complementarities between EDI and API data integration systems:
Examples of EDI-based transactions include the exchange of standard documents such as purchase orders, shipping notices and invoices. B2B applications via the REST / Web Services API include shipment traceability, exception handling on damaged items, or interrupted processes. Finally, examples of B2B applications that can use either EDI or Web services or REST APIs include customs declarations (such as manifests) as a consumed service, and the corresponding response as an exposed service.
API-based transactions can implement complementary services that are not integrated with EDI standards – services that provide visibility into transport tracking, volume statistics, SLAs, and error rates, for example. They also include interactive handling of exceptions such as transport cancellation and exception notifications.
Integration and Analytics in Supply Chain 