QuickFIX/J not reading all the repeating groups in FIX message

Question

We are receiving fix messages from WebICE exchange in a text file and our application is reading and parsing them line by line using QuickFixJ. We noticed that in some messages the repeating group fields are not being parsed and upon validating with data dictionary getting error.

quickfix.FieldException: Out of order repeating group members, field=326

For example in the sample file data-test.csv the first 2 rows parsed successfully but third one fails with the above error message.

Upon investigation I found , in first 2 rows tag 326 comes after tag 9133 but in the third row it comes before that and hence fails in validation. If I adjust data dictionary as per the third one it succeeds but ofcourse the first one starts failing.

This is happening only for few messages for most of the other fix messages are getting validated and parsed quite fine. This is part of the migration project from existing C# application using QuickFix/N to our scala application using QuickFix/J. And its been working fine at the source end (with QuickFIx/N). Is there any difference in both the libraries QuickFIx/J and QuickFIx/N in terms of dealing with group fields ?

To help recreate the issue , I have shared the data file having 3 fix messages as explained above.

Data file : data-test.csv Data dictionary : ICE-FIX42.xml

Here is the test code snippet

val dd: DataDictionary = new DataDictionary("ICE-FIX42.xml")
val mfile = new File("data-test.csv")
for (line <- Source.fromFile(mfile).getLines) {
    val message = new quickfix.Message(line,dd)
    dd.setCheckUnorderedGroupFields(true)
    dd.validate(message)
    val noOfunderlyings= message.getInt(711)
    println("Number of Underlyings "+noOfunderlyings)
    for(i <- 1 to noOfunderlyings ) {
      val FixGroup: Group = message.getGroup(i, 711)          
      println("UnderlyingSecurityID : " + FixGroup.getString(311))
    }
}

Request to fellow SO users , If you can help me with this.

Many Thanks

Answer 1

You should use setCheckUnorderedGroupFields(false) to disable the validation of the ordering in repeating groups. However, this is only a workaround.

I would suggest to approach your counterparty about this because especially in repeating groups the field order is required to follow the message definition, i.e. the order in the data dictionary.

FIX TagValue encoding spec

Field sequence within a repeating group

...

Fields within repeating groups must be specified in the order that the fields are specified in the message definition.