Спецификация сообщений

Торгового репозитария НКО АО НРД

рус, en

Структура сообщений

Элементами верхнего уровня, с которыми ведётся работа, являются сообщения. Как отмечалось ранее, сообщение - это xml-файл, корневой тэг которого определяет тип (содержание и назначение) сообщения. Рассмотрим подробно структуру сообщений, их иерархию, основные блоки и примеры заполнения.

Иерархия сообщений

Базовым типом для всех сообщений является тип <Message>. Этот тип нельзя использовать напрямую (создавать xml-файлы с корневым тэгом <message>). От него наследуются несколько более специализированных типов сообщений, также являющихся абстрактными:

<NotificationMessage>: Сообщение-оповещение, не предполагающее ответа от адресата.
<RequestMessage>: Сообщение-запрос, предполагающее получение ответа на него от адресата.
<ResponseMessage>: Сообщение-ответ на запрос <RequestMessage>.

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

Сообщения, наследники Message. Все являются абстрактными типами (их нельзя использовать напрямую).

Некоторые сообщения, наследники RequestMessage

Некоторые сообщения, наследники CorrectableRequestMessage

Некоторые сообщения, наследники NonCorrectableRequestMessage

Структура сообщения

Структура всех используемых сообщений во многом единообразна и имеет лишь незначительные особенности у разных типов сообщений. На схеме ниже приводится структура одного из основных сообщений - <nonpublicExecutionReport>. Мы приводим структуру именно этого сообщения в качестве примера, так как она является наиболее характерной.

nonpublicExecutionReport

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

header

Заголовок сообщения, содержащий общую техническую информацию о сообщении.

messageId

Идентификатор сообщения, присвоенный ему отправителем

creationTimestamp

Время создания сообщения

sentBy

Отправитель сообщения

sendTo

Получатель сообщения

isCorrection

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

asOfDate

Дата, на которую рапортуются бизнес-события.

asOfTime

Время создания отчёта.

Event.model

Один из элементов, описывающих бизнес-событие: сделка, внесение изменений, терминация сделки, события жизненного цикла.

party

Один из блоков, описывающих участников.

partyId

Репозитарный идентификатор участника

partyName

Наименование участника

relatedParty

Ссылка на участника, играющего по отношению к описываемому участнику определённую роль

partyReference

Ссылка на участника

role

Роль

party

Один из блоков, описывающих участников.

partyId

Репозитарный идентификатор участника

partyName

Наименование участника

relatedParty

Ссылка на участника, играющего по отношению к описываемому участнику определённую роль

partyReference

Ссылка на участника

role

Роль

account

Один из блоков, описывающих клиента участника.

accountId

Репозитарный идентификатор клиента

accountName

Наименование клиента

servicingParty

Ссылка на участника, обслуживающего клиента.

Заголовок

Заголовок присутствует во всех без исключения сообщениях. В нём передаётся базовая информация о сообщении, такая как идентификаторы отправителя и получателя, время создания сообщения, время жизни и прочее.

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

Заголовок сообщения

Обобщённая структура

inReplyTo

Идентификатор сообщения, в ответ на которое направленно данное сообщение.

messageId

Идентификатор сообщения, присвоенный ему отправляющей стороной.

sentBy

Идентификатор стороны, направляющей сообщение

sendTo

Идентификатор стороны, получающей сообщение

copyTo

Идентификатор стороны, получающей копию сообщения

creationTimestamp

Дата и время создания сообщения.

expiryTimestamp

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

partyMessageInformation

Дополнительная информация о сообщении, которую хочет передать участник.

Корреляция сообщений

Как правило сообщения не независимы и образуют некоторую последовательность. Простейшим вариантом такой последовательности может быть пара сообщений "запрос-ответ".

Однако физически сообщения могут приходить в случайной последовательности и нельзя полагаться на то, что при отправке запросов с номерами 1 и 2, полученные последовательно ответы 1 и 2 будут соответствовать запросам с такими же порядковыми номерами.

Для того, чтобы можно было отвязаться от порядка физического движения сообщений через транспортные системы, в стандарте используется набор узлов CorrelationId.model, фактически состоящий из одного узла - <correlationId>.

