Обмены в СМЭВ 4 с использованием подписок

Одним из способов обмена между несколькими участниками взаимодействия (УВ) посредством СМЭВ4 является использование регламентированных запросов (РЗ) типа Рассылка.

При использовании РЗ типа Рассылка осуществляется автоматическая передача измененных данных из витрины ИС Поставщика в адрес информационной системы (ИС) Потребителя.

Использование РЗ типа Рассылка даёт следующие преимущества:

• Всегда актуальные данные на текущий момент времени: Поставщик уведомляет СМЭВ4 о наличии новых записей в автоматическом режиме, после чего СМЭВ4 забирает изменения из Витрины Поставщика и передаёт их в Витрину Потребителя;
• Потребителю нет необходимости самостоятельно запрашивать новые данные с помощью РЗ: изменения из Витрины Поставщика передаются в Витрину Потребителя в фоновом режиме, без необходимости ручного выполнения регламентированного запроса.

  Примечание

 Этот процесс итерационный и повторяется каждый раз при появлении на Витрине Поставщика новых данных в соответствии с атрибутами, указанными в зарегистрированном РЗ 

РЗ типа «рассылка» создаётся в ЕИП НСУД.

При создании РЗ необходимо учитывать следующие ограничения: 

• Разрешено зарегистрировать один РЗ на одну таблицу, при этом в РЗ нельзя использовать алгоритмы с использованием JOIN!
• В РЗ нельзя использовать агрегирующие функции (min, max, count, и пр.).
• В РЗ нельзя использовать сортировку, группировку.
• В РЗ нельзя использовать динамические параметры.
• При создании РЗ необходимо установить флажок Тип запроса – Рассылка:

Рисунок 1 – ЕИП НСУД. Окно создания регламентированного SQL-запроса. Характеристики запроса

Чтобы изменения из Витрины Поставщика передавались в Витрину Потребителя в автоматически, без необходимости ручного выполнения регламентированного запроса, необходимо оформить подписку на выполнение РЗ типа Рассылка.

Создание подписки

Как создать подписку в ЛК УВ, описано в Руководстве пользователя ЛК УВ на портале ЕСКС в разделе Документы ЛК УВ (см. п.п.5.19.2 Создание новой подписки).

Существуют два вида подписок на РЗ типа «рассылка»:

–      Репликация (со снапшотом, т.е. с первичной выгрузкой всех данных из Витрины Поставщика, обязательно подпадающих под условие РЗ);
–      Уведомление (изменения в данных на Витрине Поставщика после создания подписки, обязательно подпадающие под условие РЗ).

Ограничения:

• Репликация (со снапшотом, т.е. с первичной выгрузкой всех данных из Витрины Поставщика) недоступна для коммерческих организаций.
• Недопустимо, чтобы два и более РЗ в рамках одной подписки ссылались на одну таблицу;
• На Витрине Потребителя не должно быть создано одноименных таблиц, участвующих в запросе;
• Одна Витрина (схема данных) может выступать поставщиком для нескольких подписок, но Потребителем – только для одной.

  Примечание

 В одной подписке могут быть несколько РЗ

Настройка Витрины данных для работы подписок

Сценарий для Поставщика:

1.  Развернута и запущена Витрина данных.
2.  Настроен и запущен Агент СМЭВ4.
3.  Агент и Витрина данных связаны в ЛК УВ с ИС.
4.  ИС в ЛК УВ задана роль Поставщик.
5.  В Витрине данных установлены компоненты podd-adapter-replicator и podd-adapter-group-repl. Описание установки данных компонентов приведено в статье  Установка дополнительных компонентов витрины стандарт.
6.  РЗ типа Рассылка (с учётом всех ограничений, описанных ниже) зарегистрирован, отправлен в ПОДД СМЭВ, Потребителю выданы права на данный РЗ.

Сценарий для Потребителя, использующего ПО «Витрина данных»:

