QuickFixJ 正在截断 FIX 消息中的重复组
QuickFix4J is truncating repeated groups in the FIX messsage
我有一个字符串形式的 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 0,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 尝试解析它并因此截断字段。可惜我不能分享 DD。
我看到两个问题：
第一期：你的做法是错误的
rawMessage = new Message(newmessage, dataDictionary, false);
Session.sendToTarget(rawMessage, sessionID)
你不能那样做！序列号、时间戳等不再有效！
您要创建简单的消息重放器吗？ （为什么人们一直试图这样做？）这是行不通的！ FIX 消息流具有您不能盲目重放的状态。
如果您要创建测试工具，它需要比这更智能。停止你正在做的事情并重新考虑你的方法。
第二期：你的DD可能有错误
截断的重复组总是意味着 DataDictionary 问题。 DD 与正在解析的消息不匹配。肯定会发生以下情况之一：
- 消息在组中放置了一个字段，该字段不在该组的 DD 定义中
- 消息组的字段顺序不正确（与 DD 的顺序相比）
解析组时，引擎会在看到不希望的字段时立即结束该组。
The DataDictionary that I am using is given to me by the other party.
不要相信它！对方使用自己的文档出错，因为他们实际上并没有使用它们，或者因为他们的内部版本比他们发布的版本更新。
开始根据他们给你的 DD 手动解析你的消息，我打赌你会发现错误。
感谢 Grant 的投入，最后我们发现错误是重复的组出现了乱序：
datadictionary.setCheckUnorderedGroupFields(false);
解决了。
我有一个字符串形式的 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 0,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 尝试解析它并因此截断字段。可惜我不能分享 DD。
我看到两个问题：
第一期：你的做法是错误的
rawMessage = new Message(newmessage, dataDictionary, false);
Session.sendToTarget(rawMessage, sessionID)
你不能那样做！序列号、时间戳等不再有效！
您要创建简单的消息重放器吗？ （为什么人们一直试图这样做？）这是行不通的！ FIX 消息流具有您不能盲目重放的状态。
如果您要创建测试工具，它需要比这更智能。停止你正在做的事情并重新考虑你的方法。
第二期：你的DD可能有错误
截断的重复组总是意味着 DataDictionary 问题。 DD 与正在解析的消息不匹配。肯定会发生以下情况之一：
- 消息在组中放置了一个字段，该字段不在该组的 DD 定义中
- 消息组的字段顺序不正确（与 DD 的顺序相比）
解析组时，引擎会在看到不希望的字段时立即结束该组。
The DataDictionary that I am using is given to me by the other party.
不要相信它！对方使用自己的文档出错，因为他们实际上并没有使用它们，或者因为他们的内部版本比他们发布的版本更新。
开始根据他们给你的 DD 手动解析你的消息，我打赌你会发现错误。
感谢 Grant 的投入，最后我们发现错误是重复的组出现了乱序：
datadictionary.setCheckUnorderedGroupFields(false);
解决了。