Quickfix или Quickfix/n, через какой тип сообщения идентифицируются пользовательские сообщения U1, U2,,Un?

Я нигде не могу найти, как управлять пользовательскими сообщениями U-типа. Я использую MessageCracker, и мне нужно понять соответствующую сигнатуру метода OnMessage. Например, мой брокер отправляет пользовательские сообщения U1, U5, U2, как я могу перехватить эти входящие сообщения внутри метода OnMessage? Я понимаю, что Tag35 идентифицирует их, но если я не могу захватить их через OnMessage, тогда MessageCracker становится бесполезным, и мне нужно идентифицировать каждое сообщение с помощью Tag35 в FromApp или FromAdmin. Любое предложение, как обращаться с такими пользовательскими U-типами?

Спасибо


quickfix fix-protocol
person Matt    schedule 01.08.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

А, пользовательские сообщения. Веселые вещи.

  1. You need to add your counterparty's customizations to the DataDictionary xml file. Choose the appropriate FIXnn.xml file for your FIX version.
  2. Then, because you are adding custom messages, you'll want to regenerate the QF/n source and rebuild the library so you can get classes for your new messages.
    • Instructions for rebuilding are here: https://github.com/connamara/quickfixn
    • Вам нужно будет установить Ruby. Некоторых это раздражает, но мы не нашли более ориентированного на Windows генератора кода, который бы нам не ненавистен. Извините заранее.
    • (Если бы вы просто добавляли поля к существующим сообщениям, вы, вероятно, могли бы обойтись без перестроения. Но вы добавляете сообщения, поэтому вам в значительной степени приходится регенерировать/перестраивать.)

Разработчикам Windows может показаться раздражающим, что требуется пересборка библиотеки, но на самом деле это норма для всех движков QF. FIX — это слишком вычурный протокол для одной сборки, чтобы удовлетворить всех, потому что кажется, что каждый контрагент любит возиться с определениями сообщений.