1.  Развернута и запущена Витрина данных.
2.  Настроен и запущен Агент СМЭВ 4.
3.  Агент и Витрина данных связаны в ЛК УВ с ИС.
4.  ИС в ЛК УВ задана роль Потребитель или Поставщик/Потребитель.
5.  В Витрине данных установлены компоненты podd-adapter-group-repl и podd-adapter-replicator. Описание установки данных компонентов приведено в статье Установка дополнительных компонентов витрины стандарт.
6.  Создана отдельная схема для исключения конфликта дельт (достаточно одной таблицы в схеме с одним атрибутом по первичному ключу primary key, при этом наименование должно отличаться от наименования реплицируемых таблиц.
7.  Получен доступ к РЗ типа «подписка».
8.  Подписка на РЗ создана в ЛК УВ.
9.  При необходимости – настроить динамический топик (при отсутствии динамического топика необходимо дублировать Адаптеры). Настройка динамического топика описана в статье Настройка нескольких витрин в ПО «Витрина данных» через динамический топик.

  Примечание

 podd-adapter-group-repl – это модуль группировки чанков репликации на стороне Витрины Потребителя. 
При обмене по подписке выполняет следующие функции:
–     группирует фрагменты данных подписки, полученные из топика delta.in.rq;
–     размещает данные во временные топики с именем mppw.data.[hash(requestId+subscriptionId)].deltaNum.streamNum;
–     отправляет команду в топик subscription.in модулю подписок при получении lastChunk на загрузку сгруппированных фрагментов (по каждой дельте каждого стрима).

  Важно!

 Существует проблема конфликта дельт, если подписка прилетает в существующую витрину. Поэтому целесообразно для подписок использовать отдельную схему данных,  например, создать модель Витрины-хранилища для хранения данных по подписке с минимальным набором – одна таблица с одним атрибутом с первичным ключом (primary key), при этом можно использовать один комплект ПО «Витрина данных» (ВД). О том, как как развернуть несколько витрин на одном ПО, читайте в статье – Настройка нескольких витрин в ПО «Витрина данных» через динамический топик.

Информационный обмен с использованием подписок состоит из нескольких этапов:

1.  Регистрируется подписка в СМЭВ4 и Витрине Поставщика данных, создается структура данных в Витрине Потребителя данных.
2.  Данные актуализируются методом передачи пакета дельт от Витрины Поставщика данных в Витрину Потребителя. При этом используется вариант обмена:

–     по событию об изменении данных.

Данный информационный обмен сопровождается следующими ограничениями:

• Подписку на Рассылку нельзя обновить (то есть изменить РЗ или его версию). При необходимости внести изменения в подписку потребуется сформировать новую, заранее удалив старую.
• В схеме данных Витрины Потребителя недопустимы изменения данных, кроме процесса получения новых дельт от Витрины Поставщика.
• Механизм ограничения размера пакета отправляемых дельт не предусмотрен.

Взаимодействие участников обмена

Взаимодействие Агента Поставщика данных с Витриной Поставщика и с Витриной-хранилищем данных Потребителя осуществляется с использованием зарезервированных топиков брокера сообщений Apache Kafka в соответствии со спецификацией (Рисунок 2). Более подробно с перечнем топиков Apache Kafka и структурой сообщений можно ознакомиться в документе «Методические рекомендации по работе с СМЭВ4» раздел «2.2 Протокол взаимодействия Агента СМЭВ4 и Витрины Поставщика данных» на портале ЕСКС в разделе Документы СМЭВ4.

Рисунок 2 – Информационный обмен с использованием подписки на уведомления об изменениях

Первоначальная выгрузка данных

Порядок формирования первоначальной выгрузки всех данных, удовлетворяющих РЗ, показан на схеме ниже (Рисунок 3):

Рисунок 3 – Схема процесса формирования начальной выгрузки

Сценарии:

• Агент Поставщика данных:

1)     Передает запрос на регистрацию подписки Витрине (топик <мнемоника Витрины>.replication.rq):
-       Получает структуру таблиц в случае успешной обработки запрос Витриной (топик <мнемоника Витрины>.replication.rs);
-       Получает уведомление об ошибке в случае неуспешной обработки (топик <мнемоника Витрины>.replication.err).
2)     Пересылает структуру таблиц в Ядро СМЭВ4.

