3

我正在使用 QuickFIX/N 1.8，当它必须基于 XML 创建 DataDictionary 时，它会失败，因为我的FIX50SP1_TRTN.xml（由 Thomson Reuters 提供）包含一条消息（AllocationReport）和两个组件（TrdInstrmtLegGrp，InstrmtLegAllocGrp），并且两个组件都有具有相同名称 ( NoLegs- 555) 的组。

QuickFIX/N 试图为每条消息创建一个字典，包含其所有组件的组，其中每个组的键是 id。因此，它尝试插入密钥555两次，第二次抛出异常。

System.ArgumentException: '已添加具有相同键的项目。'

\QuickFIXn\DataDictionary\DataDictionary.cs

else if(childNode.Name == "group")
{
    DDField fld = FieldsByName[childNode.Attributes["name"].Value];
    DDGrp grp = new DDGrp();
    XmlAttribute req = childNode.Attributes["required"];
    if (req != null && req.Value == "Y"
    && (componentRequired == null || componentRequired.Value == true))
    {
        ddmap.ReqFields.Add(fld.Tag);
        grp.Required = true;
    }
    if (!ddmap.IsField(fld.Tag))
    {
        ddmap.Fields.Add(fld.Tag, fld);
    }
    grp.NumFld = fld.Tag;
    parseMsgEl(childNode, grp);
    ddmap.Groups.Add(fld.Tag, grp); //########### It fails when the second group is processed ###########
}

我的FIX50SP1_TRTN.xml的摘要内容

<fix major="5" minor="0">
  <header/>
  <trailer/>

  <messages>
    <message name="AllocationReport" msgtype="AS" msgcat="app">
      <component name="TrdInstrmtLegGrp" required="N"/>
      <component name="InstrmtLegAllocGrp" required="N"/>
    </message>
  </messages>

  <components>
    <component name="TrdInstrmtLegGrp">
      <group name="NoLegs" required="N"> <!-- 555 -->
         (content A)
      </group>
    </component>
    <component name="InstrmtLegAllocGrp">
      <group name="NoLegs" required="N">
         (content B)
      </group>
    </component>
  </components>

  <fields>
    <field number="555" name="NoLegs" type="NUMINGROUP"/>
  </fields>
</fix>

我的问题：

  1. QuickFIX/N 是否应该支持这种情况？
  2. 你有没有遇到过这个问题？你是怎么解决的？
  3. 您是否知道有关这种情况的一些明确约束（在 QuickFIX/N 或 FIX 协议本身中）？（也许有一个明确的限制，即一条消息不能包含多个具有相同名称的组的组件）。
4

2 回答 2

2

我相信这是 FIX 规范不允许的。我这样说是因为 FIX 4.4 和 FIX 5.0 规范文件都规定：

标签号（字段）只能在消息中出现一次。如果它在消息中出现不止一次，则应将其视为规范文档的错误。

此外，如果您在 FIX 规范文档或 FIX 数据字典文件中搜索PartyID，您将看到包含 和 的重复组的概念出现在多个位置，但每个重复组及其字段的名称不同包含。有：PartyIDPartyIDSourcePartyRole

  • NoPartyIDs
  • NoNestedPartyIDs
  • NoNested2PartyIDs
  • NoNested3PartyIDs
  • NoNestedParties4
  • NoDerivativeInstrumentParties
  • NoInstrumentParties
  • NoRootParties
  • NoSettlPartyIDs
  • NoTargetParties
  • NoUndlyInstrumentParties

所有这些重复组都包含三个字段，分别表示当事人 ID、其来源和角色，但这些字段的名称永远不会从一个重复组重用到另一个重复组，并且同一重复组在消息中不会使用多个。例如，ExecutionReport消息包含：

  • NoPartyIDs
  • NoNestedPartyIDs
  • NoNested2PartyIDs
  • NoNested3PartyIDs
  • NoNestedParties4

FIX 中还有其他一些结构相似但名称不同的重复组的情况。

我的观点是，如果 FIX 打算允许重复组在消息中多次出现，那么 FIX 就不需要在 FIX 规范中定义结构相似但名称不同的重复组。

我建议你向汤森路透提出这个担忧。我曾经在不同的交易场所遇到过类似的问题；事实证明，我收到了场地 FIX 规范的错误草稿版本，他们很高兴向我发送他们的 FIX 规范的最新、更正版本。

于 2019-06-12T09:18:34.593 回答
1

This is an open issue, which I myself discovered last September.

I'm fairly sure that this DD situation is allowed in FIX, meaning this is a QF/n problem. (I'd wager money that some of the other QF language ports have this problem too.) Update: Per Ciaran McHale's excellent answer, this is not allowed in FIX.

I do intend to fix this, but I can't say when it'll happen. Update: Even though it's not allowed in FIX, I still want to support it in QF/n because counterparties do stupid things.

I don't have a good workaround right now. In my case, I was lucky that we didn't actually use that message in the application that I was developing, so I could just comment that problem group out of the DD.

于 2019-06-10T14:30:59.283 回答