EDI API - The Definitive Guide (2021)

  • Chapter 1: EDI and API Fundamentals
  • Chapter 2: EDI vs. API
  • Chapter 3: Transport, security & reliability
  • Chapter 4: Speed & size
  • Chapter 5: Cost
  • Chapter 6: Why is EDI so complex?
  • Chapter 7: EDI Message Standards
  • Chapter 8: EDI and API, together

Chapter 1: EDI and API Fundamentals

EDI stands for Electronic Data Interchange and in its broadest sense is referred to as the standard for B2B communication. EDI is used interchangeably as the established set of practices for businesses to communicate with each other. It’s not a particular technology or architectural principle, and the same applies to API.

Chapter 2: EDI vs. API

Perhaps you have read some of those articles on the Internet comparing EDI to API, suggesting that the two are mutually exclusive and can’t be perceived in accord with each other, thus prompting for a decision to choose either one but not both. This is usually a sign of misconception and is used to favor one approach over the other, depending on the author’s preference rather than any technological evidence.

Chapter 3: Transport, security & reliability

How is business data exchanged between trading partners, the EDI way?

Chapter 4: Speed & size

The beauty of the EDI format was its ability to compress data in such a way, that it is optimal in size and at the same time retains a certain level of readability by a human. Converting the nested structure of an EDI transaction to a linear set of letters and symbols and providing the specification to decode it back at the destination is how EDI works. This very functionality allows for:

  1. Smaller size, the markup renders the optimal number of letters and symbols to be able to translate the data, the compression is better than JSON, YAML, and XML (all of which need a key for every value). EDI only needs the value. For example, my first name, Kamen, represented in all 4 would look like:
  • JSON {firstName:”Kamen”} /19 symbols
  • YAML firstName:Kamen /15 symbols
  • XML <firstName>Kamen</firstName> /28 symbols
  • EDI *Kamen /6 symbols

Chapter 5: Cost

This brings us to the next topic. How do EDI and API fare in cost?

  1. Point-to-point EDI (also known as do-it-yourself EDI) example, sending a purchase order from company ABC to company XYZ:
  • EDI Software
  • AS2 Software
  • Maintaining EDI conversion and maps between ABC and XYZ
  • Maintaining EDI specifications for purchase order
  • Dedicated software and EDI resources
  • You have full control over the data and process
  • Everything is configurable and managed by you
  • Easier integration with the rest of the in-house applications
  • Predictable cost of ownership
  • How greedy is your management provider
  • How much would it cost you to maintain an often turbulent relationship with your management provider
  • Less involvement in EDI/agreements/mappings, etc. past the initial setup
  • Not operating/maintaining separate infrastructure for EDI
  • No need for EDI Software
  • EDI is practically a black box and you exchange business information with all the companies across your network using your own data formats
  • Too expensive, however, getting more expensive by the term
  • Lack of flexibility to change the channel once up and running, which more or less renders the “managed” label obsolete
  • You can never tap in programmatically into the EDI data in case you wanted to
  • APIs are widespread and the cost to host a web API is comparable to what you’d pay to your cloud hosting provider. The software to connect to APIs or build APIs is free and almost every programming language supports API.
  • API resources are widely available. The latest StackOverflow developer survey shows that web technologies are the most popular among developers worldwide. You can find a web developer far easier and far cheaper than an EDI one.
  • Data transport via APIs is secure, faster, and allows for massive data sets.
  • You can easily integrate new APIs into your existing architecture and even reuse software components.
  • APIs align well with all the latest practices in communication, software architecture, and the Web in general.
  • The API specifications are free and collaborative. OpenAPI and Swagger are de-facto the go-to options when it comes to documenting APIs and are maintained by the likes of Microsoft, Oracle, RedHat, IBM, etc.
  • API tooling is available as open-source, API adoption is fast due to the popularity of the web technologies and the developer communities.

Chapter 6: Why is EDI so complex?

So far I’ve covered some of the aspects that EDI vs. API style of comparison would normally find relatable. And I’ve concluded that from a technical, practical and financial point of view (that is on the part of the customer and not the managed provider), there are mainly positives in using API over EDI when it comes to security, reliability, speed, size, and cost. Or at least there are no downsides.

Chapter 7: EDI Message Standards

