1. Введение

1.1. Общие Сведения

Настоящий документ описывает правила и приёмы использования возможностей инфраструктуры электронного правительства (далее – ИЭП), которые позволяют участникам межведомственного взаимодействия (далее – УВ) решать задачи передачи сведений с использованием подсистемы обеспечения доступа к данным (далее – ПОДД) системы межведомственного электронного взаимодействия (далее – СМЭВ) между информационными системами участников взаимодействия (далее – ИС УВ).

Термины и сокращения, используемые в данном документе, представлены в соответствующем разделе.

1.1.1. Номер версии документа

Номер версии документа формируется по шаблону A.X.Y.Z, где:

A – номер версии подсистемы обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия».

X – номер поколения документа. Изменение данного номера означает значительные изменения в структуре и содержании документа.

Y – номер основного релиза документа в рамках поколения. Документ может содержать освещение новых и/или незначительную переработку содержащихся в предыдущей версии документа тем. Плановая подготовка основного релиза документа осуществляется раз в квартал. Основные релизы утверждаются Подкомиссией по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления.

Z – номер технологического релиза в рамках основного релиза. Может содержать в себе стилистические, редакционные, незначительные технические изменения. Данный тип релизов выпускается по необходимости и не проходит специализированной процедуры утверждения Подкомиссией по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления.

1.1.2. Нормативно-правовые основания

Данный документ разработан в целях реализации и во исполнение:

• Постановления Правительства Российской Федерации от 8 сентября 2010 года № 697 «О единой системе межведомственного электронного взаимодействия»;

• Распоряжения Правительства Российской Федерации от 3 июня 2019 года №1189-р «Об утверждении Концепции создания и функционирования национальной системы управления данными и плана мероприятий («дорожную карту») по созданию национальной системы управления данными на 2019–2021 годы» (далее – Концепция);

• Постановления Правительства Российской Федерации от 3 июня 2019 года № 710 «О проведении эксперимента по повышению качества и связанности данных, содержащихся в государственных информационных ресурсах»;

• Федерального закона от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг»;

• мероприятий федерального проекта «Цифровое государственное управление» национальной программы «Цифровая экономика», утверждённой на заседании правительственной комиссии по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности под председательством Председателя Правительства Российской Федерации Д. А. Медведева. 25 декабря 2018 года:

  • 06.01.011.001.004 «Разработка функциональных и технических требований к информационным системам НСУД (включая требования к функциям получения, очистки и преобразования данных, хранения и обработки данных, визуального представления данных, управления метаданными, межведомственного взаимодействия);

  • 06.01.011.001.006 Разработка, адаптация программного обеспечения и разработка архитектуры и проектных решений на НСУД и ее части, внедрение функционала НСУД, включая пусконаладочные работы, проведение предварительных испытаний, проведение опытной эксплуатации, доработку программного обеспечения, дополнительную наладку технических средств и проведение приемочных испытаний НСУД в соответствии с 06.01.011.001.005.

1.2. Виды информационного обмена с использованием СМЭВ

Виды информационного обмена, поддерживаемые СМЭВ, приведены в tab_info.

Данный документ описывает рекомендации и требования в отношении 2–4 видов обмена.

Виды информационного обмена

№	Вид информационного обмена	Характеристика
1	Обмен с использованием Видов Сведений	Обмен с фиксированной структурой запроса и ответа с использованием особого протокола обмена – Вид Сведения (далее – ВС). Описание данного вида обмена приведено в документе «Методические рекомендации по работе с Единой системой межведомственного электронного взаимодействия» [1]
2	Обмен с использованием SQL-запросов	Обмен с использованием регламентированных запросов типа «SQL-запрос». Раздел Обмен с использованием Регламентированных SQL-запросов содержит описание данного вида обмена
3	Обмен с использованием Рассылок	Обмен данными с использованием регламентированных запросов типа «Рассылка» в соответствии с созданной подпиской. Раздел Взаимодействие участников обмена содержит описание данного вида обмена
4	Обмен с использованием запросов к REST-сервису ИС Ответчика	Обмен с использованием регламентированных запросов типа «Rest-сервис» к зарегистрированным в ПОДД REST-сервисам ИС Ответчика. Раздел Обмен с использованием запросов к REST-сервису ИС Ответчика содержит описание данного вида обмена

[1]

Документ размещен на портале ЕСКС, https://info.gosuslugi.ru

1.2.1. Классификация регламентированных SQL-запросов

Классификация Регламентированных SQL-запросов приведена в tab_sql_class.

Классификация Регламентированных SQL-запросов

По количеству Витрин, в которых размещены данные, используемые в процессе выполнения запроса	Простые запросы Запросы, которые обращаются к данным, размещённым в одной Витрине Поставщика данных		Распределённые запросы Запросы, которые обращаются к связанным данным, размещённым в двух или более Витринах Поставщика данных
По типу условий отбора и способу обработки данных	Запросы по ключу Запросы, предполагающие отбор небольшого количества записей, относящихся к единичному объекту	Аналитические запросы Запросы, предполагающие обработку значительного количества записей и предполагающие получение агрегатов, а не значений из отдельных атрибутов	Выгрузки Запросы, обрабатывающие значительное количество записей, но не выполняющие вычисления, а возвращающие отобранные записи Потребителю данных
По типу допустимой вариативности	Фиксированные запросы Запросы, не предусматривающие каких-либо возможностей для Потребителя данных уточнить запрос		Параметризованные запросы Запросы, содержащий в своём определении параметры, значения которых Потребитель данных задаёт непосредственно перед выполнением запроса
По способу предполагаемого использования	Универсальные Запросы, атрибутный состав которых не имеет разметки, предполагающей какое-то специальное использование этого запроса		Многомерные Запросы, результат которого размечен так, что все возвращаемые атрибуты поделены на измерения и факты, таким образом многомерный запрос подходит для использования в средствах OLAP-анализа как источник данных

Классификация Регламентированных SQL-запросов содержит 24 класса, представляющих собой различные комбинации классифицирующих признаков, приведённых в таблице.

Например:

• универсальная простая фиксированная выгрузка;

• многомерный распределённый аналитический фиксированный регламентированный запрос;

• универсальный распределённый параметризованный запрос по ключу.

Значения классификаторов «универсальный», «простой» и «фиксированный» обычно не указываются и принимаются по умолчанию.

Например:

• «универсальная изолированная фиксированная выгрузка» – это просто «выгрузка»;

• «многомерный распределённый аналитический фиксированный регламентированный запрос» – это «многомерный распределённый аналитический регламентированный запрос».

1.3. Участники информационного обмена с использованием ПОДД СМЭВ

Участник взаимодействия - это орган или организация, участвующий в информационном обмене через СМЭВ.

participants иллюстрирует общю схему взаимодействия участников.

Участники информационного обмена с использованием ПОДД СМЭВ

При участии в информационном обмене через ПОДД УВ может одновременно выступать как в роли Поставщика и/или Ответчика, так и в роли Потребителя данных и/или Инициатора запроса в зависимости от используемого вида обмена.

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

Потребители данных имеют возможность получать сведения из Витрины Поставщиков данных следующими способами:

1. используя Регламентированный SQL-запрос (см. Раздел 1.4.1);

2. сформировав подписку на регламентированный запрос типа «Рассылка» и получая сведения в виде уведомлений об изменениях (см. Раздел 1.4.1.3).

В информационных обменах с использованием запросов к REST-сервису ИС Ответчика (без использования Витрин) УВ может иметь роль Инициатора и Ответчика. Каждый УВ может выступать одновременно как в качестве Ответчика, предоставляя данные c сервиса ИС, так и в качестве Инициатора запроса, выполняя запросы к другим УВ.

Инициаторы запроса имеют возможность получать сведения из ИС Ответчика, выполнив запрос к REST-сервису ИС Ответчика (см. Раздел 1.4.3).

Ответчики разворачивают REST-сервисы и предоставляют к нему доступ через ПОДД СМЭВ.

1.4. Информационный обмен участников взаимодействия с использованием ПОДД СМЭВ

Для осуществления возможности информационного обмена с использованием ПОДД СМЭВ должно быть обеспечено подключение ИС УВ к ПОДД СМЭВ с использованием Протокола ПОДД СМЭВ, описание которого приведено в разделе Раздел 2.1.

1.4.1. Обмен с использованием Регламентированных SQL-запросов

1.4.1.1. Общее описание информационного обмена

Регламентированные SQL-запросы предназначены для получения Потребителем сведений из Витрины Поставщика данных.

Классификация Регламентированных SQL-запросов приведена в разделе Раздел 1.2.1.

Регламентированные SQL-запросы формируются на основе Моделей данных Витрин, загруженных через ЕИП НСУД, управление запросами осуществляется через ЛК УВ.

1.4.1.2. Требования к участникам взаимодействия

1.4.1.2.1. Требования к Поставщикам данных

Поставщик данных для участия в информационном обмене с использованием Регламентированных SQL-запросов должен выполнить следующие требования.

Требования к Поставщикам данных

№	Требования	Комментарии [2]
1	Зарегистрировать ИС в СМЭВ	В соответствии с «Регламентом подключения к СМЭВ 4»
2	Развернуть и настроить в своем контуре Агент ПОДД СМЭВ	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»
3	Обеспечить сетевую связанность Агента, размещенного в инфраструктуре участника, и ПОДД СМЭВ
4	Развернуть в своем контуре ПО Витрина данных	Исходные коды ПО Витрина данных размещены в НФАП
5	Настроить ПО Витрина данных для взаимодействия с Агентом	См. раздел Протокол взаимодействия Агента ПОДД СМЭВ и Витрины Поставщика данных
6	Загрузить модель данных ПО Витрина данных в ПОДД СМЭВ	В соответствии с «Инструкция по работе в ЕИП НСУД»
7	Связать ПО Витрина данных и ИС	В соответствии с инструкцией в «Руководстве пользователя ЛК УВ»
8	Зарегистрировать Регламентированные SQL-запросы в ПОДД СМЭВ	В соответствии с «Руководством пользователя ЛК УВ»
9	Добавить критерии доступа к Регламентированному SQL-запросу

