Related to this question the counterparty provider engine is somehow set up to check the group order of FIX tags and reject anything out of some expected order.

  • Why does expected tag group order matter? I guess it’s quicker to validate tags in a given order.
  • How is expected tag group order set? I understand this is a random hash set, except that does not make sense, does it not depend on the order of tags in the data dictionary?
  • Besides rewriting a class to set group order, is there a quickfix setting to use?

To be exact with QuickFix version 2.2.0 I send the following message

8=FIX.4.4 9=173 35=R 34=2 49=CLIENT 52=20200909-18:11:10.426 56=SIMULATOR 131=EEB85F9C 146=1 55=EUR/USD 460=4 167=FOR 38=1000.0 64=SP 15=EUR 1=FOR 553=test 1300=XOFF 10=086

and receive a reject

8=FIX.4.4 9=145 35=3 34=2 49=SIMULATOR 52=20200909-18:11:10.427 56=CLIENT 45=2 58=The group 146 must set the delimiter field 460 371=55 372=R 373=15 10=224 

So in the sent message the tag 460 is coming after the tag 55 and I can’t get these tags the other way around. In the code I set up the repeating group g

QuickFix.FIX44.QuoteRequest.NoRelatedSymGroup g = new QuickFix.FIX44.QuoteRequest.NoRelatedSymGroup();

and add the data to the group in the order I am looking for, so like:

Product product = new Product(4);
g.Product = product;
Symbol symbol = new Symbol("EUR/USD");

and so on… I am looking at the g.getFieldOrder and g.SetFields but is there another way?

enter image description here

In other quickfix versions like 1.6.2 the reject message is Out of order repeating group members for the same reason, as far as I can tell.


Thanks to @ChristopheJohn I got this working in QuickFixN with code:

using QuickFix;

class MyGroup : Group
    private static int[] FIELD_ORDER = { 460, 1300, 167, 55, 15, 38, 64, 1, 553, 0 };

    public MyGroup() : base(146, 460, FIELD_ORDER) { }

Which I called from my message construction methods with MyGroup g = new MyGroup();

Note the 0 at the end of the field order.