Поддерживает ли QuickFIX / N сообщения, содержащие два компонента по одной группе каждый с одинаковым именем?

Question

Я использую QuickFIX / N 1.8, и когда он должен создать DataDictionary на основе XML, он завершается ошибкой, потому что мой FIX50SP1_TRTN.xml (предоставленный Thomson Reuters) содержит одно сообщение (AllocationReport) с двумя компонентами (TrdInstrmtLegGrp, InstrmtLegAllocGrp), и оба компонента имеют группу с одинаковым именем (NoLegs - 555).

QuickFIX / N пытается создать словарь для сообщения, содержащий группы всех его компонентов, где ключом каждой группы является идентификатор. Поэтому он пытается дважды вставить ключ 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) в этой ситуации? (возможно, существует явное ограничение, согласно которому сообщение не может содержать более одного компонента с группой с одинаковым именем).

Answer 1

Я считаю, что это не разрешено спецификацией FIX.Я говорю это потому, что оба документа спецификации FIX 4.4 и FIX 5.0 утверждают:

Номер (поле) тега должен появляться в сообщении только один раз.Если оно появляется более одного раза в сообщении, это следует рассматривать как ошибку в документе спецификации.

Кроме того, если вы выполняете поиск в документе спецификации FIX или в файле словаря данных FIX для PartyID, вы увидите, что концепция повторяющейся группы, содержащей PartyID, PartyIDSource и PartyRole, появляется в нескольких местах, но каждое с разными именами для повторяющейся группы и содержащихся в ней полей.Есть:

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

Все эти повторяющиеся группы содержат три поля, обозначающие идентификатор партии, ее источник и ее роль, но имена этих полей никогда не используются повторно из одной повторяющейся группы в другую, иодна и та же повторяющаяся группа не используется более одной в сообщении.Например, сообщение ExecutionReport содержит:

• NoPartyIDs
• NoNestedPartyIDs
• NoNested2PartyIDs
• NoNested3PartyIDs
• NoNestedParties4

В FIX есть еще несколько случаев структурно подобных, но с разными именами повторяющихся групп.

Моя точка зрения заключается в том, что если бы FIX намеревался разрешить повторяющуюся группу появляться в сообщении несколько раз, то в FIX не было бы необходимости определять повторяющиеся группы со структурно подобными, но с разными именами вспецификация FIX.

Я предлагаю вам поднять эту проблему с Thomson Reuters.Однажды я столкнулся с подобной проблемой в другом месте торговли;оказалось, что мне дали черновую версию спецификации FIX объекта, и они были рады выслать мне обновленную исправленную версию своей спецификации FIX.

Answer 2

Это открытый вопрос, , который я сам обнаружил в сентябре прошлого года .

Я вполне уверен, что эта ситуация DD разрешена в FIX, то есть это QF/ п проблема.(Я бы поставил деньги на то, что некоторые другие языковые порты QF тоже имеют эту проблему.) Обновление: согласно превосходному ответу Сиарана Макхейла, не разрешено в FIX.

Я собираюсь это исправить, но не могу сказать, когда это произойдет. Обновление: несмотря на то, что это не разрешено в FIX, я все же хочу поддерживать его в QF / n, потому что контрагенты делают глупости.

У меня сейчас нет хорошего обходного пути.В моем случае мне повезло, что мы фактически не использовали это сообщение в приложении, которое я разрабатывал, поэтому я мог просто прокомментировать эту группу проблем из DD.