Проверка повторяющейся группы QuickFix/N, в которой меняются местами первые два поля

Я реализую клиент для подключения к серверу, который, насколько я могу судить, использует гибрид FIX4.2 и FIX4.4.

Сервер отправляет группу 453 (NoPartyIDs) с полями в нестандартном порядке при возникновении некоторых событий.

Согласно спецификации, первым полем должно быть PartyID (448). В некоторых сообщениях первым полем в группе является PartyIDSource (447), и сообщение отклоняется. PartyIDSource — второе поле в группе по спецификации.

Я получаю следующую ошибку:

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

Из документации и проб и ошибок я не могу найти способ решить эту проблему. Среди нескольких предположений я попытался добавить поле 447 в качестве первого (необязательного) поля в определении группы в словаре данных. Я также установил для ValidateFieldsOutOfOrder значение N в конфигурации.

Есть ли что-то, что я могу сделать, чтобы не отклонять и не обрабатывать сообщение?

Соответствующая документация:

Группы немного более детализированы, чем другие части словаря данных.

Группа определяется в сообщении с помощью тега group. Первым дочерним элементом группового тега является тег группового счетчика, за которым следуют другие поля в группе в том порядке, в котором они должны появляться в сообщении.


quickfix quickfixn
person HOLY_CRAP_LIONS    schedule 13.04.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

ValidateFieldsOutOfOrder здесь не имеет значения, так что можете его убрать.

Если я правильно вас понял, вы говорите, что

  • иногда 447 предшествует 448
  • но в других случаях 448 предшествует 447

Если это правда, то, к сожалению, ваш контрагент ведет себя очень глупо. Согласно спецификации FIX, порядок полей в повторяющихся группах должен быть постоянным. (Кроме того, всегда должно присутствовать первое поле каждой групповой последовательности.) Если это триггерные поля, они нарушают FIX.

Если бы порядок был непротиворечивым, вы бы просто отредактировали свой DD, чтобы изменить порядок, и похоже, что вы пытались это сделать. Но если ваш контрагент ошибается, то ваш DD всегда будет неправильной частью время.

У меня нет хорошего ответа для вас. QF/n не предназначен для обработки всех случаев, когда контрагенты делают FIX неправильно (да и не должно быть).

Реализация вашего контрагента неаккуратна. Попробуйте связаться с их поддержкой и посмотреть, исправят ли они это?

person Grant Birchmeier    schedule 13.04.2021