Does QuickFIX/N support messages containing two components with one group each, both with same name?

泄露秘密 提交于 2021-01-27 14:05:50

问题


I am using QuickFIX/N 1.8 and when it has to create the DataDictionary based on an XML, it fails because my FIX50SP1_TRTN.xml (provided by Thomson Reuters) contains one message (AllocationReport) with two components (TrdInstrmtLegGrp, InstrmtLegAllocGrp), and both components have a group with a same name (NoLegs - 555).

QuickFIX/N is trying to create a dictionary per message, containing the groups of all its components, where the key of each group is the id. Therefore, it's trying to insert the key 555 twice, throwing an Exception the second time.

System.ArgumentException: 'An item with the same key has already been added.'

\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 ###########
}

Summarized content of my 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>

My questions:

  1. Is QuickFIX/N supposed to support this situation?
  2. Have you ever faced this problem? How did you solve it?
  3. Do you know some explicit constraint (in QuickFIX/N, or the FIX protocol itself) about this situation? (maybe there is an explicit restriction saying that a message cannot contain more than one component with a group with a same name).

回答1:


I believe that this is not allowed by the FIX specification. I say this because the FIX 4.4 and FIX 5.0 specification documents both state:

A tag number (field) should only appear in a message once. If it appears more than once in the message it should be considered an error with the specification document.

In addition, if you search through a FIX specification document or a FIX data dictionary file for PartyID, you will see that the concept of a repeating group containing PartyID, PartyIDSource and PartyRole appears in several places, but each with different names for the repeating group and the fields it contains. There are:

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

All of those repeating groups contain three fields denoting a party ID, its source and its role, but the names of those fields is never reused from one repeating group to another, and the same repeating group is not used more than one in a message. For example, the ExecutionReport message contains:

  • NoPartyIDs
  • NoNestedPartyIDs
  • NoNested2PartyIDs
  • NoNested3PartyIDs
  • NoNestedParties4

There are a few other cases of structurally-similar-but-differently-named repeating groups in FIX.

My point is that if FIX intended to allow a repeating group to appear multiple times in a message, then there would not have been any need for FIX to define structurally-similar-but-differently-named repeating groups in the FIX specification.

I suggest you raise this concern with Thomson Reuters. I once encountered a similar issue with a different trading venue; it turned out I had been given a buggy draft version of the venue's FIX specification, and they were happy to send me an up-to-date, corrected version of their FIX specification.




回答2:


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.



来源:https://stackoverflow.com/questions/56524842/does-quickfix-n-support-messages-containing-two-components-with-one-group-each

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!