person Grant Birchmeier    schedule 01.08.2013
comment
Итак, вы говорите, что мне нужно создать новую библиотеку для каждого брокера, которого я хочу поддерживать, и для каждого будущего обновления QF, которым я хочу воспользоваться, мне придется выполнить одну и ту же процедуру? Это звучит невероятно громоздко, но если это единственный способ сделать это в настоящее время... почему бы не использовать генератор кода для создания отдельной библиотеки кода. Таким образом, основная библиотека остается нетронутой, а на добавленный код сообщения можно просто ссылаться. - person Matt; 01.08.2013
comment
кстати, меня смущает, насколько сложно, например, добавить символы в запрос рыночных данных. Учитывая, что это приложение-оболочка, которое в любом случае создает строковые сообщения, почему бы, например, не воспользоваться преимуществами коллекций .Net (таких как List‹string›) и позволить пользователю просто добавлять символы таким образом, а синтаксический анализ выполняется скрыто? - person Matt; 01.08.2013
comment
... в отношении моего первого комментария, в случае моего предложения библиотека потенциально даже не будет зависеть от версии QF. Тот факт, что вы, ребята, переходите на версию 1.5, скорее всего, ничего не меняет в пользовательском коде сообщения. И в том редком случае, когда вы измените свою структуру настолько сильно, что сгенерированный пользователем код потеряет совместимость, код сломается во время компиляции. Неплохо, я чувствую... просто мои 2 цента... - person Matt; 01.08.2013
comment
QF/n все еще довольно молодой проект. Нашей первоочередной задачей было сделать интерфейс похожим на другие порты QuickFIX, чтобы он оставался знакомым разработчикам. Конечно, есть вещи, которые мы можем сделать, чтобы воспользоваться преимуществами .Net, но никто их не предлагал. - person Grant Birchmeier; 01.08.2013
comment
С другой стороны, у нас есть открытые проблемы с разделением функций на подбиблиотеки. То, что вы предлагаете, не совсем исключено. - person Grant Birchmeier; 01.08.2013
comment
Грант, спасибо за ваш вклад. Тем не менее, я признаю, что все еще немного застрял в вашей идее смешивания XML-файлов datadictionary. Что мне делать, если у меня конфликтующие сообщения, потому что я хочу поддерживать 2 брокеров, которые требуют заполнения разных тегов в MarketDataRequest (V)? Должен ли я добавить обе записи xml из обоих словарей данных брокера в один и тот же xml DD версии FIX44 (конечно, учитывая, что они оба нацелены на 4.4)? Как будет создаваться код? Тот же метод, но другая подпись параметра? Не могли бы вы уточнить это? - person Matt; 02.08.2013
comment
Это ни в коем случае не критика, а просто обратная связь: я начинаю чувствовать, что может быть намного проще каждый раз создавать небезопасное сообщение, просто заполняя теги в соответствии с требованиями спецификации брокера. Это одноразовое упражнение, и оно не будет представлено конечному пользователю и не изменится. Неудобство, которое я вижу во всех этих безопасных для типов методах сообщений, заключается в том, что в большинстве случаев теги все равно приходится добавлять/манипулировать вручную. Но я признаю, что не пересобирал библиотеку с новым xml-файлом. Может быть, я пропустил какую-то концепцию здесь... - person Matt; 02.08.2013
comment
Грант, могу я подтвердить, что мне нужна Руби? Почему это? Я думал, что вызов пакетного файла запускает процесс сборки? - person Matt; 02.08.2013
comment
Грант, я пробовал, но добавление пользовательских сообщений или, если уж на то пошло, замена полного файла FIX44.xml полнофункциональным словарем данных xml от брокера не создает никакого кода, который охватывает рассматриваемые настраиваемые типы сообщений. - person Matt; 02.08.2013
comment
Генератор представляет собой скрипт Ruby. generate.bat выполняет генерацию кода. build.bat компилирует его. - person Grant Birchmeier; 02.08.2013
comment
Я попытался использовать словарь данных пользовательского брокера xml. Но после повторной сборки ни одно из пользовательских сообщений не доступно. Сборка показала, что ошибок или предупреждений не было. - person Matt; 02.08.2013
comment
Я смог сгенерировать код после установки Ruby 1.9.3 и драгоценного камня Nokugiri. - person Matt; 04.08.2013
comment
Я никогда не использовал QuickFIX/N, но для QuickFIX и QuickFIX/J вам НЕ нужно создавать библиотеку для каждого варианта словаря данных. Словарь данных требуется для синтаксического анализа (например, повторяющихся групп) и для проверки. Генерация кода — это удобство и безопасность типов. Существуют нетипобезопасные API (по крайней мере, в других реализациях QuickFIX) для создания сообщений и доступа к полям сообщений. Также легко написать собственную реализацию MessageCracker (или аналогичную). - person Frank Smith; 04.08.2013
comment
Не то чтобы мне не нравился Ruby в целом, но я всегда чувствовал, что генерация кода Ruby в QuickFIX была плохим решением. Почему бы не использовать для QuickFIX/N текстовые шаблоны T4? Я предполагаю, что это потому, что генератор Ruby уже был там из QuickFIX. - person Frank Smith; 04.08.2013
comment
Даже в других QF вам следует перегенерировать, если вы отправляете пользовательские сообщения. Что и делает мистер Вольф. - person Grant Birchmeier; 05.08.2013
comment
Опять же, это может быть необходимо в реализации QuickFIX/N, но, по крайней мере, в QuickFIX/J в этом нет необходимости. Средство форматирования сообщений использует внутреннюю коллекцию FieldMap и Group для создания сообщений. Средство форматирования ничего не знает о пользовательских и стандартных сообщениях. Он просто форматирует тег/значения в этих структурах данных. Мне нужно перепроверить, но я считаю, что то же самое с QuickFIX C++. - person Frank Smith; 05.08.2013