Our EDI code probably has multiple if blocks for every customer we communicate with.
Implementing EDI is not for the faint of heart. For the variations I worked with, there was little useful documentation, I learned mostly be reading existing code. I would hate to have to start from scratch.
I wrote an EDI parser from scratch some years ago (2 to 5, really don't remember). Almost until the end I kept second-guessing myself. It all looked so flimsy.
Eventually I made a second parser that utilized a parser-combinator library (the first one was hand-rolled) and devised extremely detailed property tests that I ran against both parsers. Only then did I feel confident.
Naturally, in production the code crashed on the second day because OF COURSE the senders didn't obey the EDI[FACT] spec and had quirky deviations from it.
Shit like that makes people retire to the mountains and never touch a computer again, man.
This is so true. Am in logistics so can't speak to other verticals but every-single-implementation has something unique to it. Either they're on a version we haven't tested on, or they only support some date/time formats, or they have custom codes, whatever.
Also in logistics, and agree. There is danger in over-promising with customizations. If you're not careful to you can spend more time and money meeting what the customer wants than the actual business the customer brings in.
Agreed, everyone needs something just a little different. And at least from my experience, the platforms and systems that build the integration are essentially disparate and held together with I.T. brand duct tape.
I worked at a healthcare company at my last job and dealt with the X12 EDI. We had several ETL processes just to convert X12 834s (benefits/membership enrollment) into a common file format because every client seemed to do something different that was not part of the spec. It was hard because we would get the data from clients and since we were taking their money we had to accommodate their butchering of the specs. The thing is, though, that many of the files we received were generated from a COBOL program and then moved to our SFTP server. It isn't like there are many (if any) COBOL libraries that validate or enforce the standards and it isn't like they would be able to just update their COBOL programs to make API calls either.
I second that; it is the core of all EDI issues. Outdated software and ancient complex maps that no one dares touch. That's why so many adapter/data cleansing projects spring up to isolate the COBOL-style software from the rest.
I used to do implementations for an EDI provider. They were almost always custom. I am shocked there’s a belief that it isn’t custom. Most projects took weeks to just setup a single partner relationship.
There are companies that can help with EDI integrations so that both ends can use their "flavor" of EDI and they do the translation. SPS Commerce is one such company I know of. Not affiliated, but we do use them at my employer. I don't work on that team, though, can't offer any thing in terms of ease of use, pricing, etc.
Vans sound convenient but are really just another potential problem in the chain. I only use them when the other side insists on some truely inconvenient protocol I don't want to have to set up and maintain a special windows vm just to run a special client for one customer-of-a-customer.
Implementing EDI is not for the faint of heart. For the variations I worked with, there was little useful documentation, I learned mostly be reading existing code. I would hate to have to start from scratch.