QuickFIX不验证重复组 [英] QuickFIX doesn't validate the repeating group

查看:894
本文介绍了QuickFIX不验证重复组的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在实现一个基于QuickFIX的客户端 - 服务器集。当我尝试发送包含重复群组的邮件时,我得到拒绝,具有以下描述:58 =未为此邮件类型定义标签| 371 = 447 |

I'm implementing a client-server set based on QuickFIX. When I try to send a message that contains a Parties repeating group, I get the Reject with the following description: "58=Tag not defined for this message type|371=447|"

我尝试发送的消息类型是OrderCancelReplaceRequest。

The message type thet I try to send is OrderCancelReplaceRequest.

代码示例是:

FIX44::OrderCancelReplaceRequest order(FIX::MsgType("G"));

FIX44::OrderCancelReplaceRequest::NoPartyIDs party;
// 448-PartyID
party.set(FIX::PartyID("PartyId"));
// 447-PartyIDSource
party.set(FIX::PartyIDSource('B'));    
// 452-PartyRole
party.set(FIX::PartyRole(1));    
// 802-NoPartySubIDs
party.set(FIX::NoPartySubIDs(0));

order.addGroup(party);

...

如果邮件不包含缔约方群组,成功由服务器。

If the message contains no Parties group, it's validated successfully by the server.

此外,即使它包含FIX44 :: OrderCancelReplaceRequest :: NoAllocs组,也会成功验证:

Moreover, it's validated successfully even if it contains the FIX44::OrderCancelReplaceRequest::NoAllocs group:

 FIX44::OrderCancelReplaceRequest::NoAllocs alloc;
 // 79-AllocAccount
 alloc.set(FIX::AllocAccount("Alloc Account"));
 // 80-AllocQty
 alloc.set(FIX::AllocQty(4.2));
 order.addGroup(alloc);

所以,我看到这个问题只有当我试图使用缔约方组。

So, I see this problem only when I try to use the Parties group.

服务器的配置文件是:

[DEFAULT]
ConnectionType=acceptor
SocketAcceptPort=28663
SocketReuseAddress=Y
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=Y
DataDictionary=<some path here>/FIX44.xml
FileLogPath=QuickFixServerLog
ValidateUserDefinedFields=N

[SESSION]
BeginString=FIX.4.4
SenderCompID=EXECUTOR
TargetCompID=CLIENT1
FileStorePath=store

客户端是:

[DEFAULT]
ConnectionType=initiator
ReconnectInterval=1
FileStorePath=store
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=Y
DataDictionary=<some path here>/FIX44.xml
HttpAcceptPort=9911
ValidateUserDefinedFields=N
ResetOnLogout=Y
ResetOnLogon=Y

[SESSION]
BeginString=FIX.4.4
SenderCompID=CLIENT1
TargetCompID=EXECUTOR
SocketConnectHost=127.0.0.1
SocketConnectPort=28663
HeartBtInt=15

更新。

由服务器重新生成的请求示例(来自服务器日志)为:

The example of the request reseived by server (it's from the server logs) is:

8=FIX.4.4|9=234|35=G|34=2|49=CLIENT1|52=20150417-10:49:07.715|56=EXECUTOR|1=Account|11=Id123|38=11.11|40=1|41=OrigId321|44=4.2|54=2|55=Symbol|60=20150417-10:49:07|78=2|79=AllocAccount1|79=AllocAccount2|80=10|80=20|447=B|448=PartyId|452=1|453=1|802=0|10=185|

该请求的响应是:

8=FIX.4.4|9=124|35=3|34=2|49=EXECUTOR|52=20150417-10:49:07.719|56=CLIENT1|45=2|58=Tag not defined for this message type|371=447|372=G|373=2|10=060|


推荐答案

<缔约方>中的字段顺序。组件块 组不正确。应保留重复组(或如< Parties> 的情况下的组件块)中的字段顺序。您可以在此处找到有关

As you noted after our conversation in the comments section, the order of the fields in the <Parties> component block group was incorrect. The field order in a repeating group (or component block as in case of <Parties>) should be preserved. You can find here a blog post on the subject explaining the importance of field order in repeating groups.

在你的情况下,客户端对消息的修改破坏了< Parties> 组,导致来自服务器的拒绝消息。

In your case, a client-side modification of the message screwed up the field order of the <Parties> group which resulted in a Reject message from the server.

这篇关于QuickFIX不验证重复组的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