QuickFixJ 正在截断 FIX 消息中的重复组答案

【问题标题】：QuickFix4J is truncating repeated groups in the FIX messsageQuickFixJ 正在截断 FIX 消息中的重复组
【发布时间】：2019-04-10 11:55:48
【问题描述】：

我有一条 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 尝试解决它并因此截断字段的情况下按原样发送消息。很遗憾，我无法分享 DD。

【问题讨论】：

你删掉了8=FIXT.1.1吗？为什么？那不是专有的。这对读者来说非常重要。
@GrantBirchmeier 对不起，我一般掩盖了它。已恢复该部分。

标签： fix-protocol quickfixj data-dictionary

【解决方案1】：

我看到两个问题：

第一个问题：你的方法是错误的

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

你不能这样做！序列号、时间戳等不再有效！

您是否正在创建一个简单的消息播放器？（为什么人们一直试图这样做？）它不会工作！ FIX 消息流具有不能盲目重播的状态。

如果您要创建测试工具，它需要比这更智能。停止你正在做的事情并重新考虑你的方法。

第二个问题：你的 DD 可能有错误

截断的重复组总是意味着 DataDictionary 问题。 DD 与正在解析的消息不匹配。肯定会发生以下情况之一：

消息在组中放置了一个字段，该字段不在 DD 对该组的定义中
消息组的字段乱序（与 DD 的顺序相比）

解析组时，引擎会在看到它不期望的字段时立即结束组。

我使用的DataDictionary是对方给我的。

不要相信它！交易对手在他们自己的文档中出错，因为他们实际上并没有使用它们，或者因为他们的内部版本比他们发布的版本新。

开始根据他们给你的 DD 手动解析你的消息，我打赌你会发现错误的。

【讨论】：

感谢您的见解。我的代码是一个接受者。我的代码从 QA Automation Scripts 编写的文件中提取 FIX 消息，然后将其发送给发起者。对于我们的特定场景，这是可行的。我没有遇到时间戳等问题。它适用于大多数消息。唯一的问题是这个特定的消息和数据字典组合。所以想检查它是否真的是 DD 问题，或者我可以在我的代码中做的任何事情。不幸的是，我作为开发人员无法访问 DD。会要求他们检查是否有更新的 DD。
你的 Acceptor 确实有一个 DD。您的 Acceptor 配置文件将指向它。这就是它用来解析传入消息的内容。
感谢格兰特。 DD 似乎是最新的，但它确实有自定义字段。我必须用这个新的 DD 重新构建 quickfix4j 吗？
如果它正在接收自定义重复组，您可以不重建。如果是发送自定义重复组，你可能应该重新生成和重建。

【解决方案2】：

感谢格兰特的投入，最后我们发现错误在于重复组出现故障：

datadictionary.setCheckUnorderedGroupFields(false);

解决了。

【讨论】：