Принцип использования этого узла следующий. Отправляя исходное сообщение, инициирующее какой-либо бизнес-процесс, отправитель задаёт для него уникальный <correlationId>. Далее, все сообщения, относящиеся к этому бизнес-процессу также должны содержать тэг <correlationId> с тем же значением, что и инициирующее сообщение.

Так, например, если сообщение <nonpublicExecutionReport> содержит узел <correlationId> 123 </correlationId>, то любое из последующих сообщений <nonpublicExecutionReportException>, <nonpublicExecutionReportAcknowledgement>, <nonpublicExecutionReportRetracted> должны также содержать элемент <correlationId> 123 </correlationId>.

Бизнес-события

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

Trade

Описание сделки.

trade

Описание сделки

tradeHeader

Заголовок сделки

partyTradeIdentifier

Описание идентификатора сделки, присвоенного ей одной из сторон

partyTradeIdentifier

Описание идентификатора сделки, присвоенного ей одной из сторон

tradeDate

Дата сделки

product

Блок, в котором описывается конкретный финансовый инструмент. Так на месте этого блока могут быть fxSwap, fxOption, и другие блоки, унаследованные от product.

documentation

Описание правовой основы сделки.

masterAgreement

Структура данных определяющая генеральное соглашение, в рамках которого совершена данная сделка

masterAgreementType

Тип генерального соглашения

masterAgreementVersion

Версия генерального соглашения

masterAgreementDate

Дата, в которую было заключено генеральное соглашение

masterAgreementId

Уникальный идентификационный номер Генерального соглашения, присвоенный репозитарием

nsdSpecificTradeFields

Блок полей, связанных со специфичными требованиями локального регулятора.

dealStatus

Состояние обязательств по сделке (договору)

reconciliationType

Условия согласования параметров сделки (договора) при регистрации в репозитарии

dfiCode

Код производного финансового инструмента, указывается в соответствии с Приказом ФСФР

relationCode

Код взаимосвязи элементов различных видов производных финансовых инструментов, указывается в соответствии с Приказом ФСФР

clearSettlmentType

Тип расчетов

clearSettlmentMethod

Метод расчетов

regulatoryStatus

Классификационный признак отнесения правового статуса продукта к производным финансовым инструментам согласно действующему регулированию

Amendment

Описание изменений условий сделки.

amendment

trade

Исходное бизнес-событие (сделка) с внесёнными изменениями.

Информация об участниках

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

Для этого в стандарте описывается набор узлов <PartiesAndAccounts.model>, с помощью которого можно описать участников и их клиентов, фигурирующих в данном сообщении. И далее в других частях сообщения использовать ссылки на эти описания.

<!-- Первый участник. Аттрибут id используется для того, чтобы ссылаться на данного участника. -->
<party id="first">
    <!-- Идентификатор участника. Тип идентификатора задаётся атрибутом partyIdScheme. Значение 
    атрибута по умолчанию http://www.nsd.ru/repository/fpml-5.4/coding-schemes/partyid -->
    <partyId>RP0000000001</partyId>

    <!-- Название участника. -->
    <partyName>Сторона 1</partyName>

    <!-- Описание взаимосвязи между двумя участниками. Это опциональный блок.-->
    <relatedParty>
        <!-- Ссылка на описание участника в данном документе. -->
        <partyReference href="reporter"/>
        <!-- Роль relatedParty, по отношению к party. Набор ролей определяется схемой, задаваемой
        в атрибуте partyRoleScheme. Значение атрибута по умолчанию: http://www.fpml.org/coding-scheme/party-role -->
        <role>ReportingParty</role>
        <!-- 
            Дополнительный элемент, уточняющий роль relatedParty. Например, в этом узле передаётся информация
            о том, по договорам каких типов имеет право отчитываться информирующее лицо. Набор значений определяется схемой,
            задаваемой в атрибуте partyRoleTypeScheme. Значени атрибута по умолчанию: 
            http://www.fpml.org/coding-scheme/party-role-type
            -->
        <type>ALL</type>
    </relatedParty>
</party>

<!-- Второй участник. -->
<party id="second">
...
</party>

<!-- Третий участник. Например, информирующее лицо. -->
<party id="reporter">
    <!--  -->
    <partyId>RP0000000002</partyId>
    <!--  -->
    <partyName>Банк "Информатор"</partyName>
</party>

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