[2]

Перечисленные руководства и регламенты размещены на портале ЕСКС – https://info.gosuslugi.ru/

1.4.1.2.2. Требования к Потребителям данных

Потребитель данных для участия в информационном обмене с использованием Регламентированных SQL-запросов должен выполнить следующие требования.

Требования к Потребителям данных

№	Требования	Комментарии [3]
1	Развернуть и настроить в своем контуре Агент ПОДД СМЭВ	В соответствии с «Регламентом подключения к СМЭВ 4»
2	Развернуть и настроить в своем контуре Агент ПОДД СМЭВ	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»
3	Обеспечить сетевую связанность Агента, размещенного в инфраструктуре участника, и ПОДД СМЭВ
4	Настроить ИС, которая выполняет запросы и осуществляет обработку данных, получаемых от ПОДД СМЭВ, для взаимодействия с Агентом ПОДД СМЭВ	См. раздел Протокол взаимодействия Агента ПОДД СМЭВ и ИС Потребителя данных
5	Получить полномочия на выполнени Регламентированного SQL-запроса для своей ИС	В соответствии с «Руководством пользователя ЛК УВ»

[3]

Перечисленные руководства и регламенты размещены на портале ЕСКС – https://info.gosuslugi.ru/

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

1. Взаимодействие Ядра ПОДД СМЭВ с Агентами ПОДД СМЭВ осуществляется с использованием Протокола ПОДД СМЭВ (Протокол ПОДД СМЭВ).

2. Взаимодействие Агента Поставщика данных с Витриной Поставщика данных осуществляется с использованием зарезервированных топиков брокера сообщений Apache Kafka в соответствии со спецификацией:

   • Раздел 2.3.2 содержит перечень топиков Apache Kafka;

   • Раздел 2.3.5 содержит структуры сообщений.

3. Взаимодействие ИС Потребителя с Агента Потребителя осуществляется через REST или JDBC-интерфейс в соответствии со спецификацией Раздел 2.4.

participants_interaction_img иллюстрирует общю схему взаимодействия участников обмена.

Информационный обмен при выполнении запроса с использованием ПОДД СМЭВ

1.4.1.4. Диаграмма последовательности информационного обмена

query_process содержит диаграмму последовательности осуществления информационного обмена с использованием Регламентированных SQL-запросов.

В контуре Потребителя данных (УВ 3 или 4 на схемах):

1. ИС Потребителя данных передаёт SQL-запрос Агенту ПОДД СМЭВ. Передача запроса может осуществляться с использованием:

   • JDBC-подключения;

   • REST-интерфейса.

   Настройки подключения выполняются в рамках настройки ИС для взаимодействия с Агентом ПОДД СМЭВ согласно «Руководству администратора ПОДД СМЭВ [4] ».

   Раздел 2.4 содержит Спецификацию взаимодействия.

2. Агент Потребителя данных проверяет наличие включенного режима блокировки на отправку запросов.

3. В случае отсутствия блокировки Агент ПОДД СМЭВ передает полученный запрос в Ядро ПОДД СМЭВ с использованием Протокола ПОДД СМЭВ. Раздел 2.1 содержит Спецификацию Протокола ПОДД СМЭВ.

Ядро ПОДД СМЭВ (после получения запроса от Агента Потребителя данных):

4. Выполняет проверку ЭП ОВ, которой подписан запрос, полученный от Агента Потребителя данных.

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

6. Выполняет проверку запроса на корректность.

7. Выполняет преобразование полученной мнемоники Регламентированного SQL-запроса в SQL-выражение в соответствии с загруженным определением Регламентированного SQL-запроса.

8. Выполняет проверку соответствия указанных в запросе атрибутов и объектов Модели данных Витрины.

9. Если хотя бы одна из проверок возвращает отрицательный результат, то Ядро ПОДД СМЭВ прекращает выполнение запроса и возвращает Агенту Потребителя данных соответствующую ошибку в качестве результата запроса с использованием Протокола ПОДД СМЭВ.

10. На основании полученного от Потребителя данных запроса Ядро ПОДД СМЭВ формирует один или несколько запросов в адрес Витрин Поставщиков данных (далее – подзапросы).

11. query_process указывает, что Шаг 10 соответствует простому запросу, для которого формируется один подзапрос. Для распределенного запроса Ядро ПОДД СМЭВ формирует два или более подзапроса.

12. Выполняет проверку соответствия ограничениям, заданным в Ядре ПОДД СМЭВ:

    • на интенсивность запросов от ИС Потребителя данных за интервал времени;

    • на общий объем данных в запросе и подзапросах за интервал времени.

    В случае превышения установленных ограничений Ядро ПОДД СМЭВ прекращает выполнение запроса или подзапроса и возвращает Агенту Потребителя данных сообщение о включении режима блокировки. Агент Потребителя данных при получении такого сообщения активирует режим блокировки и отвечает ошибкой на запросы от Потребителя данных.

[4]

Размещен на портале ЕСКС – https://info.gosuslugi.ru/

Диаграмма последовательности процесса выполнения SQL-запроса, отправленного от ИС Потребителя данных

Если запрос распределённый, осуществляется оптимизация запроса:

13. Ядро ПОДД СМЭВ запрашивает у соответствующих Витрин оценку объема результатов подзапросов.

14. Передача запроса на оценку в Витрину от Агента Поставщика данных осуществляется через Apache Kafka. Раздел Протокол взаимодействия Агента ПОДД СМЭВ и Витрины Поставщика данных содержит спецификацию взаимодействия.

15. Возврат результата от Витрины в Агент Поставщика данных осуществляется также через Apache Kafka.

16. Ядро ПОДД получает оценку от Агента Поставщика данных с использованием Протокола ПОДД СМЭВ.

17. На основании полученной от Витрин оценки Ядро ПОДД СМЭВ выбирает последовательный или параллельный алгоритм выполнения подзапросов.

Ядро ПОДД СМЭВ:

18. Передаёт каждый подзапрос в соответствующий Агент Поставщика данных с использованием Протокола ПОДД СМЭВ.

В контуре Поставщика данных (УВ 1 и 2 на схемах):

19. Агент Поставщика данных получает запрос с использованием Протокола ПОДД СМЭВ и проверяет ЭП ОВ, которой подписан запрос.

    Дополнительно для простых исходных запросов Потребителя данных в рамках получения подзапроса от Ядра ПОДД в Агент Поставщика передается исходный запрос с ЭП ОВ и сертификатом Потребителя данных, отправившего исходный запрос.

Если на стороне Агента Поставщика данных развернут и включен Сервис проверки полномочий:

20. Сервис проверки полномочий выполняет проверку подтверждения полномочия на выполнение Регламентированного SQL-запроса для Потребителя данных, отправившего запрос.

21. Если для запроса не подтверждено полномочие, то Агент Поставщика прекращает выполнение запроса и возвращает Агенту Потребителя соответствующую ошибку в качестве результата запроса с использованием Протокола ПОДД СМЭВ. При подтвержденном полномочии выполнение запроса продолжается.

В контуре Поставщика данных (УВ 1 и 2 на схемах):

22. Агент Поставщика данных помещает запрос в зарезервированный топик брокера сообщений Apache Kafka.

23. Агент Поставщика данных считывает результат выполнения подзапроса из зарезервированного топика брокера сообщений Apache Kafka, формирует ответ и передает его в Ядро ПОДД СМЭВ с использованием Протокола ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

24. Ожидает результаты по подзапросам ко всем Витринам Поставщиков данных исходного запроса. Если хотя бы по одному была получена ошибка, Ядро ПОДД СМЭВ прекращает выполнение запроса и возвращает Агенту Потребителя данных соответствующую ошибку в качестве результата запроса с использованием Протокола ПОДД СМЭВ.

25. Осуществляет проверку ЭП ОВ УВ.

26. После получения результатов по всем подзапросам Ядро ПОДД СМЭВ формирует результат для исходного запроса.

27. Отправляет результат Агенту Потребителя данных с использованием Протокола ПОДД СМЭВ.

В контуре Потребителя данных (УВ 3 или 4 на схемах):

28. Агент Потребителя данных проверяет ЭП ОВ УВ.

29. Агент Потребителя данных передает ИС с использованием JDBC-подключения или REST-интерфейса результат запроса.

1.4.2. Обмен с использованием Рассылок

1.4.2.1. Общее описание информационного обмена

ПОДД СМЭВ и ПО «Витрина данных» позволяют организовать процесс автоматического:

• информирования Потребителя данных об изменениях на Витрине Поставщика данных посредством передачи уведомления об изменениях;

• размещения и актуализация данных из Витрины Поставщика данных в контуре Потребителя данных посредством снапшотов и дельт.

Такой обмен осуществляется по Подписке Потребителя данных на получение изменений данных с использованием регламентированного запроса типа «Рассылка» [5].

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

Примечание

В настоящий момент подписка не может быть поставлена на паузу. Для остановки обмена данных по подписке, она должна быть отменена.

[5]

Регламентированный запрос типа «Рассылка» и права доступа на него регистрируются аналогично Регламентированному SQL-запросу.

tab_subscription и subscription_view показывают виды подписок.

Виды подписок

	Вид	Характеристика
1	Простая	Подписка на один простой Регламентированный запрос типа «Рассылка»
2	Множественная	Подписка на несколько простых Регламентированных запросов типа «Рассылка» к таблицам одной Витрины данных
3	Распределённая	Подписка на один распределённый Регламентированный запрос типа «Рассылка»

