QuickFix4J обрезает повторяющиеся группы в сообщении FIX

У меня есть сообщение FIX в виде строки, и я создаю объект сообщения из этого сообщения с помощью QuickFix4J, чтобы я мог отправить его другой стороне.

DataDictionary, который я использую, предоставляется мне другой стороной.

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

Это мое исходное сообщение:

8=FIXT.1.1|9=1288|35=X|34=1163|49=XX|52=20190410-10:27:43|56=XXXXXXXXXXXXXXXXXXXXX|131=XXXXXXXXXXXXXX_2019410_155743|146=1|55=[X/X]|48=58013XXX5|22=1|6360=XXXXXXXX XXXXXXXX|454=1|455=XX58013XXX54|456=4|20200=2|20201=1|20202=6|20203=99.06300000|20204=1111.00|20205=3|20206=XXX2|20201=2|20202=6|20203=0.14400000|20204=2222.00|20205=3|20206=XXX2|460=3|1227=XXXX|29703=XXXX XXXX|167=XXXX|541=20350410|225=20170410|223=0.03500000|106=XXXXXXXXX XXXX XXXXXX XXXX XXX XXXX XXXXX|107=XXX  3.500  3/1/27 X26|873=20170309|54=2|38=188000|64=20190412|15=XXX|126=20190410-10:32:43|60=20190410-10:27:43|663=1|699=9128286X1|761=1|29715=XX9128286X18|29716=4|29717=XXX|29718=0.02625000|29719=20290215|423=6|453=7|448=XXXXXXX1|447=X|452=11|802=1|523=XXXXXXX XXXXXX XX XXX|803=9|448=XXXX|447=X|452=13|448=XXX XXXXXXXXXX 5|447=X|452=13|448=XXXXXX33|447=X|452=17|802=1|523=0355|803=17|448=XXXX|447=X|452=17|448=XXXXXX XXXXXX XXXXXXXXXX (XXX) XXX|447=X|452=17|448=XXXXXXX|447=X|452=13|58=XXXXXX5 (XXXXXXXXXX, XXXXXXX XXXXXX XX XXX)  XXXXXXXX  XXX XX $100,000 XXX 3.500 03/01/27 X26, XXXXXXXXX XXX 2.625 02/29, XXX XX 2 XXXX XXXXX-XXXXXXX , XXXX XXXX.|5625=2|20117=10155743|5961=XXXXXX|5626=3|20012=1 3|5215=X|5627=XXXXXXXXX|5630=XXXXXXX, XXXX|20120=X2X-XXX-XXXX|21031=X|21032=X|20013=0.3|29724=60|22203=XXXX|29741=000X|29742=1000|10=144|

А это сообщение после создания объекта сообщения:

8=FIXT.1.1|9=262|35=X|34=656|49=XX|52=20190410-10:27:45.566|56=XXXXXXXXXXXXXXXXXXXXX|131=XXXXXXXXXXXXXX_2019410_155743|146=1|55=[X/X]|48=58013XXX5|22=1|6360=XXXXXXXX XXXXXXXX|454=1|455=XX58013XXX54|456=4|20200=2|20201=2|20202=6|20203=99.06300000|20204=1111.00|20205=3|20206=XXX2|10=111|

Это код, с помощью которого я создаю сообщение:

rawMessage = new Message(newmessage, dataDictionary, false);

Session.sendToTarget(rawMessage, sessionID)

Есть ли способ отправить сообщение как есть без quickfix4j, пытающегося разрешить его и, следовательно, усекая поля. К сожалению, я не могу поделиться ДД.


data-dictionary fix-protocol quickfixj
person Ragesh G R    schedule 10.04.2019    source источник
comment
Вы подвергли цензуре 8=FIXT.1.1? Почему? Это не собственность. Это очень важно знать читателям.   -  person Grant Birchmeier    schedule 10.04.2019
comment
@GrantBirchmeier Извините, я вообще замаскировал это. Восстановили эту часть.   -  person Ragesh G R    schedule 11.04.2019

Ответы (2)


arrow_upward
1
arrow_downward

Я вижу две проблемы:

Первая проблема: ваш подход — ошибка

rawMessage = new Message(newmessage, dataDictionary, false);
Session.sendToTarget(rawMessage, sessionID)

Вы не можете этого сделать! Порядковые номера, временные метки и т. д. больше недействительны!

Вы создаете наивный проигрыватель сообщений? (Почему люди продолжают пытаться это сделать?) Это не сработает! Потоки сообщений FIX имеют состояние, которое нельзя просто воспроизвести вслепую.

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

Вторая проблема: возможно, ваш DD содержит ошибки

Усеченные повторяющиеся группы всегда означают проблему DataDictionary. DD не соответствует анализируемому сообщению. Наверняка происходит одно из следующего:

  • сообщение поместило в группу поле, которого нет в определении DD для этой группы
  • группа сообщения имеет поля не по порядку (по сравнению с порядком DD)

При анализе группы механизм завершит группу, как только увидит поле, которого не ожидает.

DataDictionary, который я использую, предоставляется мне другой стороной.

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

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

person Grant Birchmeier    schedule 10.04.2019
comment
Спасибо за ваши идеи. Мой код является акцептором. Мой код получает сообщения FIX из файла, написанного сценариями автоматизации QA, и я отправляю их инициатору. Для нашего конкретного сценария это работает. У меня не было проблем с отметкой времени и т. д. И это работает для большинства сообщений. Единственная проблема связана с этим конкретным сочетанием сообщения и словаря данных. Поэтому хотел проверить, действительно ли это проблема DD или что-то еще, что я могу сделать в своем коде. И к сожалению я как разработчик не могу получить доступ к DD. Попросит их проверить, есть ли у них еще обновленные ДД. - person Ragesh G R; 11.04.2019
comment
У вашего Акцептора есть DD. Конфигурационный файл вашего Acceptor будет указывать на него. Это то, что он использует для анализа входящего сообщения. - person Grant Birchmeier; 11.04.2019
comment
Спасибо Грант. DD кажется последним, но в нем есть настраиваемые поля. Нужно ли мне пересобирать quickfix4j с этим новым DD? - person Ragesh G R; 05.11.2019
comment
Если он получает настраиваемые повторяющиеся группы, вы можете обойтись без перестроения. Если он отправляет настраиваемые повторяющиеся группы, вам, вероятно, следует повторно сгенерировать и перестроить. - person Grant Birchmeier; 05.11.2019

arrow_upward
0
arrow_downward

Спасибо, Грант, за ваш вклад, наконец, мы выяснили, что ошибка заключалась в том, что повторяющиеся группы выходили не по порядку:

datadictionary.setCheckUnorderedGroupFields(false);

решил это.

person Ragesh G R    schedule 02.09.2020