A search term came in to this website. I came across it in our site analytics – “What is the Proper Port for EDI Communications”.
It made me think. When configuring EDI services in a server context, we often have to wrangle with secure FTP or AS2. Most of the EDI Communications services providers will give you a setup form if you are attaching to their VAN. If you re EDIINT peering, you can hassle with your counterpart Network Ops at the partner hub. Yay! There Must Be a Better Way.
When ‘old line’ EDI folks ask me, “why would I want to use a web services (WS) API for EDI, when I can just drop a file into an FTP directory, or have an AS2 connection upload?”. Well, my answer is: If you are one spokey on a hub, I get it, your EDI usage is not like the hosted EDI providers or Server OEMs that the API is targeting. There is a caveat, however – there will be 3rd party ECGridOS user and UI widgets that can be used in code and in stand alone web pages. But I digress.
By making EDI part of the OEM software or server communications foundation via the API, we can get over this “what port, what directory, what network, what VAN, problem set.”
ECGridOS allows OEM and Cloud service B2B providers to knit in EDI communications into the user and admin experience, just as other robust HTTP SMTP, POP, and IMAP network services are expected to be part of most integrations servers, ERP systems, and more and varied vertical systems.
What, pray tell, are you people waiting for, the EDI equivalent of Godot or Baudot? Perhaps a monopolized EDI industry that hasn’t seen a network innovation since the bastard compromise of AS2 and the Inovis GXS merger combined into a Fellini movie of nightmarish proportions?
Integrate EDI in your B2B comms foundation with ECGridOS, take back the night, get started with a developer account, and then, let us help you build the next, big, EDI thing.
