How can you connect with EDI networks and communities?

Heterogeneous systems are a reality. Involving various platforms with varying capabilities. New generation applications expose / consume API. Certain legacy systems though, still rely on EDI messages since it is standardized format. Unfortunately, using EDI messages has drawbacks. It is asynchronous, gets complicated with customizations, and becomes time-consuming to onboard new business partners. Consider EDI 850 (Orders) being received and processed in batches. Can you ensure that the available inventory is honored on a first-come, first-served basis? In today's world, can you actually afford to send order confirmations on a daily basis? API-led synchronous integration will eventually take over. Until then, best of luck with EDI.

One big thing to remember is Standard in EDI doesn't always mean being compliant to those Standards...lol Everyone can debate over the standards. Basically a company will ask for a file format to be exchanged and they want it to work how they want it to work. Unless you are the Big Company you will have little say in how the file format will be exchanged and what rules the Big company will enforce.

It is always a challenge to fine tune the EDI standards as per the customer EDI guidelines and this needs a thorough understanding of requirements and making it fit to EDI standards. There is no as such fixed template for this and hence so every customer brings an unique challenge in charting out the EDI mappings for various message types.

There are different protocols set to connect with EDI networks and based of industry requirements. Few are as below. AS2 and VAN ( Value Added Network) with SFTP is most common. Gas and electric industry uses Naesb protocol for file exchange. These are protocol for X12 and EDIFACT type of documents, XML and JSON is mostly uses SFTP and WebAPI.

XML is the right answer here. Alternatively - JSON. I disagree with the fact mentioned here that EDIFACT is standard for Europe. Yes, it is widely used but is legacy in many countries and becomes less and less common. Even such a conservative country like Germany has their own ZUGFeRD stadard for invoices (which is pdf combined with xml).

From my perspective API is also a communication that should be included. Because most feel EDI and API are separate but by definition EDI stands for Electronic Data Interchange. API falls into EDI as a whole by definition. The file formats exchanged in API is JSON or XML. It all comes down to the flavor of REST or SOAP.

None of the EDI communication - guarantees - technical non-repudiation features without a VAN. My clients and their partners moved many EDI interfaces to RESt API based integration .

We still use lot of FTP connections to exchange the data between client and us. We are also using real-time or near real time feeds like kafka feeds as well for some of the projects and clients.

5 of EDI operators I had dealt with have APIs. In some rare cases they offer SFTP. And if the partner at the other end has old infrastructure and all those ancient EDIFACTs, then AS2/X400 can be used.

Hmm API, XML to my knowledge are not standardized where as X12,UN EDIFACT is covers most if not all msgs from order to delivery, transportation, warranty, various invoicing, etc.. Standard meaning msg’s format, structures, qualifiers ban be used all the trading partners instead of MFT, Proprietary formats.

I don't agree that it should be an EDI operator business only. In a world where digital security awareness is increasing, the ability to control and do most things in house becomes more important than ever. I would say that it's more important to choose a mapping tool/middleware that is flexible and easy to understand, learn and work in. The days of coding integrations are over and in comes the No Code solutions that saves companies hours of coding and offer the ability to do the mappings without the need to know code.

That should be EDI operator business. End users shouldn't care about it so they don't have to implement mapping tool for each partner.

Mapping Rules and Functions built with your Business processes in Mind. You could have Pre-processing of the Data, Post processing of the Data and Data Validation in your Mapping.

I too agree Now-a-days Using Mapping Guidelines Business also takes interest in Mapping processes. It's not purely Technical process anymore, for example Simpler Documentation from Mapping Guidelines MAGs from SAP's Integration Suite!! Involvement of Stakeholders while Mapping the EDI message will significantly reduce post Go-Live issues and gaps at requirements.

EDI integration and automation modernize operations by streamlining data exchange, minimizing errors, and expediting functions like order processing, saving time and costs. This ensures real-time data synchronization for a unified business perspective. Integrated EDI systems enhance collaboration, improve supply chain visibility, and boost satisfaction, contributing to data consistency. Aligned with industry standards, EDI facilitates compliance, empowering businesses with proactive decision support through intelligent workflows and predictive analytics. Ongoing enhancements in EDI integration are crucial for businesses to stay agile and competitive, adapting to market demands in an evolving landscape with sustained operational efficiency.

Alot of Small businesses might not have Automation and may need to rely on what is being referred to as Web EDI. This may call for more user intervention to meet the needs of a Trading Partner. Which that is ok. As you grow your business you will want to figure out how to reduce any user intervention and look to automate.

Yes, It's very critical to do this with collaboration. We need IT management and Trading Partners to be on board to work as a team for the successful execution of any EDI implementation.