Special Handling Attribute useMC="true"

There are some rare cases in which you might have to use identifiers in subsegments (of segments with identifiers). In those cases, you can use the segment attribute useMC="true". This attribute will have the effect that the parser is looking for the specified identifiers (values of attribute mc) in each token of the segment. In the screenshot above you can see a segment Waybill Details with identifier 5.1 and three subsegments Dimensions, Volume, and ULD Number with identifiers 5.6.2, 5.7.2, and 5.8.2.

images/download/attachments/189460107/CargoIMP_8-version-1-modificationdate-1737525047383-api-v2.png



Following an example of how these subsegments have to be defined in your XML:


<segment id="WBD" useMC="true">
<token mc="D">1|0-3,0-5n,-,0-5n,-,0-5n|</token>
<token mc="V">1|2,</token>
<token mc="U">1|3,</token>
</segment>


You can see the Line Identifier WBD of segment Waybill Details and the Goods Data Identifier D, V, and U of subsegments Dimensions, Volume, and ULD Number (the explicit values of the respective identifiers will be found in the Cargo-IMP message format specification PDF). The values for attribute mc can be a plain string, which will be interpreted as a Begins with condition, or two strings, separated by a comma, which will be interpreted as two Begins with conditions (OR related). Regular expressions can be used as well and have to be used with the prefix regex:.

If you look at the screenshot above, you will see that subsegment ULD Number consists of 2 tokens. Token 1 (5.8.2) is separated by slant 5.8.3 from token 2 (5.8.4-5.8.6). In your XML file, you have to represent every slant with character | and specify the splitting as you already know from before. So token 1 is an alpha-numerical character with length 1 (look at the line ...mc="U"...) and token 2 (5.8.4-5.8.6) is split into 2 subtokens. The first subtoken is alpha-numeric with length 3 (5.8.4), the second subtokens consists of the rest of token 2, which is a merged subtoken (5.8.5-5.8.6). The necessity of this merging in explained in the next chapter.

Note: Your source structure will have to have the same subnode match codes as specified in your XML and all the subnodes will have to be placed in a node repeat. See screenshot above.


images/download/attachments/189460107/892-version-1-modificationdate-1737525047379-api-v2.png


Note: If your segment in which you use attribute useMC="true" is optional (or conditional), you might end up with a situation, in which this segment is not in the input data, but following segment identifiers match the some of the identifiers of your subnodes. To avoid incorrect parsing, you have to make sure that your identifiers are uniquely defined (usually you will have to do that with a regular expression) so that any overlapping with other segment identifiers is impossible.

If your segment is mandatory, you can avoid that additional work by simply using another attribute topMove="true". This attribute has the effect that the parser will jump to the next top-level node when the next segment line (a line not starting with a slant) is found. The reason you cannot use this technique in the case of optional (and conditional) segments is that it will simply not be triggered if the segment is missing.

Example:

Assume the following input data:


...
RTD/P1/K48.0/CS/SN100/W96/R22.20/T2131.20
PPD/WT2131.20
...

If your segment is specified as follows, you will incorrectly parse segment PPD into your segment RTD (since PPD starts with P).


...
<segment id="RTD" useMC="true" >
<token mc="P">1,</token>
</segment>
...


This can be avoided by the following specification (if your segment RTD is mandatory).


...
<segment id="RTD" useMC="true" topMove="true">
<token mc="P">1,</token>
</segment>
...

If your segment RTD is optional or conditional, you have to solve the problem in a different way.


...
<segment id="RTD" useMC="true">
<token mc="regex:^(?!PPD)P.*">1,</token>
</segment>
...