EDIFACT Support validation of empty segments about staedi HOT 10 CLOSED

@benisantos, thanks for the report. I'll be looking into this shortly.

from staedi.

@benisantos - when the TOO_MANY_DATA_ELEMENTS error occurs, can you confirm that the segment involved is the SRC?

from staedi.

After doing some additional research on this issue, I believe that your configuration that includes the following schema type should work. At this point, I suspect that there is some other data error in the input file you are processing that is causing the ELEMENT_OCCURRENCE_ERROR.

<segmentType name="SRC">
  <sequence />
</segmentType>

from staedi.

Hi @MikeEdgar and thank you for your time. I attach a simple test with the TOO_MANY_DATA_ELEMENTS failure.

validation-test.zip

The test fails with:
java.lang.AssertionError: ELEMENT_OCCURRENCE_ERROR: TOO_MANY_DATA_ELEMENTS (seg=SRC, elemPos=1, compoPos=-1, textOnError=null)

from staedi.

@benisantos , thank you for the example. I will be providing a fix for the issues you flagged with TODO comments as well in your test case related to the UNA segment.

from staedi.

@benisantos, the reason you are seeing an issue with the validation of the IATA in UNB element 1, component 1 and PNRGOV in the UNH is because the internal control schema is based on the ISO control segments which do not include those values. Are you aware of any publications by IATA that would define the valid values for IATA's message types?

The use of IATA in the UNB seems to be in conflict with the guidelines here (https://www.gefeg.com/jswg/cl/v4x/40200/cl1.htm), but I understand that the PDF linked in #10 requires that code value and it should be supported somehow.

from staedi.

@MikeEdgar "Are you aware of any publications by IATA that would define the valid values for IATA's message types?"

• No, sorry. I'm only aware of "PNRGOV" and "ACKRES" msg types :(

from staedi.

@benisantos , the following code sample is a way you might be able to "ignore" the code values in the UNB and UNH segments. You could alternatively use an EDIStreamFilter to ignore them and keep your main logic cleaner. I have identified the issues with TOO_MANY_DATA_ELEMENTS and SEGMENT_NOT_IN_DEFINED_TRANSACTION_SET for UNA and will have a new release published soon, hopefully today.

case ELEMENT_DATA_ERROR:
    // TODO Change "control schema", because it does not recognise "IATA" (UNB), "PNRGOV:11" (UNH)
    if ("DE0001".equals(reader.getReferenceCode()) && "IATA".equals(reader.getText())) {
        break;
    }
    if ("DE0065".equals(reader.getReferenceCode()) && "PNRGOV".equals(reader.getText())) {
        break;
    }
    if ("DE0052".equals(reader.getReferenceCode())) {
        break;
    }
    // Handle the error

from staedi.

@benisantos - the fix for the two issues here has been release and is now available in version 1.4.0.

<dependency>
  <groupId>io.xlate</groupId>
  <artifactId>staedi</artifactId>
  <version>1.4.0</version>
</dependency>

from staedi.

Thank you so much @MikeEdgar

from staedi.