Skip to content

To EDI or Not To EDI – That’s the Question

#API#integration#MuleSoft
to-edi-or-not-to-edi-electronic-data-interchange-2-1

Alive & Kicking for more than Half a Century

In today’s era, where a technology’s lifespan to obsolescence is becoming significantly shorter, many companies, especially in the Logistics, Manufacturing & Retail industries are struggling with a Hamlet-like dilemma on whether to (still invest in) EDI or not. After all, EDI, which stands for Electronic Data Interchange, has celebrated its 50th birthday in 2018 and a myriad of new data exchange standards have superseded EDI.

EDI facilitated moving from a paper-based transaction of business documents to an electronic one, giving organizations key benefits like a decrease in cost, faster processing speed, less errors and better relationships with business partners and other stakeholders.

The sheer success of EDI is demonstrated by the fact that EDI is used in 90% of Fortune 500 companies, assisting in rich B2B integration. Most ERP systems, like SAP, JDE, Oracle, Salesforce, etc, have extensive support for EDI messaging. Extensive usage often results in building very complex partner ecosystems with unique integration flows, sometimes hundreds of them, especially in large enterprises. A migration to modern style data flows proves not only to be a financial challenge but also a technological and organizational one, especially as most of the connecting endpoints are not within the enterprise itself but are part of the external partner ecosystem. The majority of those endpoints have already proven themselves in production for many years, making the reluctance to change very understandable, especially if previous technological changes have not led business innovation at all.

Help! I am a Gen Y! Technological archeology is not my thing! What does EDI look like?

An EDI business document is a delimited file, looking like an ASCII, and quite difficult to interpret.

A clip of an example EDIFACT invoice message:

UNA:+.? ‘
UNB+UNOA:2+xxxxxxxxxxxxx:14+xxxxxxxxxxxxx:14+100517:1423+9519′
UNH+24459+INVOIC:D:93A:UN:EAN007′
USH+1+NSC24459+2+1+6+2+1+1::XXXXXXXXXXXXX::9+2::XXXXXXXXXXXXX::9++5:20100517:142300′
USA+1:::16:1’

Similar to IKEA’s assembling instructions which help to “create” a piece of furniture from multiple pieces of wood delivered in a box, EDI translations are needed to give the business the “meaning” of the EDI messages. The following URL has quite extensive document definitions for EDI for those who want to read more.

EDI will be Celebrating many more Birthdays

EDI as a standard has contributed, and is still contributing massively to automation efficiencies in various industries. This is what counts in the end, especially if you look at it from a business perspective.

During some large integration projects in the Construction, Pharma, Health & Shipping industries, I have been using ERP built-in mechanisms to process business documents for fast integration, especially when “another” endpoint was speaking EDI language only. In the implementation processes, I was able to leverage the accuracy of the default business document processing features in combination with the accuracy of the EDI specification.

My valuable experience with EDI so far made me come in contact with typical real-world EDI challenges and best practices on how to address those challenges:

  1. For customers who have already implemented ways to handle business processes like invoices/purchase orders etc, using XML, and now need to use EDI, an EDI <-> XML translation is implemented and the existing logic is re-used.
  2. Since most EDI messages are file based exchanges, notifications on validation issues are important. If the translated EDI document doesn’t comply with the expected structure the customer gets notified about the issue via their preferred mode of communication.
  3. ERP systems have default programs for creating purchase orders and invoicing etc. These programs can be easily triggered by GUI or other means. A particular client wanted to continue using these triggers, so we (created a system that) translated received EDI messages and directly added the information inside the database while subsequently triggering the programs.
  4. For security reasons, B2B consumers prefer authentication, which was sometimes not supported by a customer’s tool of choice. We positioned iPass in front to support security and provide the necessary security framework.

As every situation and organization are unique in a way, we have to ensure that the right frameworks are used to enable easy maintenance.

The Power of Modern Integration Platforms

In the integration world, most iPaaS providers like Mulesoft, Tibco, SnapLogic etc, support in (un-)marshaling EDI messages to more commonly used data formats like XML, JSON etc. Time tested schemes and detailed documentation available on the internet makes this quite reliable as it offers enhanced accuracy and simplifies onboarding new partners, vendors and customers.

Most important, modern iPaaS platforms offer an opportunistic migration from EDI to the latest data exchange standards, quite naturally moving the discussion from technology to a value-adding discussion for business.

Related Integration blog-posts & cases