3 ms·

I develop an internal system for a company which sells diapers to big chain supermarkets in europe. It is connected to them through EDI. These are my 2 reasons

I develop an internal system for a company which sells diapers to big chain supermarkets in europe. It is connected to them through EDI. These are my 2 reasons why EDI is hard and fucked up in my opinion: 1) syntax - we are using XML which has weird element names and values and it's mixed camel case with other styles. It's not nice or possible to read without a manual/reference 2) brokers - you connect to others throught "EDI brokers" (dunno the right name in english). Basically you don't connect with other directly but it always goes through one or more brokers which are part of some EDI union or whatnot. So for example order from chain to a producer goes like this Supermarket -> Broker -> Producer. What this means is that different brokers pass you the orders in different way. So i guess it can vary a lot. Our broker is maybe the largest in the country and yet the only way how to programatically get messages from him is invoking a Java program, which downloads the message from his servers and that is possible to do exactly once. Then it's up to you to distribute it in your company as you wish. God forbid if you corrupt the message or something. This is very bad because you have to do a lot more work than just do a few REST requests to deal with anything. It prolongs basic integration by a lot.

DennisP 5y ago
Twenty years ago I was working with EDI without XML. The format was a series of lines, each with a starting tag followed by a delimited list of values. Each transaction type had a grammar, so each starting tag could mean different things depending on its position within the grammatical structure of the transaction. We were new to EDI and had to roll out a bunch of partners fast, so we bought $60K software to help us. Turned out, that software had no understanding of the grammar; you had to use a cumbersome GUI to essentially write code from scratch to pull out what you wanted, with the only control structure available being GOTOs. Just pulling out a dozen important fields looked like a significant engineering effort. Then our partners said they required us to display to the user everything they sent. I ended up ditching the $60K software and writing my own tool with a proper parser, so I could input the grammar of a new transaction type in an hour and sort everything out right. After that it was easy. We didn't have to deal with brokers at least, we connected to everyone directly. I think the company became one of the brokers after I left.

DennisP 5y ago

Twenty years ago I was working with EDI without XML. The format was a series of lines, each with a starting tag followed by a delimited list of values. Each transaction type had a grammar, so each starting tag could mean different things depending on its position within the grammatical structure of the transaction. We were new to EDI and had to roll out a bunch of partners fast, so we bought $60K software to help us. Turned out, that software had no understanding of the grammar; you had to use a cumbersome GUI to essentially write code from scratch to pull out what you wanted, with the only control structure available being GOTOs. Just pulling out a dozen important fields looked like a significant engineering effort. Then our partners said they required us to display to the user everything they sent. I ended up ditching the $60K software and writing my own tool with a proper parser, so I could input the grammar of a new transaction type in an hour and sort everything out right. After that it was easy. We didn't have to deal with brokers at least, we connected to everyone directly. I think the company became one of the brokers after I left.