Виды подписок

Примечание

Множественная и распределённая подписки одновременно не работают на одной Витрине (Витрина 1 на subscription_view не может одновременно участвовать в подписках на схемах в центре и справа).

Для использования Регламентированного запроса типа «Рассылка» в подписке, он должен удовлетворять следующим требованиям:

1. Общие требования к Регламентированного запроса типа «Рассылка» для использования в подписке:

1.1. Не допустимо использование в SQL-запросе параметров (за исключением статического where).

1.2. Не допустимо использование в SQL-запросе set operation («union», «minus», «intersect» и т.п.), оконных функций, коррелирующих подзапросов, группирующих функций, сортировок, common table expression, semi-join.

1.3. Используемые в запросе функции, должны поддерживаться витринами Поставщиков.

2. Дополнительные требования для нераспределённых подписок:

2.1. Количество источников данных в SQL-запросе должно быть равно одному.

3. Дополнительные требования для нераспределённых (множественных) подписок:

3.1. Количество источников данных в SQL-запросе должно быть равно одному.

3.2. Во всех SQL-запросах должна быть указана одна и та же Витрина данных (таблицы могут быть разными).

4. Дополнительные требования для распределённых подписок:

4.1. Количество источников данных должно быть равно двум (обработка большего количества в ПОДД не поддерживается).

4.2. Объединение данных в SQL-запросе должно осуществляться с помощью inner join (обработка outer join в ПОДД не поддерживается).

Раздел 1.5.3 содержит описание метаданных подписки.

Жизненный цикл подписки состоит из следующих этапов:

1. подготовительные мероприятия для регистрации подписки в соответствии с Раздел 1.4.2.2;

2. регистрация подписки в ПОДД и Витринах Поставщиков и Потребителей в соответствии с Раздел 1.4.2.4.1;

3. осуществление информационного обмена по подписке в соответствии с Раздел 1.4.2.4.2, включающего в себя:

• уведомление о наличии дельты от Поставщика;

• передачу уведомления о наличии дельты Потребителю;

• запрос у Поставщика дельты по инициативе Потребителя или ПОДД;

• передача дельты Потребителю;

4. удаление подписки в ПОДД и Витринах Поставщиков в соответствии с Раздел 1.4.2.4.3.

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

1. Подписка не обновляется. При необходимости изменений формируется новая подписка с новым идентификатором.

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

3. Механизма ограничения объема пакета отправляемых дельт не предусмотрено.

1.4.2.2. Требования к участникам взаимодействия

1.4.2.2.1. Требования к Поставщикам данных

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

Требования к Поставщикам данных для использования Рассылок

№	Требование	Инструкция [6]
1	Зарегистрировать ИС в СМЭВ	Инструкция приведена в «Регламент подключения к СМЭВ 4»
2	Развернуть и настроить в своем контуре Агент ПОДД СМЭВ	Инструкция приведена в «Руководство администратора Агента ПОДД СМЭВ»
3	Обеспечить сетевую связанность Агента, размещенного в инфраструктуре участника, и ПОДД СМЭВ	Инструкция приведена в «Руководство администратора Агента ПОДД СМЭВ»
4	Развернуть в своем контуре ПО Витрина данных	Исходные коды ПО Витрина данных размещены в НФАП
5	Настроить Витрины для взаимодействия с Агентом	См. Раздел 2.3
6	Связать ПО Витрина данных и ИС	Инструкция приведена в «Руководство пользователя ЛК УВ»
7	Загрузить модель данных Витрины в ПОДД СМЭВ	Инструкция приведена в «Регламент подключения к СМЭВ 4»
8	Зарегистрировать Регламентированный запрос типа «Рассылка», по которому будет выполняться подписка в ПОДД СМЭВ	Инструкция приведена в «Руководство пользователя ЛК УВ»
9	Добавить критерии доступа к Регламентированному запросу типа «Рассылка»	Инструкция приведена в «Руководство пользователя ЛК УВ»
10	Согласовать право доступа Потребителя к Регламентированному запросу типа «Рассылка», по которому будет выполняться Подписка	Инструкция приведена в «Регламент подключения к СМЭВ 4»
11	Зарегистрировать Подписку в ПОДД СМЭВ	Инструкция приведена в «Регламент подключения к СМЭВ 4»

[6]

Перечисленные руководства и регламенты размещены на портале ЕСКС – https://info.gosuslugi.ru/

1.4.2.2.2. Требования к Потребителям данных

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

Требования к Потребителям данных для использования Рассылок

№	Требование	Инструкция [7]
1	Зарегистрировать ИС в СМЭВ	Инструкция приведена в «Регламент подключения к СМЭВ 4»
2	Разместить в своем контуре Агент ПОДД СМЭВ, выполнить настройки для соответствующего вида обменов	Инструкция приведена в «Руководство администратора Агента ПОДД СМЭВ»
3	Обеспечить сетевую связанность Агента, размещенного в инфраструктуре участника, и ПОДД СМЭВ	Инструкция приведена в «Руководство администратора Агента ПОДД СМЭВ»
4	Развернуть в своем контуре ПО Хранилища данных по подписке и настроить его взаимодействие с Агентом	Для использования распределённых подписок необходимо использовать типовое ПО Витрина данных в качестве хранилища данных по подписке. Исходные коды Витрины размещены в НФАП. Для нераспределённых подписок допустимо использование иного ПО для хранения данных. Независимо от типа используемого ПО, его взаимодействие с Агентом ПОДД СМЭВ должно осуществляться в соответствии с Раздел 2.5 данного документа
5	Согласовать право доступа к Регламентированному запросу типа «Рассылка», по которому будет выполняться Подписка с Поставщиком данных	Инструкция приведена в «Регламент подключения к СМЭВ 4»

[7]

Перечисленные руководства и регламенты размещены на портале ЕСКС – https://info.gosuslugi.ru/

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

1. Взаимодействие Ядра ПОДД СМЭВ с Агентами ПОДД СМЭВ осуществляется с использованием Протокола ПОДД СМЭВ (Раздел 2.1).

2. Взаимодействие Агента Поставщика данных с Витриной Поставщика данных осуществляется с использованием зарезервированных топиков брокера сообщений Apache Kafka в соответствии со спецификацией:

   • Раздел 2.3.2 содержит перечень топиков Apache Kafka;

   • Раздел 2.3.5 содержит структуры сообщений;

3. Взаимодействие Агента Потребителя данных с Хранилищем данных по подписке осуществляется с использованием зарезервированных топиков брокера сообщений Apache Kafka в соответствии со спецификацией:

   • Раздел 2.5.1 содержит перечень топиков Apache Kafka;

   • Раздел 2.5.2 содержит описание структуры сообщений.

Информационный обмен с использованием Рассылок

1.4.2.4. Описание этапов

1.4.2.4.1. Регистрация подписки

Порядок регистрации подписки приведён на img_subscription_registration, соответствующее описание процесса приведено ниже.

Диаграмма последовательности – Регистрация подписки

1. Запрос на регистрацию подписки передаётся в ПОДД в соответствии с Раздел 1.5.3.

Ядро ПОДД СМЭВ:

2. Осуществляет следующие проверки:

• проверка уникальности идентификатора подписки в запросе;

• в случае множественной подписки, проверка Регламентированных запросов типа «Рассылка» на то, что они нераспределённые и источникам во всех запросах является одна Витрина данных;

• проверка Регламентированного запроса типа «Рассылка» на его наличие в ПОДД;

• проверка соответствия Регламентированного запроса типа «Рассылка» требованиям для использования в подписке (приведены в Раздел 1.4.2.1);

• проверка соответствия Регламентированных запросов на использование допустимого для информационного обмена по подписке количество Поставщиков;

• проверка наличия зарегистрированных в ПОДД Витрин данных Поставщиков и Потребителя;

• проверка наличия прав доступа ИС Потребителя к Регламентированному запросу типа «Рассылка», указанному в регистрируемой подписке;

• проверка является ли действующей версия Регламентированного запроса типа «Рассылка».

• в случае распределённой подписки, проверка на отсутствие значения в поле «cronExpression».

3. Отправляет ответ со статусом обработки запроса.

4. Определяет перечень подзапросов:

• если подписка нераспределённая, то формируется один подзапрос на получение дельты (тип - DATA);

• если подписка распределённая, формирует набор подзапросов:

  • подзапрос ключей Витрины Поставщика 1 (тип - KEYS);

  • подзапрос ключей Витрины Поставщика 2 (тип - KEYS);

  • подзапрос ключей Витрины Поставщика 1 с фильтрацией по ключам Витрины Поставщика 2 (тип - KEYS_FILTERED);

  • подзапрос ключей Витрины Поставщика 2 с фильтрацией по ключам Витрины Поставщика 1 (тип - KEYS_FILTERED);

  • подзапрос дельты Витрины Поставщика 1 с фильтрацией по ключам Витрины Поставщика 2 (тип - DATA_FILTERED);

  • подзапрос дельты Витрины Поставщика 2 с фильтрацией по ключам Витрины Поставщика 1 (тип - DATA_FILTERED);

  • подзапрос объединения частей дельт на Потребителе (тип - FINAL).

5. 12 отправляет запрос на регистрацию подписки всем участвующим в подписке Поставщикам в соответствующие Агенты.

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

6. 13 осуществляет проверку ЭП Ядра ПОДД СМЭВ;

7. 14 передает запрос на регистрацию подписки Витрине в топик <префикс>.replication.rq.

Витрина данных Поставщика:

8. 15 осуществляет проверку запроса на регистрацию подписки:

• проверка уникальности идентификатора подписки;

• проверка наличия витрины, указанной в подписке;

