SAP Architect Matthew Montano continues his series on the Vortex Consulting blog:

Back in the late 1990s–decades before S/4HANA made its way onto the scene–my first full SAP implementation took a team of a couple dozen SAP consultants about 9 months. In addition to focusing on the successful incorporation of multiple currencies and languages, my secondary responsibility was the full EDI integration of 30+ EDI transactions across about a half dozen EDI trading partners. With just a part-time technical resource and a Windows NT EDI Server–which has less computing power than the phone in your pocket–we did it all on time and on budget.

So what’s changed since then? Today, the topic of EDI integration as part of their S/4HANA project can strike fear in even the most hardened of CIOs. Fear of exploding budgets, fear of racks of expensive servers and software licenses with fancy names, and the fear of endless consulting bills.

All because we need to exchange several hundred bytes of correctly crafted letters and numbers that represent a Purchase Order or an Invoice?

How did the everyday work of EDI integration become intimidating?

I have some theories and some recommendations on how to think about EDI as part of your next project to keep you from running away scared.

A key question is, “What is EDI?” Although formally known as Electronic Data Interchange, it is better described as Electronic Document Interchange. In its most accepted definition, it is the electronic exchange of relatively standard messages that mirror a paper document such as a Purchase Order, Order Confirmation, or Invoice. Not only is the content of the message often a mirror image to a paper equivalent, but so is the timing and frequency. Most companies use EDI standards from the early 1990s and only exchange them every 10-15 minutes. This is all fine.

There is a separate integration world where none of these norms apply. For example, integrating SAP with an internal Warehouse Management System (WMS) is very different. Sometimes the connections might be synchronous (in which both systems exchange data and there is a confirmation almost instantly). Sometimes there are multiple WMS systems that require significant transformation of the messages.

Solutions such as SAP Integration Suite (as part of SAP BTP), or third-party suites such as Boomi or Mulesoft, are built for non-EDI integration scenarios. In other words, they are made for scenarios like those I’ve just outlined.

But dragging EDI into the same integration world could unnecessarily kill your budget and be intimidating to all involved. Consider these red flags:

If you hear the term “canonical,” be wary. The concept prescribes that messages from different sources are all mapped into a single internal common structure and then mapped on to their destination structure. This might sound like a great way to simplify building and testing. But the EDI standards themselves already represent a canonical standard, one that is already a middle-aged global standard that is proven to accommodate nearly every business scenario. Additionally, when using SAP, you are almost assuredly going to use an IDoc, which is by definition a “canonical” itself.

“Canonical” approaches frequently fail because of the telephone-game problem: too many transformations.

If you hear the phrase “IDocs are dead; APIs are the future,” you might want to hang up the phone. API (Application Programming Interfaces) is the collective term usually used to describe a live connection between two systems. Terms such as RESTful, SOAP, and OData correspond to the various protocols. Need a real-time check of inventory or calculation of a price? Then an API-based integration is the approach to take. But EDI messages are like their real-world equivalent; completely intended to be handled in batch. Connectivity with trading partners is through connections, with names like AS2, sFTP, or X.400–all batch technologies, and many of them still operating on 10- to 15-minute cycles.

There is considerable effort and risk–along with minimal benefit–taking API technology into an EDI world.

Your elder EDI integration consultant will undoubtedly share many stories where an EDI message was implemented that never gets used or doesn’t deliver the benefit that was expected–despite an extensive effort to implement it.

A classic example is the Purchase Order Change (EDI 860) message. In most SAP implementations, once a Sales Order is entered, there are minimal opportunities to automatically change it. A Sales Order has been credit checked, inventory allocated, and items possibly already shipped. Expending the effort to fully integrate a complicated “Purchase Order Change” message, which is already a business exception that has minimal chance to actually update an SAP Sales Order, is likely not a good investment.

There is no shame in saying “no” to integrating some EDI messages and asking the business to just go manual. 

EDI is a very mature technology that does mesh well to SAP S4/HANA but needs to be respected for what it is and what it is not. For further experience, insight, and guidance on integrating EDI with your SAP solution, I invite you to reach out to the experienced EDI integration consultants at Vortex Consulting. Contact us at 1.888.627.3640 today.

About the Author: Matthew Montano is a Vortex Consulting SAP architect with more than 25 years of experience in Electronic Data Interchange, Supply Chain Integration, and Third-Party Logistics. His passion for good documentation and streamlined work process has yielded measurable results for clients in the consumer packaged goods, life sciences, manufacturing, and transportation industries across both the United States and Canada.

Check out his previous blog posts here: Why Years of SAP ERP Experience Makes Me Question if You Really Need that Custom Code / Time Zones in SAP: Let’s Dig In / Daedalian ABAP Source Code (aka Throw us Old Folks a Bone) / ZZXREFDETAIL–SAP’s Dreaded Universal Cross Reference Table (…that your favorite SAP functional consultant hates to see)