Настоящая статья посвящена проблеме физического и логического разделения информационных потоков в ситуациях, когда разные информационные системы участника взаимодействия обмениваются со СМЭВ разными видами сведений. Или схема информационных потоков построена таким образом, что ответы на запросы должны распределяться по определенным узлам (нодам) информационной системы.
Разделение информационных потоков в СМЭВ
При стандартном подключении участника взаимодействия (УВ) к СМЭВ предусматривается один поток сообщений между информационной системой участника взаимодействия (ИС УВ) и СМЭВ.
Существует возможность настроить (через запрос в ситуационный центр (СЦ) СМЭВ) специальные очереди СМЭВ, в которые выделяются сообщения по определенным видам сведений (ВС). При этом дискриминатором информационных потоков становятся ВС, а не узлы ИС УВ. Поэтому в случае, когда разные узлы ИС УВ обмениваются со СМЭВ одними и теми же ВС, специальные очереди не решают проблему распределения сообщений по узлам.
При стандартном подключении одна ИС УВ формирует запросы по всем видам сведений, направляет их в СМЭВ (напрямую или через адаптер) и получает ответы из СМЭВ (из адаптера). Схема такого взаимодействия с использованием адаптера приведена на Рисунке 1.
В СМЭВ для одной мнемоники ИС УВ (точнее, для одной электронной подписи, потому что идентификация ИС УВ в СМЭВ осуществляется по подписи) создаются две очереди сообщений – очередь ответов на запросы ИС УВ и очередь запросов к ИС УВ от других участников. Если для ИС УВ настроены специальные очереди, то количество очередей в СМЭВ увеличивается на количество специальных очередей.
ИС УВ, работающая со СМЭВ напрямую, забирает ответы, вызывая метод GetResponse сервиса СМЭВ. Запросы извлекаются методом GetRequest.
Оба метода, при использовании в них элемента фильтрации по ВС, дополнительно позволяют выборочно извлекать сообщения, относящиеся к определенному ВС, из специальных очередей. Для этого нужно передать в параметрах метода пространство имен нужного ВС и наименование его корневого элемента (см. Рисунок 2). Запрос GetRequestRequest имеет аналогичную структуру.
Если для связи со СМЭВ используется адаптер СМЭВ, то он автоматически забирает все сообщения из обеих «стандартных» очередей СМЭВ и сохраняет их в своей БД. Текущая версия адаптера не поддерживает работу со специальными очередями.
ИС УВ, работающая со СМЭВ через адаптер, вызывает метод get web-сервиса адаптера, который, будучи вызван без параметров фильтрации, возвращает самое раннее непрочитанное сообщение из адаптера. Каждый последующий вызов get возвращает очередное непрочитанное сообщение.
В метод get можно передать параметр фильтрации specificQuery, который принимает только два значения: REQUEST и RESPONSE. С помощью этого параметра можно получать либо запросы к ИС УВ от других участников, либо ответы на запросы ИС УВ.
Метод find более гибкий – в нем можно указать один из двух критериев поиска:
- по интервалу времени поступления сообщения в адаптер;
- по клиентскому идентификатору (clientId) сообщения.
Последний критерий дополнительно детализируется предметом поиска:
- запрос с определенным clientId;
- все ответы на запрос с определенным clientId;
- ответ с определенным clientId.
Таким образом, на текущий момент единственным способом извлекать из очереди адаптера отдельные сообщения вместо дефолтного FIFO является метод find с идентификатором сообщения. Для этого ИС УВ должна эти идентификаторы у себя хранить и реализовывать некую логику их обработки.
Проблема организации нескольких информационных потоков через СМЭВ
Нередки ситуации, когда на стороне участника взаимодействия существует несколько бизнес-процессов, каждый из которых предполагает отправку запросов в СМЭВ и получение ответов оттуда. Т.е. порождают разные информационные потоки через СМЭВ.
Например, такие ситуации типичны для негосударственных пенсионных фондов, которые в одном потоке обмениваются документами с ПФР, а в другом потоке запрашивают и получают данные о своих клиентах из ЕГР ЗАГС.
В описанной выше схеме взаимодействия задача распределения СМЭВ-сообщений по информационным потокам ложится на ИС УВ.
Например, ИС УВ может запоминать идентификаторы запросов, отправленных каждым из инициаторов взаимодействия, получать ответ из адаптера с помощью метода find, передавая в его параметре идентификатор запроса, и направлять ответ инициатору соответствующего запроса. Такое решение приводит к необходимости доработок ИС УВ и добавления в них «неродного» функционала по распределению СМЭВ-сообщений по разным функциональным модулям.
Альтернативным вариантом решения может быть регистрация в СМЭВ двух и более ИС одного участника с разными электронными подписями и установка нескольких экземпляров адаптера. Такой вариант влечет за собой прохождение полного круга регламентных процедур подключения к СМЭВ каждой ИС – получение подписей, заявления в МКС на подключение систем к тестовому СМЭВ, тестирование ВС на тестовом СМЭВ и подключение к продуктивному стенду СМЭВ.
Разделение потоков через «узлы» ИС УВ
Для элегантного решения описанной проблемы разработчики СМЭВ вводят понятие «узла» ИС УВ. Узел представляет собой обособленную часть информационной инфраструктуры участника, которая выступает в качестве отдельного получателя СМЭВ-сообщений. Узлами могут быть как разные информационные системы, так и разные функциональные блоки одной информационной системы. Т.е. «узел» понятие скорее логическое, чем физическое.
Каждый узел определяется своим идентификатором – nodeId.
Идентификаторы узлов должны регистрироваться в МКС либо одновременно с регистрацией ИС УВ, либо позже, по мере необходимости. Участнику взаимодействия по умолчанию доступно до трех узлов. Чтобы зарегистрировать большее количество, необходимо предоставить в СЦ обоснование такой потребности. Поскольку для каждого узла в СМЭВ создается отдельная очередь ответов, а следовательно, расходуются дополнительные ресурсы, такое «ограничение аппетита» участников представляется авторам СМЭВа вполне разумным.
Идентификатором узла можно пометить любой запрос, ответ на который должен прийти в указанный узел. При этом запрос не обязательно должен отправляться тем же узлом, который будет получателем ответа.
Если взаимодействие со СМЭВ организовано без использования адаптера, то ИС УВ включает элемент nodeId в сообщение SendRequestRequest, отправляемое в СМЭВ. Чтобы получить ответ из очереди конкретного узла, ИС УВ направляет в СМЭВ сообщение GetResponseRequest, в котором указывает nodeId этого узла.
Получить входящий запрос для определенного узла невозможно – для входящих запросов СМЭВ не поддерживает механизм nodeId. Хотя в схеме сообщения GetRequestRequest и присутствует такой же необязательный элемент NodeID, как и в запросе GetResponseResponse (см. Рисунок 2), но СМЭВ этот элемент игнорирует.
При взаимодействии через адаптер элемент nodeId включается в сообщение ClientMessage, отправляемое в адаптер (см. Рисунок 3).
Адаптер формирует сообщение SendRequestRequest, в котором транслируется тот же nodeId. СМЭВ в процессе доставки сообщения поставщику кодирует nodeId в элементе ReplyTo, который поставщик должен скопировать в свой ответ в соответствии с Методическими рекомендациями.
Взаимодействие с использованием Адаптера СМЭВ можно организовать двумя способами, описанными ниже.
Способ № 1. Один адаптер и несколько узлов за ним
Схема взаимодействия представлена на Рисунке 4.
Адаптер по-прежнему считывает сообщения из каждой очереди в свою базу, но теперь сохраняет в числе прочего и nodeId каждого сообщения.
Каждый узел ИС УВ может запросить в адаптере предназначенные для него ответы, передав в параметре метода get свой nodeId. Метод вернет первое непрочитанное сообщение из соответствующей очереди. Метод get без параметров возвращает первое сообщение без nodeId.
Таким образом, ИС УВ достаточно использовать для каждого информационного потока свой nodeId для того, чтобы гарантировать доставку ответов в тот поток, который породил соответствующие запросы.
Для вышеупомянутого случая с НПФ запросы в ПФР должны помечаться одним nodeId, а запросы в ЕГР ЗАГС – другим. Тогда ответы от ПФР будут приходить в первый узел, а ответы от ЕГР ЗАГС – во второй. Необходимость реализации в ИС УВ дополнительного модуля для «разбора» ответов по видам сведений отпадает.
Кроме того, новая версия Адаптера СМЭВ, по словам разработчиков, позволит раздельно работать со специальными очередями, в которых сообщения распределяются по видам сведений. Для использования этой возможности необходимо описать специальные очереди в параметрах Адаптера (предусловие – специальные очереди должны быть зарегистрированы в СЦ СМЭВ).
ИС УВ вызывает метод get Адаптера с параметром определенной специальной очереди. Метод возвращает первое непрочитанное сообщение из указанной специальной очереди.
Способ № 2. Несколько адаптеров-узлов и несколько ИС УВ за ними
В параметрах Адаптера можно указать конкретный nodeId, превратив его таким образом в узел информационной системы. Этот вариант предусматривает наличие нескольких экземпляров Адаптера (по одному для каждого nodeId + экземпляр без nodeId). Вариант с настройкой nodeId на адаптере представлен на Рисунке 5.
Каждый экземпляр адаптера читает «свою» очередь ответов из СМЭВ, а узел ИС УВ обращается к «своему» экземпляру адаптера за «своими» ответами. Узел ИС УВ может обращаться к нескольким экземплярам адаптера по разным адресам WS, получая из каждого экземпляра ответы с разными nodeId (или вовсе без nodeId в случае дефолтного адаптера).
Такой способ организации взаимодействия можно использовать при интенсивном обмене сообщениями со СМЭВ, распределяя нагрузку по нескольким адаптерам-узлам.
Резюме
Использование nodeId для распределения ответов СМЭВ по разным узлам ИС УВ позволит снизить затраты участников взаимодействия за счет экономии денег на разработке собственных решений для такого распределения или за счет экономии времени на регистрацию нескольких ИС УВ в СМЭВ. (При использовании Способа №1 определенные доработки в ИС УВ все-таки потребуются – нужно будет научить ИС УВ добавлять элемент nodeId в сообщение ClientMessage.)
В скором времени узлы ИС УВ можно будет регистрировать самостоятельно в Личном кабинете участника взаимодействия. До тех пор узлы регистрируются через обращение в СЦ СМЭВ в соответствии с регламентной процедурой по изменению ИС УВ.
Регистрация специальных очередей СМЭВ осуществляется аналогично – через обращение в СЦ СМЭВ. Через некоторое время такая возможность должна появиться в Личном кабинете участника взаимодействия.
Использование специальных очередей в структуре интеграционного решения предоставляет дополнительную к nodeId «степень свободы».
Кроме того, в ближайшей версии Адаптера СМЭВ анонсированы:
- метод get с фильтром по виду сведений;
- метод get с фильтром по прикладному содержимому.
Все это позволит участникам взаимодействия строить еще более гибкие и мощные интеграционные решения.
Если у Вас остались вопросы, комментарии или замечания по организации «узлов» информационных систем в СМЭВ, пожалуйста, напишите их в комментариях или свяжитесь с командой Хемуль IT любым удобным для Вас способом.
