Parsing an EDI/X12 document is either a trivial task or a difficult one depending on the tool you use. Many tools, provide a graphical drag and drop environment, where you can drop each element of the source document into a target element. Along the way, you can also define functions for these transformations and as the number of elements increase, it gets more and more messier. With MOND, our goal is to create the easiest EDI parser in the world and at the same time create the easiest EDI document creator in the world. Whether you use a graphical drag and drop tool or not, it is important to be able to refer to elements in the EDI document. For example, in an EDI 850 document, we may want to fetch the value of the data element '324' within the BEG segment. Some data elements repeat based on a qualifier(ex 'ST', 'BT'), while some data elements repeat without any qualifier. (ex: Line Items).Loops are identified by Loop Id, Segments by Segment Identifier and soon. To get the value of any data element, we need to know the segment identifier and the loop identifier. Instead of saying, get me element 324 of BEG segment (or dragging that element into a target element), in MOND we first assign a variable name to the element 324 of BEG segment. The EDI specifications assigns the identifier BEG03 to this data element, but I don't think it adds a lot of value to programmers or analysts. In MOND, we call this a variable name or better still a 'Keyword'. A better variable name or key word for this element would be PurchaseOrderNumber of PONumber or DocumentNumber. The business usage of this variable or keyword could vary from company to company or even within the 850, it may vary based on the document type. (ex:Contract Number or CallOff Number). That's why in MOND, we assign a keyword and a business term to every EDI data element that has to be parsed or created.Once we assign a keyword, the corresponding value can be fetched or set based on a simple statement. Unlike other tools in the market, MOND programmers do not have to worry about the Loops, the different EDI identifiers etc.
Finally, what about the elements that occur multiple times like Line Item Number, Item Quantity, Item Description, Item Part Number etc?The Item Part Number is an interesting variation, because there can be multiple occurrences based on qualifiers. (How that is handled in MOND is a discussion for another day)
The same approach can be used for 2nd level, 3rd level repeating elements. ex: setTargetLevel2Value or getSourceLevel2Value, by passing the appropriate level1 and level2 indexes.
With this approach, we have dramatically simplified EDI parsing and document creation. In addition we have separated the business logic from the data format. The same code can be used to produce an EDI 3040, or EDI 4010 or EDI 5010 version with minimal changes. For that matter, instead of an EDI document, you could choose to create an SAP IDOC or xCBL or Ariba cXML document using the same code. Notice how simple this approach is compared to JAXB or other methods.