• проверка наличия таблицы, указанной в подписке;

• проверка корректности sql-запроса;

• проверка соответствия полей sql-запроса таблице Витрины Поставщика;

• проверка наличия атрибутов «primaryKey» и «shardingKey» в структуре итоговой таблицы.

9. 16 регистрирует подписку (устанавливает статус подписки – активная (OPENED))

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

• в случае успешной обработки запроса – структуру таблиц в топик <префикс>.replication.rs.

• в случае неуспешной обработки запроса – уведомление об ошибке в топик <префикс>.replication.err.

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

18. Пересылает структуру таблиц в Ядро ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

19. Пересылает структуру таблиц Агенту Потребителя данных.

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

20. Осуществляет проверку ЭП Ядра ПОДД СМЭВ;

21. Передает в Хранилище данных по подписке структуру таблиц с использованием топика <префикс>.replication.in.rq.

Витрина данных Потребителя:

22. Осуществляет проверку запроса на регистрацию подписки:

• проверка уникальности идентификатора подписки;

• проверка уникальности целевой таблицы подписки;

• проверка корректности sql-запроса на объединение данных.

23. Регистрирует подписку (устанавливает статус подписки – активная (OPENED))

24. Отправляет ответ в Агент ПОДД Потребителя данных:

• в случае успешной обработки - уведомление об успешном создании структуры данных в топик <префикс>.replication.in.rs.

• в случае неуспешной обработки - уведомление об ошибке в топик <префикс>.replication.in.err.

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

25. Отправляет в Ядро ПОДД СМЭВ статус обработки структуры таблиц Хранилищем данных.

Ядро ПОДД СМЭВ:

26. Регистрирует подписку.

1.4.2.4.2. Осуществление информационного обмена по рассылке

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

Диаграмма последовательности – Информационный обмен по рассылке

Витрина данных Поставщика:

1. Передаёт в Агент Поставщика уведомление о наличии дельты в топик <префикс>.delta.notification.

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

2. Передаёт уведомление в Ядро ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

3. по наличию расписания (cronExpression) определяет кто является инициатором запроса дельты – Ядро ПОДД или Потребитель . В случае распределённых подписок расписание не задаётся, инициатором запроса дельты всегда является Потребитель.

   • если расписание задано, осуществляет запрос дельты самостоятельно (переход к шагу 11). При этом если Потребитель

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

4. отправляет уведомление о наличии дельты в Агент Потребителя и не запрашивает дельту пока не придёт команда от Потребителя.

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

5. передаёт уведомление о наличии дельты Витрине Потребителя в топик <префикс>.delta.notification.in.

Витрина данных Потребителя:

6. обрабатывает уведомление о наличии новой дельты;

7. в случае распределённой подписки, определяет порядок обращения к Поставщикам;

8. посылает запрос на получение дельты в командный топик <префикс>.command.podd.

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

9. передаёт запрос в Ядро ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

10. обрабатывает запрос на получение дельты;

11. проверяет права доступа Потребителя данных

Если подписка нераспределённая:

Ядро ПОДД СМЭВ:

12. передаёт запрос дельты на Агент Поставщика.

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

13. передаёт запрос дельты Витрине Поставщика в топик <префикс>.delta.rq.

Витрина данных Поставщика:

14. обрабатывает запрос дельты;

15. передаёт дельту в Агент Поставщика:

• в случае успешной обработки запроса результат в топик <префикс>.delta.rs.

• в случае неуспешной обработки запроса - уведомление об ошибке в топик <префикс>.delta.err.

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

16. передаёт дельту в Ядро ПОДД СМЭВ.

Если подписка распределённая:

Ядро ПОДД СМЭВ:

17. передаёт запрос ключей (без фильтрации) в Агент Поставщика 1

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

18. передаёт запрос ключей (без фильтрации) Витрине Поставщика в топик <префикс>.delta.rq.

Витрина данных Поставщика 1:

19. обрабатывает запрос;

20. передаёт дельту в Агент Поставщика 1:

• в случае успешной обработки запроса результат в топик <префикс>.delta.rs.

• в случае неуспешной обработки запроса - уведомление об ошибке в топик <префикс>.delta.err.

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

21. передаёт ключи в Ядро ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

22. передаёт запрос ключей (с фильтрацией по ключам Витрины 1) в Агент Поставщика 2.

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

23. передаёт запрос ключей (с фильтрацией по ключам Витрины 1) Витрине Поставщика 2 в топик <префикс>.delta.tp.

Витрина данных Поставщика 2:

24. обрабатывает запрос;

25. передаёт пересечение ключей в Агент Поставщика 2:

• в случае успешной обработки запроса результат в топик <префикс>.delta.rs.

• в случае неуспешной обработки запроса - уведомление об ошибке в топик <префикс>.delta.err.

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

26. передаёт пересечение ключей в Ядро ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

27. 33 передаёт запрос дельты (с фильтрацией по ключам) в Агент Поставщика 1 (2).

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

28. 34 передаёт запрос дельты (с фильтрацией по ключам) в Витрине Поставщика 1 (2).

Витрина данных Поставщика 1 (2):

29. 35 обрабатывает запрос;

30. 36 передаёт дельту в Агент Поставщика 1 (2).

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

31. 37 осуществляет простановку ЭП Поставщика 1 (2)

32. 38 передаёт пересечение ключей в Ядро ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

39. передаёт дельту в Агент Потребителя

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

40. 44 проверяет ЭП Поставщика;

41. 45 передаёт дельту в Витрину Потребителя.

Витрина данных Потребителя:

42. 46 обрабатывает полученную дельту; 47. применяет дельту; 48. 50 передаёт статус применения дельты.

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

49. 51 передаёт статус применения дельты в Ядро ПОДД СМЭВ.

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

img_subscription_delete иллюстрирует порядок отмены подписки, соответствующее описание процесса приведено ниже.

Диаграмма последовательности – Удаление подписки

1. Запрос на удаление подписки передаётся в ПОДД в соответствии c Раздел 1.5.3.

Ядро ПОДД СМЭВ:

2. осуществляет проверку запрос на отмену подписки на наличие в ПОДД подписки с указанным идентификатором;

3. отправляет ответ со статусом обработки запроса;

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

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

5. 12 осуществляет проверку ЭП Ядра ПОДД СМЭВ;

6. 13 отправляет запрос Витрине Поставщика в топик <префикс>.replication.cancel.rq.

Витрина данных Поставщика:

7. 14 осуществляет проверку запроса на отмену подписки;

8. 15 отменяет подписку (устанавливает статус подписки – отменённая (CANCELED));

9. 16 отправляет ответ в Агент ПОДД Поставщика данных в топик <префикс>.replication.cancel.rs.

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

10. 17 отправляет в Ядро ПОДД СМЭВ статус обработки запроса на отмену подписки.

Ядро ПОДД СМЭВ:

18. удаляет подписку после получения ответа от всех Поставщиков вне зависимости от статуса этих ответов (успех/ошибка). При этом статус Поставщика временно (до удаления) в случае успеха меняется на CANCELLED, а в случае ошибки – ERROR.

1.4.3. Обмен с использованием запросов к REST-сервису ИС Ответчика

1.4.3.1. Общее описание информационного обмена

Обмен с использованием запросов к REST-сервису ИС Ответчика предназначен для сквозного («прозрачного») доступа ИС Инициаторов к REST-сервисам ИС Ответчиков. ПОДД СМЭВ используется в качестве канала передачи данных.

Также данный механизм обеспечивает:

1. регистрацию REST-сервисов ИС Ответчиков, описываемых спецификацией OpenAPI, в ПОДД СМЭВ через ЛК УВ;

2. разграничение доступа Инициаторов к REST-сервисам ИС Ответчиков путём использования принципа выдачи/изъятия прав на взаимодействие ИС Потребителя с REST-сервисом ИС Ответчика через ЛК УВ;

3. форматно-логический контроль запросов ИС Инициаторов и ответов ИС Ответчиков на соответствие спецификации OpenAPI зарегистрированного в ПОДД REST-сервиса.

4. механизм лимитирования запросов к REST-сервисам ИС Ответчика.

1.4.3.2. Требования к участникам взаимодействия

1.4.3.2.1. Требования к Ответчикам

Ответчик для участия в информационном обмене с использованием запросов к REST-сервису ИС Ответчика должен выполнить следующие требования.

Требования к Ответчикам

№	Требование	Инструкция [8]
1	Зарегистрировать ИС в СМЭВ	В соответствии с «Регламентом подключения к СМЭВ 4»
2	Развернуть и настроить в своем контуре Агент ПОДД СМЭВ	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»
3	Обеспечить сетевую связанность Агента, размещенного в инфраструктуре участника, и ПОДД СМЭВ
4	Развернуть в своем контуре REST-сервис ИС Ответчика
5	Настроить REST-сервис ИС Ответчика, который обрабатывает получаемые от ПОДД СМЭВ запросы, для взаимодействия с Агентом ПОДД СМЭВ	См. Раздел 2.6 данного документа
6	Зарегистрировать REST-сервис ИС Ответчика (Регламентированный запрос типа «REST-сервис») в ПОДД СМЭВ	В соответствии с инструкцией в «Руководстве пользователя ЛК УВ»
7	Добавить критерии доступа для запросов к развернутому REST-сервису
8	Для обеспечения возможности получения большого запроса размером до 30 Гб необходимо обновить версию Агента ПОДД СМЭВ до версии не ниже 3.4.0.	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»
9	При необходимости задать лимиты на выполнение запросов через Службу эксплуатации. Лимиты задаются в разрезе конкретного REST-сервиса ИС Ответчика и ИС Инициатора. Если лимиты не заданы, запросы ИС Инициатора к REST-сервису ИС Ответчика не ограничиваются. Для использования механизма лимитирования необходимо: установить версию Агента ПОДД на стороне Ответчика не ниже 3.4.0; установить версию Агента ПОДД на стороне Инициатора не ниже 3.4.0; ИС Инициатора должна осуществлять запросы к Агенту ПОДД Инициатора через порт для версии 3.4.0 или новее (см. «Руководство администратора Агента ПОДД СМЭВ»).	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»