EDI’s main selling point is maintaining a rigid format for every business document. An abstraction of a document, let’s say a purchase order, or an invoice, that allows for all permutations and combination of data it can possibly ever need. A set structure with extension points in the form of repetitions, groups, optional elements, and EDI codes.

  • Collaboration, or the lack of it. EDI standardization is governed by a third party. ASC in America, UNECE in Europe, etc. They do release new versions of all business documents bi-annually, however, the pace of business is faster. To keep up companies have taken the liberty to negotiate amendments to the standards amongst themselves, bypassing the governing organizations, and hoping that they will be allowed to retrospectively sneak in those amendments into the official standards later.
  • Power struggle. It’s widely known that VICS, UCS, and ASC had a breakout and whole industries took their own way in governing and maintaining EDI standards. Let’s face it, trusting a third party to dictate the shape of business formats is idealistic with a flavor of monopoly. This caused a lot of friction and businesses wanted not only control over their data but also the formats that mold this data.
  • Natural. EDI has been here for a while. Multiply 2 versions every year, for every business document for the last 40 years. Now multiply this by the number of trading partners that connected with each other over the years. That’s like 70% of all B2B communication worldwide. It’s the nervous system of global trade. Managed EDI was created to solve this complexity which EDI was meant to solve in the first place but suffered from the same 2 issues as the ones above, collaboration failure and power struggle.
  • Poor tooling. Standardizing business transactions is one thing. Enforcing this standard is another. A correct association would be to having separate institutions for lawmaking and law enforcement as we do in every democratic country. EDI is the law, but there is no law enforcement. This means that complying with EDI is voluntary, error-prone, and subject to interpretation. The core issue is the lack of machine-readable meta-format to represent EDI documents. Just look at the example above, it’s made for humans, not for machines.

Chapter 8: EDI and API, together

I think it’s glaringly obvious. The solution to all of EDI’s shortcomings. To bring EDI to the modern age it needs a practical solution to:

  1. Have a new, free and machine-readable standard for representing and validating EDI messages, with adequate and free tools
  2. Align well with APIs
  3. Allow for easy migration of all existing specifications to this new standard
  1. A new standard for representing and validating EDI documents based on OpenAPI,
  2. An EDI translator and validator API
  3. A library of interactive, machine-readable and human-readable EDI specifications for all of the popular EDI standards like X12, HIPAA, EDIFACT, IATA, EANCOM, VDA, IAIABC, etc.
  4. A tool to convert old SEF and EdiFabric specifications to the new OpenAPI standard
  • Have a human-readable and machine-readable standard for representing EDI documents, based on OpenAPI. Here is how the format of an X12 837 P medical claim looks like.
  • Describing EDI formats with OpenAPI in YAML or JSON means that interpreting and consuming EDI data would be native for most programming languages.
  • Translation and validation between EDI messages and their OpenAPI representations are seamless. Consumers can choose whether to exchange EDI data as EDI messages or directly as “JSON”.
  • Automatic import of SEF specifications for X12 and EDIFACT.
  • Resolve the versioning and partner-specific dialects hell by maintaining distinct data models and benefiting from the nature of JSON serialization.
  • Lower the bar for adopting EDI or replacing existing EDI systems.
  • Reduce the go-to-market time for EDI implementations.
  • Reduce the cost of developing, owning, and maintaining EDI solutions in-house.
  • Reuse existing code and integrations and apply them to EDI. You don’t need separate software or hardware dedicated to EDI only.
  • Collaborate on data formats quicker and more accurately by exchanging machine-readable EDI message formats.
  • Hop on the modern infrastructure for APIs and the Web, and control your data and processes.
  • Onboard new trading partners in hours not weeks.
  • The OpenAPI EDI standard is free, anyone can create tooling for it, we do not hold any IP rights over it and happily share it with the world.
  • VANs
  • Logistics platforms
  • ERPs
  • EDI servers
  • Medical claims platforms
  • Supply chain software add-ons for EDI
  • Amazon vendor integration
  • Airline ticketing and availability systems
  • Insurance software
  • Government institutions and educational software
  • many more…

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kamen Nikolov

Kamen Nikolov

2 Followers

Founder of EdiNation and EdiFabric. Perpetual developer. Enjoys building stuff. Hoping to get better at the execution.