ilyn.org/schema/edi-message-mapping-1.0.xsd">edi2SaxMappingConfig = .... {@link org.xml.sax.ContentHandler} contentHandler = ....EDIParser parser = new EDIParser(); parser.setContentHandler(contentHandler); parser. {@link #setMappingModel(EdifactModel) setMappingModel}(EDIParser. {@link #parseMappingModel(InputStream) parseMappingModel}(
edi2SaxMappingConfig)); parser.parse(new InputSource(ediInputStream)); etc...
Mapping Model
The EDI to SAX Event mapping is performed based on an "Mapping Model" supplied to the parser. This model must be based on the
edi-message-mapping-1.0.xsd schema.
From this schema you can see that segment groups are supported (nested segments), including groups within groups, repeating segments and repeating segment groups. Be sure to review the
schema.
Example (Input EDI, EDI to XML Mapping and Output SAX Events)
The following illustration attempts to create a visualisation of the mapping process. The "input-message.edi" file specifies the EDI input, "edi-to-xml-order-mapping.xml" describes how to map that EDI message to SAX events and "expected.xml" illustrates the XML that would result from applying the mapping.
So the above illustration attempts to highlight the following:
- How the message delimiters (segment, field, component and sub-component) are specified in the mapping. In particular, how special characters like the linefeed character are specified using XML Character References.
- How segment groups (nested segments) are specified. In this case the first 2 segments are part of a group.
- How the actual field, component and sub-component values are specified and mapped to the target SAX events (to generate the XML).
Segment Cardinality
What's not shown above is how the <medi:segment> element supports the 2 optional attributes "minOccurs" and "maxOccurs" (default value of 1 in both cases). These attributes can be used to control the optional and required characteristics of a segment. A maxOccurs value of -1 indicates that the segment can repeat any number of times in that location of the EDI message (unbounded).
Segment Groups
Segment groups can be added using the <segmentGroup> element. A Segment group is matched by the first segment in the group. A Segment Group can contain nested <segmentGroup> elements, but the first element in a <segmentGroup> must be a <segment>. <segmentGroup> elements support minOccurs/maxOccurs cardinality. They also support an optional "xmlTag" attribute, when if present will result in the XML generated by a matched segment group being inserted inside an element having the name of the xmlTag attribute value.
Segment Matching
Segments are matched in one of 2 ways:
- By an exact match on the segment code (segcode).
- By a {@link java.util.regex regex pattern match} on the full segment, where the segcode attribute defines theregex pattern (e.g. segcode="1A\*a.*").
Required Values
<field>, <component> and <sub-component> configurations support a "required" attribute, which flags that <field>, <component> or <sub-component> as requiring a value.
By default, values are not required (fields, components and sub-components).
Truncation
<segment>, <field> and <component> configurations support a "truncatable" attribute. For a segment, this means that parser errors will not be generated when that segment does not specify trailing fields that are not "required" (see "required" attribute above). Likewise for fields/components and components/sub-components.
By default, segments, fields, and components are not truncatable.
@author tfennelly