[8]

Перечисленные руководства и регламенты размещены на портале ЕСКС – https://info.gosuslugi.ru/

1.4.3.2.2. Требования к Инициаторам запросов

Инициатор запроса для участия в информационном обмене с использованием запросов к REST-сервису ИС Ответчика должен выполнить следующие требования.

Требования к Инициаторам запросов

№	Требование	Инструкция [9]
1	Зарегистрировать ИС в СМЭВ	В соответствии с «Регламентом подключения к СМЭВ 4»
2	Развернуть и настроить в своем контуре Агент ПОДД СМЭВ	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»
3	Обеспечить сетевую связанность Агента, размещенного в инфраструктуре участника, и ПОДД СМЭВ
4	Настроить ИС, которая выполняет запросы и осуществляет обработку данных, получаемых от ПОДД СМЭВ, для взаимодействия с Агентом ПОДД СМЭВ	См. Раздел 2.4.1.3 данного документа
5	Получить полномочия на выполнение запросов к REST-сервису Ответчика (Регламентированному запросу типа «REST-сервис»)	В соответствии с «Руководством пользователя ЛК УВ»
6	Для обеспечения возможности отправки от инициатора большого запроса размером до 30 Гб необходимо: установить версию Агента ПОДД на стороне Ответчика не ниже 3.4.0; установить версию Агента ПОДД на стороне Инициатора не ниже 3.4.0; ИС Инициатора должна осуществлять запросы к Агенту ПОДД Инициатора через порт для версии 3.4.0 или новее (см. «Руководство администратора Агента ПОДД СМЭВ»); обеспечить свободный объем оперативной памяти на стороне Агента ПОДД инициатора запроса не менее размера передаваемых данных. Для версий Агента ПОДД СМЭВ ранее 3.4.0 максимальный размер запроса от инициатора при обращении к REST-сервису ИС Ответчика ограничен 5 Мб.	В соответствии с «Руководством администратора Агента ПОДД СМЭВ»

[9]

Перечисленные руководства и регламенты размещены на портале ЕСКС – https://info.gosuslugi.ru/

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

Механизм обмена с использованием запросов к REST-сервису ИС Ответчика реализован в виде комплекса взаимодействующих программных средств и артефактов, приведенных на рисунке 9.

1. Взаимодействие Ядра ПОДД с Агентами ПОДД осуществляется по Протоколу ПОДД СМЭВ в соответствии с Раздел 2.1.

2. Взаимодействие Агента ПОДД Инициатора с ИС Инициатора осуществляется с использованием REST-интерфейса в соответствии с Раздел 2.4.1.3.

3. Взаимодействие Агента ПОДД Ответчика с ИС Ответчика осуществляется в соответствии со спецификацией OpenAPI, загруженной в ПОДД СМЭВ (см. Раздел 2.6).

Информационный обмен с использованием запросов к REST-сервису ИС Ответчика через ПОДД СМЭВ

1.4.3.4. Описание этапов

1.4.3.4.1. Регистрация в ПОДД REST-сервиса ИС Ответчика и инициализация обмена

Подготовка УВ к использованию механизма запросов к REST-сервисам ИС Ответчика описана в Раздел 1.4.3.2 настоящего документа.

Этапы и основные шаги процесса:

Сотрудник УВ (img_rest_respondent_registration):

1. Реализует REST-сервис.

2. Осуществляет подготовку спецификации OpenAPI в соответствии с реализованным REST-сервисом.

Примечание

основные положения по подготовке спецификаций OpenAPI для использования в ПОДД СМЭВ приведены в подразделе 1.5.5 настоящего документа.

3. Регистрирует REST-сервиса своей ИС в ПОДД СМЭВ через ЛК УВ.

Ядро ПОДД:

4. Сохраняет метаданные REST-сервиса ИС Ответчика.

5. Отправляет подтверждение регистрации.

При обмене через механизм без возможности отправки большого запроса:

1. Агент ПОДД Инициатора, сконфигурированный для работы с механизмом обмена с использованием запросов к REST-сервису Ответчика, уведомляет Ядро ПОДД о своем запуске.

2. Ядро ПОДД передаёт в Агент ПОДД спецификации OpenAPI на REST-сервисы ИС Ответчиков в части данного Инициатора.

Диаграмма последовательности регистрации в ПОДД REST-сервиса ИС Ответчика и инициализации информационного обмена

1.4.3.4.2. Информационный обмен для механизма без возможности отправки большого запроса

Взаимодействие ИС Инициатора и ИС Ответчика при обмене с использованием запросов к REST-сервису ИС Ответчика (img_interaction_without_large_request) без возможности отправки большого запроса:

Агент ПОДД Инициатора запроса:

1. Получает запрос к требуемому REST-сервису ИС Ответчика, сформированный в ИС Инициатора, с использованием REST-интерфейса. Спецификация взаимодействия приведена в разделе 2.4.

2. Проверяет, что запрос и его параметры соответствуют спецификации OpenAPI REST-сервиса ИС Ответчика.

3. Подписывает сообщение ЭП Инициатора.

4. Передает запрос в Ядро ПОДД СМЭВ с использованием Протокола ПОДД СМЭВ.

Ядро ПОДД СМЭВ:

5. Выполняет проверку ЭП Инициатора.

6. Выполняет проверку наличия у Инициатора, отправившего запрос, соответствующих полномочий на выполнение запросов к REST-сервису. Если хотя бы одна из проверок возвращает отрицательный результат, то Ядро ПОДД СМЭВ прекращает выполнение запроса и возвращает Агенту Инициатора соответствующую ошибку в качестве результата запроса с использованием Протокола ПОДД СМЭВ.

7. Формирует и отправляет запрос Агенту Ответчика.

Агент ПОДД Ответчика:

8. Проверяет ЭП Инициатора, которой подписан запрос.

9. Извлекает из сообщения запрос и формирует абсолютный URL-адрес запроса к соответствующему методу REST-сервиса ИС Ответчика.

10. Отправляет запрос REST-сервису ИС Ответчика согласно полученному URL адресу.

REST-сервис ИС Ответчика:

11. Выполняет полученный запрос (поиск и извлечение требуемых данных, создание или модификация сущностей БД и другое).

12. Возвращает в Агент ПОДД ответ на полученный запрос с HTTP кодом статуса выполнения операции и (в зависимости от запрошенного метода) тело ответа, содержащее запрошенные данные и/или дополнительную информацию о результате выполнения операции.

Агент ПОДД Ответчика:

13. Формирует ответ и подписывает его ЭП Ответчика.

14. Передает ответ в Ядро ПОДД СМЭВ с использованием Протокола ПОДД СМЭВ. Ядро ПОДД СМЭВ: 15. Выполняет проверку ЭП Ответчика. 16. Перенаправляет результат Агенту Инициатора с использованием Протокола ПОДД СМЭВ.

Агент ПОДД Инициатора запроса:

17. Выполняет проверку ЭП Ответчика.

18. Извлекает из сообщения HTTP код и тело (если присутствует) и возвращает их в качестве ответа ИС Потребителя с использованием REST-интерфейса.

Диаграмма информационного обмена с использованием запросов к REST-сервису ИС Ответчика через ПОДД СМЭВ

1.4.3.4.3. Информационный обмен для механизма с возможностью отправки большого запроса

Взаимодействие ИС Инициатора и ИС Ответчика при выполнении запроса к REST-сервису ИС Ответчика (img_interaction_with_large_request):

Агент ПОДД Инициатора:

1. Получает запрос к REST-сервису ИС Ответчика.

2. Проверяет наличие активной блокировки на отправку запросов.

3. В случае отсутствия блокировки делит запрос на чанки:

   • чанк метаданных, который содержит параметры, заголовки и относительный URI (path), необходимые для валидации по спецификации OpenAPI REST-сервиса ИС Ответчика;

   • чанки тела запроса.

4. Подписывает чанк метаданных ЭП Инициатора.

5. Передает чанк метаданных в Ядро ПОДД по протоколу RSocket.

Ядро ПОДД:

6. Осуществляет проверку ЭП Инициатора для чанка метаданных.

7. Осуществляет поиск спецификации OpenAPI REST-сервиса ИС Ответчика и валидацию на соответствие спецификации по чанку метаданных запроса:

   • валидация осуществляется по параметрам, заголовкам и path;

   • тело запроса не валидируется.

8. Проверяет наличие у Инициатора прав доступа для обращения к REST-сервису Ответчика.

9. Выполняет проверку соответствия ограничениям, заданным на REST-сервис ИС Ответчика:

   • на количество запросов от ИС Инициатора за интервал времени;

   • на объем данных, передаваемых ИС Потребителя по всем запросам за интервал времени.

10. Осуществляет маршрутизацию запроса.

11. Подписывает ЭП Ядра ПОДД чанк метаданных запроса.

12. Передает в Агент ПОДД Ответчика чанк метаданных по протоколу RSocket или возвращает ошибку обработки запроса (при ее возникновении).

13. Получает подтверждение приема чанка метаданных от Агента ПОДД Ответчика.

14. Передает подтверждение корректности запроса Агенту ПОДД Инициатора.

Агент ПОДД Инициатора:

15. Подписывает ЭП Инициатора чанки тела.

16. ередает последовательно чанки тела запроса в Ядро ПОДД по протоколу RSocket с сохранением исходного порядка.

Ядро ПОДД:

17. Проверяет ЭП Инициатора каждого чанка тела запроса.