• Ядро СМЭВ4:

1)     Проверяет подпись Агента Поставщика данных.
2)     Пересылает структуру таблиц далее Агенту Потребителя.

• Агент Потребителя данных:

1)     Проверяет подпись Агента Поставщика данных.
2)     Передает в Витрину-хранилище данных структуру таблиц (с использованием топика replication.in.rq):
-       Получает уведомление об успешном создании структуры данных в случае успешной обработки (топик <мнемоника Витрины>.replication.in.rs);
-       Получает уведомление об ошибке в случае неуспеха (топик <мнемоника Витрины>.replication.in.err).
3)     Отправляет обратно в Ядро СМЭВ4 статус обработки структуры таблиц Витрины-хранилища данных.

• Ядро СМЭВ4, после получения удовлетворительного ответа о создании структуры данных на витрине Потребителя данных:

1)     Проверяет наличие новых данных по подписке.
2)     Обращается к Поставщику данных за изменениями в реплицируемой таблице и транслирует эти изменения в витрину Потребителя данных.
3)     Данный процесс итерационный. После уведомления поставщика о наличии новых данных  шаг 2 повторяется.

Процесс получения пакета дельт

Порядок получения пакета дельт показан на схеме ниже (Рисунок 4):

Рисунок 4 – Схема процесса получения пакета дельт

Агент Поставщика осуществляет:

1. Получение уведомления на Витрине Поставщика (топик <мнемоника Витрины>.delta.notification) о наличии новых данных;
2. Пересылка уведомления в Ядро ПОДД.

Ядро СМЭВ4:

3. Проверяет полномочия Потребителей данных, указанных в подписке.
4. Отправляет запрос пакета дельт Агенту Поставщика, если права у потребителей есть и Потребитель успешно применил предыдущую дельту.

Далее Агент Поставщика данных выполняет:

5. Запрос пакета дельт у Витрины Поставщика (через топик <мнемоника Витрины>.delta.rq);

-        Получение пакета дельт (топик <мнемоника Витрины>.delta.rs) при успешной обработке запроса Витриной Поставщика.
-        Получение уведомления об ошибке при неспешной обработке (топик <мнемоника Витрины>.delta.err).

6. Пересылку пакета дельт в Ядро ПОДД;

Ядро СМЭВ4 выполняет:

7. Проверку подписи Агента Поставщика.
8. Пересылку пакета дельт Агенту Потребителя.

В свою очередь Агент Потребителя:

9. Проверяет подпись Агента Поставщика.
10. Передает пакет дельт в Хранилище данных (через топик delta.in.rq).

Витрина-хранилище данных последовательно применяет дельты из пакета:

11. Получает уведомление об успешной загрузке пакета дельт (топик <мнемоника Витрины>.delta.in.rs с указанием номера последней дельты).
12. Получает уведомление об ошибке при загрузке пакета дельт (топик <мнемоника Витрины>.delta.in.err) – в случае неуспешной обработки Хранилищем.
13. Отправляет в Ядро СМЭВ4 статус обработки пакета дельт Хранилищем данных.

Удаление подписки

Процесс удаления подписки описан в Руководстве пользователя ЛК УВ (п.п. 5.19.3 Удаление подписки).

Порядок удаления подписки в СМЭВ4 показан на схеме ниже (Рисунок 5):

Рисунок 5 – Схема процесса удаления подписки

