- 1 comment
i think it would be great to get EDI interchanges packed as an object (e.g. EdiInterchange). That would make things, like validating, a little bit easier if someone wants to work with the interchange as a whole.
At the moment i have to validate all read objects of type 'IEdiItem' myself. Furthermore i have to build an interchange structure and check if it's valid, too.
Thank you for suggesting this, however there are multiple reasons for not doing it, such as:
1. The reader should be considered a derivative from .NET's StreamReader (which it is in fact), that is - reading data from a stream in a forward-only manner.
2. The reader should be able to process large files (sometimes > 500MB), which can only work if small chunks are being streamed.
3. The reader returns an IEdiItem on every read, where each item contains a reference to the current group header and interchange header.
4. The reader should be able to split large transactions into blocks of repeating loops, retaining the previously parsed segments. This produces multiple partial copies of the same transaction.
5. Read multiple interchanges from the same file\stream.
6. Probe for parse-able data in a file with incorrect\broken data.
Summing it all up - there is no real case where you'd ever need a wrapper to be able to make sense of the EDI data, however it's entirely up to the consumer to build one should they have such a specific requirement.
Validation of the full interchange (including group and transaction level) is built into AckMan, which validates additional things such as number of transactions, ref numbers, duplicates etc. It's highly recommended that you use it as it produces standard, EDI-compliant report of the validity of an EDI interchage (or functional group in X12) according to the selected validation type (technical, functional or implementation).
AckMan also caters automatically for split transactions so you wouldn't have to do anything.
The recently released EDI API provides Interchange wrappers because all data will be presented as resource links for large files.
We may consider some sort of a helper class\model in the future but this isn't on the agenda in the moment.
Please sign in to leave a comment.