18. Подписывает ЭП Ядра ПОДД чанки тела запроса.

19. Последовательно передает чанки тела запроса в Агент ПОДД Ответчика по протоколу RSocket.

Агент ПОДД Ответчика:

20. Проверяет ЭП Ядра.

21. Проверяет ЭП Инициатора.

22. Выполняет проверку соответствия ограничениям, заданным на REST-сервис ИС Ответчика:

    • на количество запросов от ИС Инициатора за интервал времени;

    • на объем данных, передаваемых ИС Потребителя по всем запросам за интервал времени.

23. Формирует абсолютный URL-адрес запроса к соответствующему методу REST-сервиса ИС Ответчика.

24. Отправляет запрос данных согласно URL-адресу.

Диаграмма прохождения запроса к REST-сервису ИС Ответчика через ПОДД СМЭВ

Взаимодействие ИС Инициатора и ИС Ответчика при ответе на запрос к REST-сервису ИС Ответчика (img_answer_with_large_request):

Агент ПОДД Ответчика:

1. Получает ответ на запрос от ИС Ответчика.

2. Делит ответ на запрос на чанки:

   • чанк метаданных;

   • чанки тела.

3. Подписывает чанк метаданных ЭП Ответчика.

4. Передает чанк метаданных в Ядро ПОДД по протоколу RSocket.

Ядро ПОДД:

5. Проверяет ЭП Ответчика чанка метаданных.

6. Выполняет проверку соответствия ограничениям, заданным на REST-сервис ИС Ответчика, на объем данных, возвращаемых ИС Инициатора по всем запросам за интервал времени.

7. Маршрутизирует ответ на запрос.

8. Отправляет чанк метаданных в Агент ПОДД Инициатора по протоколу RSocket или возвращает ошибку обработки запроса (при ее возникновении).

9. Получает подтверждение приема чанка метаданных от Агента ПОДД Инициатора.

10. Передает подтверждение корректности ответа на запрос в Агент ПОДД Ответчика.

Агент ПОДД Ответчика:

11. Подписывает ЭП Ответчика чанки тела.

12. Отправляет последовательно чанки тела в Ядро ПОДД по протоколу RSocket.

Ядро ПОДД:

13. Проверяет ЭП Ответчика чанков тела.

14. Последовательно передает чанки тела в Агент ПОДД Инициатора по протоколу RSocket.

Агент ПОДД Инициатора:

15. Выполняет проверку ЭП Ответчика.

16. Извлекает из ответа на запрос HTTP код и тело (если присутствует).

17. Отправляет ответ ИС Инициатора.

Диаграмма прохождения запроса к REST-сервису ИС Ответчика через ПОДД СМЭВ

1.5. Метаданные ПОДД СМЭВ

Метаданные ПОДД СМЭВ содержат информацию о следующих объектах:

1. модели данных Витрин Поставщиков данных;

2. подписки Потребителей данных;

3. определения Регламентированных SQL-запросов;

4. REST-сервисы ИС Ответчиков, описываемые спецификацией OpenAPI;

5. полномочия Потребителей данных.

1.5.1. Поддерживаемые форматы

tab_supported_formats содержит ограничения на формат значений в загружаемых метаданных и сведения о проверках на стороне ПОДД СМЭВ.

Ограничения на формат значений в метаданных

№	Наименование	Тип	Требования к формату
1	Идентификатор	uuid	Маска: "([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})|(\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\})"
2	Мнемоника (ИС/Витрины/ Регламентированного SQL-запроса / Регламентированного запроса типа «Рассылка» /атрибута/параметра)	String	Латинские буквы, цифры и символ «_», без пробелов. Первым символом должна быть буква. Регистр не учитывается
3	Мнемоника (Витрины/ Регламентированного SQL-запроса / Регламентированного запроса типа «Рассылка»)	String	Запрещено использование зарезервированных ключевых слов SQL [10]
4	Мнемоника (Регламентированного SQL-запроса /Регламентированного запроса типа «Рассылка»)	String	Запрещено использование префикса information_schema_
5	Алиас атрибута в SQL запросе	String	Латинские буквы, цифры и символ «_», без пробелов. Первым символом должна быть буква. Регистр не учитывается
6	Версия (Витрины/ Регламентированного SQL-запроса/ Регламентированного запроса типа «Рассылка»)	String	Должна соответствовать формату <major>.< minor >: major типа int, >= 0 minor типа int, >= 0
7	ОГРН УВ (владельца Витрины/ Регламентированного SQL-запроса / Регламентированного запроса тип «Рассылка»)	String	ОГРН владельца Витрины должен соответствовать значению в ранее зарегистрированных версиях Витрины Ожидаемый формат: только цифры
8	Даты поддержки (Витрины/ Регламентированного SQL-запроса / Регламентированного запроса тип «Рассылка»)	Integer (int64)	В миллисекундах от эпохи. Временной диапазон периода поддержки Регламентированного SQL-запроса и Регламентированного запроса тип «Рассылка» должен входить в диапазоны поддержки всех Витрин, которые указаны в SQL данных Регламентированного SQL-запроса и Регламентированного запроса тип «Рассылка»
9	Текстовое описание (Витрины/ Регламентированного SQL-запроса / Регламентированного запроса тип «Рассылка»)	String	Ожидаемый формат: латинские и русские буквы, цифры, печатные символы и символы разметки (пробел, перенос строки), максимум 2000 знаков
10	Текст SQL-выражения (для Регламентированного SQL-запроса / Регламентированного запроса тип «Рассылка»)	String	Поддерживаются возможности, указанные в Раздел 3.1 данного документа
11	Тип атрибута или параметра	String	«BOOLEAN» «STRING» «SHORT» «INTEGER» «LONG» «FLOAT» «DOUBLE» «BIG_DECIMAL» «DATE» «TIME» «TIMESTAMP» «BINARY»
12	Префикс в URL для REST-сервиса ИС Ответчика (basepath)	String	Латинские буквы, цифры, символы. Из зарезервированных символов допустимы „/“ и „_“ непустая строка; начинается с символа „/“; содержит символы после „/“. Допускается несколько элементов пути, например level1/level2/level3. Двойные слэши „//“ недопустимы; параметры недопустимы, например /{parameter}; заканчивается символом, отличным от „/“
13	Спецификации OpenAPI для REST-сервиса ИС Ответчика		Поддерживаемые форматы: JSON, YAML. Максимальный размер 1 Мб

[10]

См. https://calcite.apache.org/docs/reference.html#keywords

1.5.2. Модель данных Витрины Поставщика данных

Все передаваемые, получаемые и распространяемые посредством ПОДД СМЭВ сведения должны соответствовать моделям данных Витрины Поставщика данных в Ядре ПОДД СМЭВ.

Модели данных загружаются в Ядро ПОДД СМЭВ из ФГИС «ЕИП НСУД» в соответствии с инструкцией по работе с ФГИС «ЕИП НСУД» [11].

Модель данных Витрины Поставщика данных содержит:

1. уникальную мнемонику Витрины данных;

2. ОГРН владельца Витрины данных;

3. версии Витрины данных, содержащие структуру сущностей.

Каждая версия Витрины данных содержит:

1. номер версии Витрины;

2. описание для версии Витрины;

3. срок действия версии Витрины Поставщика данных (дата начала и дата окончания действия версии Витрины);

4. перечень таблиц версии Витрины со следующей информацией:

   • мнемоника и описание таблицы;

   • перечень атрибутов таблицы с указанием типа данных;

   • первичный ключ, состоящий из мнемоник атрибутов таблицы;

   • массив уникальных ключей, состоящий из мнемоник атрибутов таблицы.

Правила/ограничения использования:

1. Модель данных Витрины Поставщика данных загружена в Ядро ПОДД СМЭВ, если загружена как минимум одна (первая) версия Витрины.

2. Значение ОГРН владельца должно быть одинаковым для всех версий Витрины данных. При несоответствии ОГРН значениям в ранее зарегистрированных версиях Витрины ПОДД вернет ошибку регистрации.

3. Актуальной версией Витрины считается максимальная по номеру среди действующих.

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

5. Для выполнения запроса к определенной версии Витрины данных необходимо в запросе после мнемоники витрины явно указать номер версии. Пример приведен в Раздел 3.1.1 настоящего документа.

[11]

Размещена на портале ФГИС «ЕИП НСУД» https://nsud.gosuslugi.ru/ifp/portals/documents и портале ЕСКС https://info.gosuslugi.ru

1.5.3. Подписки Потребителей данных ПОДД СМЭВ на регламентированный запрос типа «Рассылка»

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

tab_distribution_subscription содержит Метаданные подписки.

Метаданные Подписки

