Validating QuickFix/N Repeating Group Where First Two Fields Swap Order

user_15624851 0
Viewed 135

I am implementing a client to connect to a server which as far as I can tell uses a hybrid of FIX4.2 and FIX4.4.

The server sends group 453 (NoPartyIDs) with fields in a non-standard order when some events occur.

According to the specification document, the first field should be PartyID (448). With certain messages, the first field in the group is PartyIDSource (447) and the message is rejected. PartyIDSource is the second field in the group as per the specification.

I get the following error:

<event> Message 140 Rejected: Group 453's first entry does not start with delimiter 448 (Field=453)

From the documentation and trial and error, I cannot find a way through this issue. Amongst a few guesses, I have tried adding field 447 as the first (non-required) field in the group definition in the data-dictionary. I have also set ValidateFieldsOutOfOrder to N in the config.

Is there something I can do to not reject and process the message?

Relevant documentation:

Groups are a little more nuanced than other parts of the Data Dictionary.

A group is defined within a message, with the group tag. The first child element of the group tag is the group-counter tag, followed by the other fields in the group in the order in which they should appear in the message.

quickfixn quickfix
1 Answers

ValidateFieldsOutOfOrder is not relevant here, so you can take that out.

If I understand you correctly, you're saying that

  • sometimes 447 comes before 448
  • but at other times 448 comes before 447

If this is true, then unfortunately your counterparty is being really stupid. Per the FIX spec, the order of fields in repeating groups is supposed to be in a consistent order. (And also, the first field of the each group-sequence is always required to be present.) If they're flip-flopping fields, they're violating FIX.

If the order was consistent, you would just edit your DD to change the order, and it sounds like you tried that. But if your counterparty is flip-flopping, then your DD will always be wrong part of the time.

I don't have a good answer for you. QF/n is not designed to handle all the ways that counterparties do FIX wrong (nor should it be).

Your counterparty's implementation is sloppy. Try contacting their support and seeing if they'll fix it?

user_6504750
Related