Not seeing a whole lot of value of SfEDI over just writing a StringBuilder if you want to treat EDI like a CSV file. http://www.X12.org (once their servers are back online) provide XSD schemas that you can generate (http://www.liquid-technologies.com/online-xsd-to-cs-generato...) classes from that would provide full validation of an EDI document. Those classes would then allow you to serialize/deserialize from POCO to XML which most EDI providers (http://www.spscommerce.com) support. The validation piece of that is key to making sure your documents are valid for the EDI translators that will be checking your documents prior to them getting to the supplier/customer.
Thanks, I was unaware that X12 provided those. Have you used them with success?
Truth be told, sfEDI is as much an example of how EDI could be done simply as anything else. (I probably should have provided an example file generating a full document to show that). The main value that sfEDI has is in the validation performed by the Element class, which I suppose could be done just as well using string utils, since that's basically what it is.
The other advantage to treating your document like lists of segments and segments like lists of elements is that you can use things like LINQ to read, modify and update them. Obviously sfEDI is a work in progress, but I think that has some value. Again nothing you couldn't easily implement yourself, but that's sort of the point.
We weren't able to use an EDI provider like SPS and most of the libraries that we tried that went directly from C# to EDI had issues that we couldn't rectify, which is what led to this solution.
Electronic Document Interchange. It was one of the early ways of communicating different documents electronically. Things like invoices, orders, health documents, shipping manifests, etc. It's pretty important for coordinating supply chains still.
4 comments
[ 2.9 ms ] story [ 15.8 ms ] threadTruth be told, sfEDI is as much an example of how EDI could be done simply as anything else. (I probably should have provided an example file generating a full document to show that). The main value that sfEDI has is in the validation performed by the Element class, which I suppose could be done just as well using string utils, since that's basically what it is.
The other advantage to treating your document like lists of segments and segments like lists of elements is that you can use things like LINQ to read, modify and update them. Obviously sfEDI is a work in progress, but I think that has some value. Again nothing you couldn't easily implement yourself, but that's sort of the point.
We weren't able to use an EDI provider like SPS and most of the libraries that we tried that went directly from C# to EDI had issues that we couldn't rectify, which is what led to this solution.
For instance take a look at these example files:https://secure.edidev.net/edidev-ca/help/Sample_Files/Sample...
I think for new development, it's been largely superseded by things like JSON, but for many applications, it's still kind of the thing.