№	Атрибут	Тип	Обязательность	Описание
1	subscriptionId	String UUID	Да	Уникальный идентификатор подписки. Генерируется ПОДД в соответствии с форматом UUID.
2	RQs	array of object	Да	Массив регламентированных запросов типа «Рассылка». При указании нескольких запросов используется множественная подписка. Использование распределённых запросов в таком случае не допустимо.
2.1	queryMnemonic	String	Да	Полная мнемоника Регламентированного запроса: <мнемоника витрины>.<мнемоника РЗ> Для распределенного запроса: podd.<мнемоника РЗ>
2.2	version	String	Да	Номер версии Регламентированного запроса в формате: <major>.<minor>
3	datamartMnemonic	String	Да	Мнемоника Витрины данных Потребителя (без учёта версионности)
4	name	String	Нет	Наименование подписки (для краткой формулировки)
5	description	String	Нет	Описание подписки (для подробного описания)
6	isSnapshot	Boolean	Нет	Признак того, что сначала Потребителю нужно выгрузить снапшот. Значение по умолчанию - false
7	initiator	Boolean	Нет	Признак того, кто является инициатором запроса новой дельты: «PODD» - Ядро ПОДД; «CONSUMER» – Потребитель (Ядро ПОДД передаёт уведомления о наличии дельт Потребителю, который инициирует запрос в соответствии с собственными настройками). Значение по умолчанию - PODD
8	schedule	String	Нет	Расписание запроса Ядром ПОДД дельт у Витрины Поставщика. Представляет собой cron-выражение. Для подписок, в которых инициатором является Потребитель, значение атрибута всегда отсутствует.
9	status	String	Да	Статус подписки, формируется ПОДД по ходу регистрации и удаления подписки: REGISTRATION_REQUEST – Подписка принята к регистрации в ПОДД; REGISTRATION_ON_PRODUCER – Подписка регистрируется на Поставщике; REGISTRATION_ON_PRODUCER_ERROR – Подписка не зарегистрирована на Поставщике, возникла ошибка; REGISTRATION_ON_CONSUMER – Подписка регистрируется на Потребителе; REGISTRATION_ON_CONSUMER_ERROR – Подписка не зарегистрирована на Потребителе, возникла ошибка; REGISTERED – Подписка зарегистрирована; CANCEL_REQUEST – Принят запрос на удаление подписки (обмен по ней останавливается); CANCEL_ON_PRODUCER (Удаление на Поставщике); CANCEL_ON_CONSUMER (Удаление на Потребителе).

Функционирование Агента и Ядра ПОДД СМЭВ при формировании первоначальной выгрузки и передачи изменений подписки от Витрины Поставщика в Хранилище данных по подписке приведено в Раздел 1.4.3.1 и Раздел 2.5 данного документа.

Регистрация подписки осуществляется через:

• ЛК УВ;

• ЕИП в случае тиражирования подписок (создание копии подписки, в которой изменяется только идентификатор и витрина потребителя).

• СЭ в случае необходимости ручного вмешательства.

Также временно остаётся поддержка регистрации с использованием Вида сведения «Подписка на репликацию или уведомлений в изменении данных».

Удаление подписки осуществляется через:

• ЛК УВ;

• СЭ в случае необходимости ручного вмешательства.

Также временно остаётся поддержка удаления с использованием Вида сведения «Отмена подписки на репликацию или уведомлений в изменении данных».

1.5.4. Определения Регламентированных SQL-запросов

Загрузка Регламентированного SQL-запроса в ПОДД СМЭВ осуществляется с использованием ЛК УВ в соответствии с инструкцией в «Руководстве пользователя ЛК УВ» [12].

Состав атрибутов определения Регламентированного SQL-запроса:

1. мнемоника Регламентированного SQL-запроса;

2. версии Регламентированного SQL-запроса.

Каждая версия Регламентированного SQL-запроса содержит:

1. описание Регламентированного SQL-запроса (краткое и полное);

2. ОГРН владельца Регламентированного SQL-запроса;

3. номер версии Регламентированного SQL-запроса;

4. срок действия Регламентированного SQL-запроса (дата начала и дата окончания действия, в рамках которых возможно выполнение соответствующего запроса);

5. SQL-выражение в соответствии с Раздел 3.1 данного документа и указанными ниже ограничениями;

6. список параметров. Описание параметра включает в себя:

   • имя параметра;

   • тип параметра;

   • описание параметра;

   • значение по умолчанию.

7. список табличных параметров. Описание параметров включает в себя:

   • имя табличного параметра;

   • описание колонок табличного параметра:

     • имя колонки

     • тип колонки;

     • описание колонки.

Правила/ограничения использования:

1. Версия Регламентированного SQL-запроса не подлежит модификации. При необходимости изменить запрос создается запрос с новой версией.

2. ОГРН Владельца и мнемоника Регламентированного SQL-запроса задаются для каждой версии отдельно, поэтому контроль их соответствия у версий ложится на создателей этих версий.

3. Актуальной версией Регламентированного SQL-запроса считается максимальная по номеру среди действующих.

4. Если в новой версии Регламентированного SQL-запроса требуется изменить входные или выходные данные, при этом Потребители, уже имеющие доступ к Регламентированному SQL-запросу, не должны автоматически получить доступ к новой версии, то изменение следует выполнить через регистрацию нового Регламентированного SQL-запроса (с новой мнемоникой), а не через выпуск новой его версии.

5. Временной диапазон срока действия Регламентированного SQL-запроса должен входить в диапазоны поддержки всех Витрин, которые указаны в SQL-выражении данного Регламентированного SQL-запроса.

6. Параметры Регламентированного SQL-запроса должны соответствовать условиям:

   • табличные и именованные параметры в SQL-выражении должны соответствовать параметрам в списке;

   • мнемоники параметров должны быть уникальными в рамках Регламентированного SQL-запроса, уникальность именованных и табличных параметров сквозная;

   • мнемоника параметра не должна начинаться с «settings_» (префикс системного именованного параметра);

   • при задании параметров в SQL-выражении через «?» порядок параметров в списке должен соответствовать порядку их представления в SQL-выражении;

   • при задании параметров в SQL-выражении через «?» количество параметров в SQL-выражении должно соответствовать количеству параметров в списке;

7. SQL-выражение для Регламентированного SQL-запроса должно соответствовать условиям:

   • Витрины, имена возвращаемых атрибутов, таблицы и схема данных должны соответствовать метаданным Витрины, сохраненным в Ядре ПОДД;

   • должна быть указана конкретная версия Витрины (правильно – dtm.1.0.table; неправильно – dtm.table);

   • указанная версия Витрины должна быть зарегистрирована в ПОДД;

   • не должно быть указано несколько версий одной Витрины;

   • простой запрос должен быть к одной Витрине;

   • для простого запроса Витрина в SQL-выражении должна соответствовать Витрине, указанной в полной мнемонике Регламентированного SQL-запроса;

   • распределенный запрос должен быть к двум или более Витринам;

   • не должно быть обращений к другим Регламентированного SQL-запроса;

   • в SQL-выражении должны быть указаны конкретные возвращаемые атрибуты (возврат всех атрибутов через * запрещен). Исключение: возможно использовать * внутри операторов (пример: count ( * ));

   • возвращаемые Потребителю атрибуты должны быть уникальны с учетом подставленных алисов.

8. Если Регламентированный SQL-запрос планируется использовать в качестве Регламентированного запроса типа «Рассылка», то он должен соответствовать требованиям приведённым в Раздел 1.4.2.1.

[12]

Размещена на портале ЕСКС – https://info.gosuslugi.ru/

1.5.5. REST-сервисы ИС Ответчиков

Регистрация REST-сервиса ИС Ответчика (Регламентированного запроса типа REST-сервис) в ПОДД СМЭВ осуществляется с использованием ЛК УВ в соответствии с инструкцией в «Руководстве пользователя ЛК УВ» [13].

REST-сервис ИС Ответчика в ПОДД СМЭВ определяется следующими атрибутами:

1. Мнемоника ИС Ответчика.

2. Префикс в URL методов API (basepath).

3. Спецификация OpenAPI, описывающая REST-сервис ИС Ответчика.

4. Признак необходимости сквозной передачи подписи Инициатора Ответчику (по умолчанию true).

Правила разработки спецификаций OpenAPI, используемых для описания и регистрации REST-сервисов Ответчиков в ПОДД СМЭВ: [14]

1. Следует руководствоваться форматом проектирования спецификаций OpenAPI версии 3.0 (в том числе минорных версий 3.0.1, 3.0.2 и т.д.).

2. В спецификациях OpenAPI могут быть использованы все типы HTTP-методов (POST, GET, PUT и DELETE), выполняющих CRUD-операции (Create/Read/Update/Delete).

3. Допустимые форматы: YAML или JSON.

4. Максимальный размер: 1 Мб. Примеры спецификаций OpenAPI, используемых в работе с REST-сервисами в ПОДД СМЭВ:

[13]

Размещена на портале ЕСКС – https://info.gosuslugi.ru/

[14]

Дополнительную информацию можно получить в статье https://info.gosuslugi.ru/articles/Как_создать_свою_спецификацию_OpenAPI/

1.5.5.1. Спецификация OpenAPI, описывающая REST-сервис с функцией возврата запрошенных данных от ИС Ответчика

