QuickFix4J усекает повторяющиеся группы в сообщении FIX - PullRequest
Новая
       27

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

0 голосов
/ 10 апреля 2019

У меня есть сообщение 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|

И это сообщение после создания сообщения.object: 

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, пытающегося его разрешить иотсюда усекаются поля.К сожалению, я не могу поделиться ДД.

1 Ответ

1 голос
/ 10 апреля 2019

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

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

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

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

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

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

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

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

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

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

Используемый мной DataDictionary предоставлен мне другой стороной.

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

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

...