Ядро СМЭВ4 проверяет наличие новых запросов на удаление подписки, после чего отправляет запрос на удаление подписки в Агента Поставщика данных.

Агент Поставщика данных:

1.      Отправляет запрос Витрине Поставщика (топик <мнемоника Витрины>.replication.cancel.rq).
2.      Получает ответ от Витрины (топик <мнемоника Витрины>.replication.cancel.rs).
3.      Отправляет в Ядро СМЭВ4 статус обработки запроса на удаление подписки.

Ядро СМЭВ4 отправляет запрос на удаление подписки в Агента Потребителя данных.

Агент Потребитель данных:

1.      Отправляет запрос Витрине – хранилищу данных по подписке (топик <мнемоника Витрины>.replication.cancel.in.rq).
2.      Получает ответ от Витрины – хранилища данных по подписке (топик <мнемоника Витрины>.replication.cancel.in.rs).
3.      Отправляет в Ядро СМЭВ4 статус обработки запроса на удаление подписки.

Типовые ошибки при регистрации/работе подписок и способы их устранения

При регистрации подписки:

1.      Если при регистрации подписки статус Отправлена на регистрацию сохраняется более 30 мин., следует оформить заявку в СЦ, указав мнемонику Витрины Поставщика, Витрины Потребителя и примерное время регистрации подписки:

Рисунок 6 – Регистрация подписки. Статус: Отправлена на регистрацию

2.      Если статус Регистрация на Поставщике сохраняется дольше 30 минут, следует выполнить следующие действия:

Рисунок 7 – Регистрация подписки. Статус: Регистрация на Поставщике

–     Проверить наличие компонентов adapter-replicator, adapter-group-repl на Витрине Поставщика.
–     Проверить корректность настройки указанных выше компонентов и Apache Kafka.
–     Проверить доступность ИС, направив тестовый запрос select 1 из Агента Поставщика.

Для того чтобы направить тестовый запрос, необходимо перейти на ВМ, где установлен Агент Поставщика, скопировать и выполнить текст запроса ниже:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": {"sql": "select 1"}}' http://localhost:8192/query --silent -m 30

–     Проверить доступность Витрины (запрос к таблице витрины).

Для проверки работы Витрины достаточно направить простой запрос от Агента Поставщика к таблице Витрины. Пример такого запроса:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": {"sql": "Select * from мнемоника_витрины.название_таблицы limit 10"}}' http://localhost:8192/query --silent -m 30

–     Перезапустить adapter-replicator, adapter-group-repl.
–     Если все предыдущие шаги не привели к успеху, оформить заявку в СЦ.

3.      Если статус Регистрация на Потребителе сохраняется долее 30 минут, следует выполнить следующие действия:

Рисунок 8 – Регистрация подписки. Статус: Регистрация на Потребителе

–     Проверить наличие компонентов adapter-replicator, adapter-group-repl на Витрине Потребителя.
–     Проверить корректность настройки указанных выше компонентов и Apache Kafka.
–     Проверить доступность ИС (направив тестовый запрос select 1 из Агента Потребителя).

Для того чтобы направить тестовый запрос, необходимо перейти на ВМ, где установлен Агент Потребителя, скопировать текст запроса ниже и выполнить запрос:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": {"sql": "select 1"}}' http://localhost:8192/query --silent -m 30

–     Проверить доступность Витрины.

Для проверки работы Витрины достаточно направить простой запрос от Агента Потребителя к таблице Витрины. Пример такого запроса:

curl -X POST -H "Accept-Version:1" -H "Content-Type: application/json" -d '{"sql": {"sql": "Select * from мнемоника_витрины.название_таблицы limit 10"}}' http://localhost:8192/query --silent -m 30

–     Перезапустить adapter-replicator, adapter-group-repl. –     Если предыдущие шаги не привели к успеху, оформить заявку в СЦ.

Примечание

Данные должны подпадать под условия РЗ, иначе они не попадут в рассылку!

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