{
 "openapi": "3.0.1",
 "info": {
    "title": "Letters content | Содержимое писем",
    "version": "1.0"
 },
 "servers": [
    {
       "url": "/"
    }
 ],
 "tags": [
    {
       "name": "Letters content | Содержимое писем"
    }
 ],
 "paths": {
    "/api/v1.0/letters/{mailId}/{date}/pdf": {
       "get": {
       "tags": [
          "Letters content | Содержимое писем"
       ],
       "summary": "Получение содержимого письма в формате PDF",
       "operationId": "getLetterPdf",
       "parameters": [
          {
             "name": "Authorization",
             "in": "header",
             "description": "Authorization header",
             "required": true,
             "schema": {
             "type": "string"
             }
          },
          {
             "name": "mailId",
             "in": "path",
             "description": "ШПИ",
             "required": true,
             "schema": {
             "type": "string"
             }
          },
          {
             "name": "date",
             "in": "path",
             "description": "Дата",
             "required": true,
             "schema": {
             "type": "string"
             }
          },
          {
             "name": "accessCode",
             "in": "query",
             "description": "Код доступа",
             "required": true,
             "schema": {
             "type": "string"
             }
          }
       ],
       "responses": {
          "200": {
             "description": "ОК",
             "content": {}
          },
          "400": {
             "description": "Некорректный запрос",
             "content": {}
          },
          "401": {
             "description": "Некорректный идентификатор клиента и/или токен",
             "content": {}
          },
          "403": {
             "description": "Доступ запрещен",
             "content": {}
          },
          "404": {
             "description": "Запрашиваемый ресурс не найден",
             "content": {}
          },
          "500": {
             "description": "Внутренняя ошибка сервиса",
             "content": {}
          }
       }
       }
    },
    "/api/v1.0/letters/{mailId}/{date}/content": {
       "get": {
       "tags": [
          "Letters content | Содержимое писем"
       ],
       "summary": "Получение содержимого письма в формате ZIP",
       "operationId": "getLetterContent",
       "parameters": [
          {
             "name": "Authorization",
             "in": "header",
             "description": "Authorization header",
             "required": true,
             "schema": {
             "type": "string"
             }
          },
          {
             "name": "mailId",
             "in": "path",
             "description": "ШПИ",
             "required": true,
             "schema": {
             "type": "string"
             }
          },
          {
             "name": "date",
             "in": "path",
             "description": "Дата",
             "required": true,
             "schema": {
             "type": "string"
             }
          },
          {
             "name": "accessCode",
             "in": "query",
             "description": "Код доступа",
             "required": true,
             "schema": {
             "type": "string"
             }
          }
       ],
       "responses": {
          "200": {
             "description": "ОК",
             "content": {}
          },
          "400": {
             "description": "Некорректный запрос",
             "content": {}
          },
          "401": {
             "description": "Некорректный идентификатор клиента и/или токен",
             "content": {}
          },
          "403": {
             "description": "Доступ запрещен",
             "content": {}
          },
          "404": {
             "description": "Запрашиваемый ресурс не найден",
             "content": {}
          },
          "500": {
             "description": "Внутренняя ошибка сервиса",
             "content": {}
          }
       }
       }
    }
 },
 "components": {}
}

2. Спецификация OpenAPI, описывающая REST-сервис с функцией модификации данных ИС Ответчика:

{
 "openapi": "3.0.2",
 "info": {
    "description": "Спецификация OpenAPI 3.0 для сервиса записи на приём к врачу",
    "version": "1.0",
    "title": "Запись на приём к врачу – OpenAPI 3.0"
 },
 "paths": {
    "/booking/book": {
       "post": {
       "summary": "Бронирование слота",
       "description": "Бронирование слота",
       "operationId": "book",
       "requestBody": {
          "description": "Запрос",
          "content": {
             "application/json": {
             "schema": {
                "$ref": "#/components/schemas/BookRequest"
             }
             }
          },
          "required": true
       },
       "responses": {
          "200": {
             "description": "Успешная операция",
             "content": {
             "application/json": {
                "schema": {
                   "$ref": "#/components/schemas/BookResponse"
                }
             }
             }
          },
          "400": {
             "description": "Неверные параметры"
          },
          "500": {
             "description": "Внутренняя ошибка"
          }
       }
       }
    },
    "/booking/cancel": {
       "post": {
       "summary": "Отмена брони",
       "description": "Отмена брони",
       "operationId": "cancel",
       "requestBody": {
          "description": "Запрос",
          "content": {
             "application/json": {
             "schema": {
                "$ref": "#/components/schemas/CancelRequest"
             }
             }
          },
          "required": true
       },
       "responses": {
          "200": {
             "description": "Успешная операция",
             "content": {
             "application/json": {
                "schema": {
                   "$ref": "#/components/schemas/BookResponse"
                }
             }
             }
          },
          "400": {
             "description": "Неверные параметры"
          },
          "500": {
             "description": "Внутренняя ошибка"
          }
       }
       }
    }
 },
 "components": {
    "schemas": {
       "BookRequest": {
       "type": "object",
       "properties": {
          "bookId": {
             "type": "string"
          },
          "slotId": {
             "type": "string"
          },
          "patient_id": {
             "type": "string"
          },
          "booking_type": {
             "type": "string"
          },
          "caseNumber": {
             "type": "string"
          },
          "preliminaryReservation": {
             "type": "boolean"
          },
          "referral_id": {
             "type": "string"
          },
          "cards_id": {
             "type": "string"
          },
          "email": {
             "type": "string"
          },
          "mobilePhone": {
             "type": "string"
          }
       },
       "required": [
          "bookId",
          "slotId",
          "patient_id"
       ]
       },
       "BookResponse": {
       "oneOf": [
          {
             "$ref": "#/components/schemas/BookResponseSuccess"
          },
          {
             "$ref": "#/components/schemas/BookResponseError"
          }
       ]
       },
       "BookResponseSuccess": {
       "type": "object",
       "properties": {
          "bookExtId": {
             "type": "string"
          },
          "slotId": {
             "type": "string"
          },
          "visitTime": {
             "type": "string"
          },
          "duration": {
             "type": "string"
          },
          "serviceId": {
             "type": "string"
          },
          "organizationId": {
             "type": "string"
          },
          "areaId": {
             "type": "string"
          },
          "queueNumber": {
             "type": "string"
          },
          "pincode": {
             "type": "string"
          },
          "window": {
             "type": "string"
          },
          "status": {
             "$ref": "#/components/schemas/Status"
          }
       },
       "required": [
          "bookExtId",
          "slotId",
          "visitTime",
          "status"
       ]
       },
       "BookResponseError": {
       "type": "object",
       "properties": {
          "status": {
             "$ref": "#/components/schemas/Status"
          }
       },
       "required": [
          "status"
       ]
       },
       "CancelRequest": {
       "type": "object",
       "properties": {
          "bookExtId": {
             "type": "string"
          },
          "patient_id": {
             "type": "string"
          }
       },
       "required": [
          "bookExtId",
          "patient_id"
       ]
       },
       "Status": {
       "type": "object",
       "properties": {
          "statusCode": {
             "type": "integer"
          },
          "statusMessage": {
             "type": "string"
          }
       },
       "required": [
          "statusCode"
       ]
       }
    }
 }
}

1.5.6. Полномочия Потребителя данных ПОДД СМЭВ на доступ к данным

Потребителю данных могут быть предоставлены следующие типы полномочий:

• полномочия на выполнение произвольных SQL-запросов;

• полномочия на выполнение Регламентированных SQL-запросов;

• полномочия на выполнение запросов к REST-сервису ИС Ответчика;

• полномочия на Рассылку.

1.5.6.1. Полномочия на выполнение произвольных SQL-запросов

Предоставляется автоматически и только владельцам Витрин данных на их собственные Витрины данных.

1.5.6.2. Полномочия на выполнение Регламентированных SQL-запросов

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

Полномочия могут быть предоставлены только на Регламентированного SQL-запроса целиком. Права на атрибуты Регламентированного SQL-запроса не выдаются.

При наличии полномочий на выполнение Регламентированного SQL-запроса Потребитель данных автоматически получает доступ ко всем версиям этого запроса, включая будущие. Выдача полномочий в ПОДД СМЭВ осуществляется с использованием ЛК УВ в соответствии с инструкцией в «Руководстве пользователя ЛК УВ» [15].

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

[15]

Размещена на портале ЕСКС – https://info.gosuslugi.ru/

1.5.6.3. Полномочия на выполнение запросов к REST-сервису ИС Ответчика

Полномочия на выполнение запросов к REST-сервису ИС Ответчика (Регламентированный запрос типа «REST-сервис») предоставляются на все запросы, указанные в загруженной в ПОДД СМЭВ спецификации OpenAPI для соответствующего REST-сервиса ИС Ответчика. Права на использование отдельных методов и запросов REST-сервиса не выдаются.

Управление полномочиями осуществляется с использованием ЛК УВ в соответствии с инструкцией в «Руководстве пользователя ЛК УВ» [16].

1.5.6.4. Полномочия на Рассылку

Полномочия на доступ к Регламентированному запросу типа «Рассылка» предоставляются исключительно органам исполнительной власти. Использование Регламентированных запросов типа «Рассылка» кредитными организациями и в коммерческих целях запрещено. Управление полномочиями осуществляется через запрос в СЦ в соответствии с инструкцией «Регламент подключения к СМЭВ 4» [16].

[16] (1,2)

Указанные документы размещены на портале ЕСКС, https://info.gosuslugi.ru

1.6. Типы данных ПОДД СМЭВ

Поддерживаемые ПОДД СМЭВ типы данных и соответствующие им физические и логические типы данных avro приведены в tab_smev_data_types.

Типы данных приведены к используемым в системе Prostore (каноническое avro).

Соответствие типов данных ПОДД СМЭВ и типов данных avro

№	Описание типа	Размерность	Имя типа ПОДД	Возможные значения	Физический тип avro	Логический тип avro	Особенности соответствия типов
1	Строка		STRING	не ограничено	string
2	Целое число	8 байт	LONG	от −9223372036854775808 до 9223372036854775807	long
3	Целое число	2 байта	SHORT	от −32768 до 32767	int
4	Целое число	4 байта	INTEGER	от -2147483648 до 2147483647	int
5	Дата	4 байта	DATE	от -2147483648 до 2147483647	int	date	unix epoch в днях, от -5 883 516 года до 5 883 515 года
6	Время	8 байт	TIME	от −9223372036854775808 до 9223372036854775807	long	time-micros
7	Числовые данные с плавающей запятой	4 байта	FLOAT	от – (2-2-23) * 2127 до (2-2-23) * 2127	float
8	Числовые данные с плавающей запятой	8 байт	DOUBLE	от -1.7 * 10308 до 1.7 * 10308	double
9	Большие числовые данные с плавающей запятой		BIG_DECIMAL	не ограничено	string	BigDecimalLogicalType
10	Временная метка	8 байт	TIMESTAMP	от −9223372036854775808	long	timestamp-micros или LocalDateTimeLogicalType	unix epoch в микросекундах, от – 292277 года до 292277 года
11	Двоичные данные		BINARY	не ограничено	bytes или record
12	Булевый тип	1 байт	BOOLEAN	true, false	boolean