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

Внедрение СМЭВ — беспрецедентный интеграционный проект в России. Если раньше для получения услуги гражданам необходимо было обойти несколько учреждений и множество кабинетов, чтобы собрать все справки и документы, то сейчас все намного проще. За счет организации работы электронного правительства, получение любой услуги становится минутным делом. Все благодаря тому, что теперь существует система, в которой в автоматическом режиме происходит быстрый обмен информацией между независимыми ведомствами.

В этой статье рассказываем про устройство СМЭВ, как работает система и какие инструменты интеграции нужно использоваться, чтобы подключиться к сервису.

Основные определения и понятия

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

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

Система упрощает и ускоряет обмен данными в электронном виде, а значит, гражданам не нужно часами простаивать в очереди, чтобы получить ответ на простой запрос. Благодаря СМЭВ реализуется принцип «единого окна». Человек обращается за услугой в одно из профильных ведомств, а специалисты собирают необходимые данные через систему межведомственного электронного взаимодействия. Никакой бумажной волокиты, потраченного времени и испорченных нервов.

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

прямую
ссылку на статью

Структура сообщения, передаваемого в СМЭВ от ИС Отправителя к ИС Получателя, зависит от протокола обмена.

Различают следующие протоколы обмена:

  • Простой
  • Директивный

Структура сообщения в случае использования простого протокола обмена

Структура сообщения, передаваемого в СМЭВ от ИС Отправителя к ИС Получателя, в случае использования простого протокола обмена приведена на рисунке 1.

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

Рисунок 1 – Структура сообщения с запросом сведений, которое ИС Отправителя передаёт в СМЭВ

Элементы XML-структуры на рисунке изображены в виде прямоугольников со скруглёнными (за исключением СМЭВ-конверта) краями, с привязкой к элементам (имена соответствующих элементов XML-структуры приведены в верхнем левом углу прямоугольников). Обязательные элементы изображены непрерывной линией, а необязательные – пунктирной.

Если элемент подписывается ЭП, то в его состав должен быть добавлен атрибут с наименованием «Id».

СМЭВ-конверт с запросом сведений по простому протоколу обмена (//SendRequestRequest), направляемый ИС отправителя в СМЭВ (для последующей передачи запроса из СМЭВ в ИС получателя), включает следующие элементы:

  • блок данных запроса (//SenderProvidedRequestData), который включает структурированные сведения в соответствии с требованиями поставщика, а также служебные данные, заполняемые потребителем сведений;
  • блок содержимого вложений (//AttachmentContentList);
  • электронная подпись органа власти (ЭП-ОВ) (//CallerInformationSystemSignature).

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

Структура сообщения, передаваемого в СМЭВ от ИС Отправителя к ИС Получателя, в случае использования директивного протокола обмена, приведена на рисунке 2.

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

Рисунок 2 – Структура сообщения с запросом сведений, которое ИС Отправителя передаёт в СМЭВ

СМЭВ-конверт с запросом сведений по директивному протоколу обмена (//SendRequestRequest), направляемый ИС Отправителя в СМЭВ (для последующей передачи запроса из СМЭВ в ИС Получателя), включает следующие элементы:

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

На данный момент в СМЭВ существует 3 среды (разработки, тестовая и продуктивная) и для каждой из них – по 3 адреса для обращения к единому сервису. С появлением серьезной модификации транспортной части СМЭВ появлялся новый адрес обращения. И несколько изменялась схема, согласно которой работал единый сервис. Что ввело за собой повышение ее версии. Поэтому всего схем три: 1.1, 1.2, 1.3. Т.е. каждому адресу соответствует своя схема.

Схема СМЭВ – это набор правил, структурированных сведений, согласно которым формируются XML сообщения для обмена в едином сервисе. Каждая версия схемы имеет свой несколько отличающийся список допустимых блоков и элементов.

Версия 1.1 считается устаревшей. Но участники, желающие остаться на этой версии, еще могут получать и отправлять сообщения. При этом им не доступна возможность получать статусные сообщения от СМЭВ.

С выводом следующего транспортного узла появилась схема 1.2. Перечень используемых элементов расширился – добавились новые. Но со временем схему 1.1 также усовершенствовали, добавив в нее те же элементы.

Со схемой 1.1 можно ознакомиться тут, со схемой 1.2 – тут.

Версия 1.3 была введена для обеспечения возможности использовать директивные протоколы обмена. Ранее применялись простые. Директивные отличаются от простых наличием директив, которые описываются элементом Registry и пространством имён:

Также в версии 1.3. были добавлены:

1)      Элемент //SendRequestRequest/Routing, содержащий директиву с маршрутной информацией. Структура директивы представлена на Рисунке 1.

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

Рисунок 1 – Структура директивы с маршрутной информацией.

2)      Элемент //Registry в блок структурированных сведений (//MessagePrimaryContent).

3)      Расширено описание типа AttachmentHeaderList, предназначенного для передачи заголовков и ЭП-СП вложений, передаваемых МТОМ (Рисунок 2 – было, Рисунок 3 – стало).

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

Рисунок 2 – Описание блока AttachmentHeaderList для версии схемы 1.2.

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

Рисунок 3 – Описание блока AttachmentHeaderList для версии схемы 1.3.

4)    Расширено описание типа RefAttachmentHeaderList, предназначенного для передачи заголовков и ЭП-СП вложений, передаваемых FTP (Рисунок 4 – было, Рисунок 5 – стало).

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

Рисунок 4 – Описание блока RefAttachmentHeaderList для версии схемы 1.2.

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

Рисунок 5 – Описание блока RefAttachmentHeaderList для версии схемы 1.3.

Со схемой 1.3 можно ознакомиться тут. Подробное описание элементов указано в разделах 5.2.2-5.2.5 Методических рекомендаций СМЭВ 3.

Для взаимодействия по какому-либо ВС с применением новых полей схемы СМЭВ версии 1.3 необходимо, чтобы на указанную версию перешли все участники: и инициатор, и ответчик этого ВС.

В случае, если инициатор и ответчик работают по разным версиям Единого сервиса (1.1/1.2 и 1.3), на стороне получателя сообщения необходимо отключить проверку ЭЦП отправителя сообщения. Осуществлять только проверку подписи СМЭВ. В противном случае для корректной вариации ЭЦП отправителя сообщения инициатору и ответчику необходимо работать по одной версии (1.3).

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

Больше проверок:  Регистрационный номер в контролирующем органе, соответствующем выбранному виду деятельности, где найти Постановление Правительства Российской Федерации от 16 апреля 2021 г. N 604 "Об утверждении правил формирования и ведения единого реестра контроля (надзора) деятельности и о внесении изменений в Постановление Правительства Российской Федерации от 28 апреля 2015 г. N 415" (с изменениями и дополнениями)

Необходимо только разобраться, какой протокол больше подходит для подготавливаемого ВС (ссылки на статьи по протоколам). Структура конвертов для простого и директивного протокола несколько отличается и схематично представлена на Рисунке 6. Здесь же видим, что при использовании простых протоколов обмена доступно обращение ко всем адресам Единого сервиса СМЭВ по схемам 1.1, 1.2 (порт 7500) и 1.3 (порт 5000). При использовании директивных протоколов – только к адресу, открытому по 5000 порту.

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

Рисунок 6 – Схема с описанием структуры СМЭВ-конвертов при обращении к разным портам СМЭВ.

Но! Если УВ присоединяется к ранее зарегистрированному обмену, необходимо обращаться к тому же адресу СМЭВ 3, по схеме которого зарегистрирован ВС.

Выяснить схему можно следующими способами:

1)  Узнать в Ситуационном центре (СЦ), написав запрос с типом Информационно-методическая поддержка (Рисунок 7);

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

Рисунок 7 – Пример формы Создания запроса через СЦ.

2)  Связавшись с владельцем ВС или представителем разработчика, контакты которого указаны в Руководстве пользователя ВС в разделе Контактная информация. Руководство размещено в ЛК УВ и технологическом портале СМЭВ 3 в карточке ВС.

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

Статья написана в развитие темы, поднятой в предыдущей публикации – «Шишки, набитые при работе с адаптером СМЭВ». Рассматривается практический опыт реализации интеграционного решения на базе Адаптера СМЭВ. В роли адаптера используется бесплатное решение, представленное на технологическом портале СМЭВ 3 в разделе «Полезные ссылки». Текст подготовлен коллективом авторов – участников экспертного проекта «Хемуль IT».

Исходные положения проекта

Масштаб межведомственного взаимодействия: Заказчик выступает потребителем порядка 20 различных видов сведений.

Интенсивность взаимодействия: 100 тысяч запросов в сутки.

Особенности архитектуры решения:

  • для подготовки данных СМЭВ-запросов и обработки данных ответов Заказчик использует собственную информационную систему (ИС);
  • ИС расположена в закрытом контуре, перенос информации из ИС в СМЭВ-проект осуществляется в полуавтоматическом режиме посредством файлового обмена;
  • часть видов сведений требует подписания запроса ЭП должностного лица;
  • все сертификаты хранятся на физических токенах и являются неэкспортируемыми.
  • администратор решения должен иметь возможность контролировать статус обработки СМЭВ-запросов, скорость ответа Поставщика, timeout-ы;
  • администратор решения должен видеть расширенный набор статусов обработки СМЭВ-запросов, в том числе уведомления о поступлении запроса в ИС Поставщика;

Сервер приложений развернут на виртуальной машине CentOS под управлением VMWare. Характеристики сервера довольно средние: 4 ядра, 4 ГБ оперативной памяти, 500 ГБ дискового пространства.

У Заказчика используется криптошлюз ПАК ViPNet Coordinator HW1000.

Для взаимодействия со СМЭВ был выбран Адаптер из раздела «Полезные ссылки» технологического портала СМЭВ 3, к которому ИС заказчика подключается в режиме файлового обмена.

В качестве криптопровайдера установлена связка КриптоПро CSP 4.0 + Trusted Java 2.0. Лицензии на оба продукта были приобретены заранее, причем клиентские, поскольку CentOS по классификации КриптоПро не относится к серверным операционным системам.

Здесь требуется отметить один нюанс, связанный с Trusted Java. В отличие от КриптоПро, который сразу поставляется с пробной лицензией, пробную лицензию на Trusted Java нужно заказывать по электронной почте, указанной на сайте производителя.

Поскольку Заказчику необходимо получать информацию о состоянии запросов, в Адаптере была использована СУБД PostgreSQL. Такое решение показалось нам с точки зрения самостоятельного развития и доработки проекта более предпочтительным, чем использование штатной СУБД Derby.

Сложность заключается в том, что при установке PostgreSQL в ней требуется вручную создавать схемы для каждой ИС участника взаимодействия. Для Derby это делается автоматически.

SQL-файл со скриптами схемы обнаружился в одном из jar-файлов из поставки Адаптера, а именно в smev-service-adapter-storage-postgresql-1.1.8.jar. Там в папке sql находится файл с названием amalgamation.sql. Этот файл был извлечен из jar-архива, модифицирован (название схемы TEST1 заменено на мнемонику ИС Заказчика) и выполнен в psql.

В документации на Адаптер все эти манипуляции, к сожалению, не описаны, поэтому у некоторых разработчиков складывается мнение, что Адаптер не поддерживает PostgreSQL.

Для сбора интересующих Заказчика данных о состоянии запросов в стандартной схеме Адаптера была создана дополнительная таблица state.

Общая архитектура в первом приближении

Первая реализация СМЭВ-проекта имела следующий вид:

Internal Gateway – набор каталогов файловой системы, с которым взаимодействует ИС Заказчика. В каталог Requests помещаются запросы в СМЭВ, а из каталога Responses забираются ответы (и иногда сообщения об ошибках). В каталоге Logs просматриваются лог обработки запросов, в том числе информация о статусах, достижении суточного лимита запросов на один вид сведений (в соответствии с заявкой на доступ к ВС), ошибках и таймаутах.

External Gateway – набор штатных каталогов Адаптера СМЭВ, которые он использует для взаимодействия с ИС УВ в режиме подключения через файловую систему.

PostgreSQL – это база данных Адаптера СМЭВ (слегка доработанная).

PHP-адаптер – это консольное приложение Transformer, написанное на PHP и выполняющее следующие функции:

  • чтение файла с запросом из каталога Requests (если есть файл вложения, то ИС заказчика передает его в одном архиве с запросом);
  • формирование client_id;
  • подпись запроса (и вложения, если есть) ЭЦП должностного лица (если требуется в виде сведений);
  • преобразование запроса в формат Адаптера СМЭВ (XSLT-преобразование, которое в конверт ClientMessage вставляет мнемонику ИС Заказчика, сформированный clientId, MessagePrimaryContent с исходным запросом и PersonalSignature, если она нужна, обработка файла вложения, если он есть);
  • сохранение преобразованного запроса в папку OUT, а файла вложения (если есть) в папку local-storage;
  • регистрацию факта обработки запроса в таблице state БД Адаптера;
  • чтение файла с ответом из каталога OUT и вложения (если есть) из каталога base_storage;
  • получение (через XSLT) из конверта ответа содержимого элемента MessagePrimaryContent;
  • сохранение бизнесовой части ответа в каталоге Responses (если ответ с вложением, то вложение упаковывается в один архив с бизнес-ответом);
  • обновление статусов отправленных запросов в таблице state БД Адаптера;
  • выгрузка статусов отправленных запросов из таблицы БД в noSQL-формат в каталог Logs.

Как видно из приведенной схемы, все работает очень просто. ИС Заказчика оперирует с форматами видов сведений в том виде, как они опубликованы на технологическом портале СМЭВ, и не заботится о каких-либо СМЭВ- или Адаптер-конвертах.

Реализации подписи СМЭВ-запросов и обновленная архитектура решения

Подпись должностного лица сначала создавалась с помощью утилиты signertool, которая входит в состав «Рекомендуемой версии библиотек для сборки клиента СМЭВ 3» (см. раздел «Полезные ссылки» технологического портала СМЭВ 3). На вход утилите подаётся команда -cmd signXml, имя файла с запросом и имя файла, в который нужно положить подпись.

Больше проверок:  Советы экспертов по оценке энергоэффективности предприятия для максимизации экономии

И тут начинаются проблемы. Если контейнер с подписью находится на физическом токене, его поиск с виртуальной машины осуществляется очень долго (20-30 секунд). В нашем случае обе подписи (ИС УВ и должностного лица) находились на RuToken’ах и были неэкспортируемыми. Поэтому, как только началась передача большого количества запросов с подписью должностного лица, общая производительность решения кардинально сократилась. Задерживалась вся очередь запросов, поскольку её обработка производилась последовательно.

Первое, что было сделано – вынос процесса подписи запросов в отдельный поток. Файлы с видами сведений, которые требуют подписи ЭП-СП, фильтруются Transformer’ом по маске в имени файла и оставляются в папке Requests без обработки. К их обработке привлекли отдельное приложение Signer, которое подписывает запрос с помощью той же утилиты signertool и запаковывает его вместе с подписью в архив. Архив возвращается в папку Requests, где уже обрабатывается Transformer’ом.

Теперь запросы, не требующие подписи должностного лица, стали уходить быстрее. Но в целом проблему это не решило – запросы по-прежнему подписывались слишком медленно. Даже запуск Signer’а в нескольких параллельных потоках не спас ситуацию. 10 потоков увеличивали скорость подписания всего в 1,5 раза.

Тогда мы провели доработку приложения signertool. Приложение, как и вся библиотека, поставляется с исходными кодами. Теперь вместо одного файла подписываются все файлы, находящиеся в папке, имя которой передаётся в командной строке, а подписи помещаются в другую папку, передаваемую там же.

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

Просьба к коллегам

Если у кого-нибудь найдётся решение проблемы с физическими токенами под виртуальными машинами, и вы можете им поделиться – будем весьма признательны. Сообщить о том, что такое решение существует, можно в редакцию D-Russia.ru.

Таким образом, схема решения приняла окончательный вид:

Расширение перечня стандартных статусов обработки СМЭВ-запросов

При больших объёмах межведомственного взаимодействия запросы иногда «теряются» – запрос направлен, ответ отсутствует. Поставщик не может оперативно ответить, получен ли и отработан ли запрос. Когда в ходе промышленной эксплуатации решения количество спорных ситуаций вида «кто виноват в том, что нет ответа на запрос» превысило порог терпения разработчиков, было решено воспользоваться возможностью отслеживания расширенных статусов запросов, предоставляемой по запросу в ситуационный центр (СЦ) СМЭВ.

Существует процедура, позволяющая подключить два дополнительных статуса обработки СМЭВ-запроса – «запрос поступил в очередь Поставщика» и «Поставщик забрал запрос из очереди». После одобрения соответствующей заявки, направляемой через СЦ электронного правительства, из СМЭВ начали поступать новые сообщения о статусах запросов, эти статусы Адаптер преобразовывал в сообщения ClientMessage с элементом status.

Потребовалось доработать PHP-адаптер для того, чтобы он мог правильно интерпретировать сообщения о статусах, после чего в файле с состоянием запросов появились статусы POSTED (запрос помещён в очередь поставщика) и DELIVERED (запрос прочитан поставщиком из очереди).

С учетом того, что ранее были реализованы статусы PREPARED (запрос обработан в PHP-адаптере и помещен в каталог Адаптера СМЭВ), TIMEOUT (запрос, который пробыл в статусе SENT более 30 дней и по нему не пришло сообщений о статусе), OVERLIMIT (запрос, необработанный PHP-адаптером по причине превышения суточного лимита по виду сведений), REJECTED (вернулся ответ с элементом reject), а также с учётом стандартных статусов SENT, QUEUE, ANSWERED и FAILED от Адаптера, модель статусов запроса приобрела следующий вид:

Интерфейс администратора для контроля состояния запросов

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

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

По каждому запросу в веб-интерфейсе отображаются данные о названии исходного файла запроса, текущем статусе запроса, СМЭВ-id запроса и ответа, времени направления запроса и последнего обновления его статуса, возвращаемых СМЭВ ошибках (при их наличии).

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

Техническая реализация функционала выстроена следующим образом:

  • при обработке нового файла с запросом в таблице state фиксируется его наименование, штамп времени обработки, clientID, наименование ВС, ключевые параметры запроса (например, ФИО при запросе ИНН или ОГРН при запросе выписки из ЕГРЮЛ), статус PREPARED (или OVERLIMIT, если по данному ВС превышен суточный лимит запросов);
  • созданная запись обогащается из штатной таблицы Адаптера message, которая связывается с таблицей state по clientID, значениями messageID (идентификатор запроса в СМЭВ), штампом времени отправки запроса в СМЭВ, новым статусом (SENT, QUEUE или FAILED);
  • при обработке ответа в таблицу state из той же таблицы message добавляются СМЭВ-идентификатор ответа, штамп времени получения ответа и новый статус (FAILED, ANSWERED, POSTED, DELIVERED, REJECTED). Причем, последние три статуса Адаптер интерпретирует в своей таблице как ANSWERED, поэтому при обновлении state PHP-адаптер анализирует не только таблицу message, но и содержимое ответа;
  • для всех статусов, кроме ANSWERED, в таблице state заполняются поля «Источник сообщения», «Код сообщения» и «Текст сообщения» для предоставления пользователю более подробной информации о статусе запроса;
  • ежедневно все запросы в статусе SENT, отправленные более 30 дней назад (этот параметр настраивается в properties PHP-адаптера), переводятся в статус TIMEOUT.
  • Веб-интерфейс обращается к постоянно пополняемой и обновляемой таблице state и таким образом предоставляет пользователю в реальном времени полную картину состояния отправленных запросов.

Особенности проведения тестирования видов сведений

Для тестирования новых видов сведений в тестовом СМЭВ был собран стенд, аналогичный описанному выше. Стенд работает под Windows на рабочем компьютере администратора.

Больше проверок:  Реестр проверок Контрольной палаты и Счетной палаты выявил расхождения в оценке госимущества в Москве на 1 трлн руб

Перед тестированием параметр development.transport.persist.soap Адаптера СМЭВ включается в положение true (этим обеспечивается сохранение Адаптером сообщений в формате СМЭВ), в настройках PHP-адаптера включается режим isTesting (этим обеспечивается вставка элемента testMessage в конверт Адаптера и затем в конверт СМЭВ), токены с подписями переносятся на тестовый стенд (да, основной процесс при этом ставится на паузу, но подписи, напоминаем, неэкспортируемые) и производится отправка тестовых запросов к тестовому СМЭВ.

При этом на вход подаются эталонные запросы из документации на ВС, которые проходя через всю цепочку превращаются в запросы СМЭВ и помещаются вместе с ответами в корневой каталог Адаптера. Запросы и ответы в формате СМЭВ затем вручную подбираются попарно, запаковываются в архив и отправляются в СЦ СМЭВ в качестве результатов тестирования ВС.

Решение стабильно работает у Заказчика на протяжении года и практически не нуждается в сопровождении. Администраторы Заказчика периодически проверяют факт наличия запущенного процесса Адаптера СМЭВ, доступность контейнеров с подписями и их актуальность (срок действия), объем свободного места на диске. Эти действия проводятся регулярно при регламентных профилактических работах.

Все проектные работы выполнялись двумя IT-специалистами – разработчиком (90% работ) и linux-администратором (10% работ). Наличие готового и работоспособного Адаптера СМЭВ позволило нам в короткие сроки и с относительно невысокими затратами реализовать полноценное (включающее этап тестирования видов сведений) интеграционное решение, к тому же высоконагруженное.

GUI Адаптера не использовался. Общение с системой производилось через настроечные файлы (properties) в одну сторону и noSQL-логи и «самописный» интерфейс Мониторига СМЭВ в другую.

Наличие бесплатного полнофункционального Адаптера СМЭВ – настоящий подарок для исполнителя работ по обеспечению межведомственного взаимодействия. Выражаем благодарность разработчикам решения и Минкомсвязи за этот проект.

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

  • поработать над полнотой и прозрачностью документации, т.к. некоторые знания в настоящий момент можно получить только опытным путем;
  • сформировать wiki для Адаптера СМЭВ или сделать отдельную площадку для обмена опытом;
  • создать и разместить на технологическом портале обучающие ролики по особо сложным темам.

Несмотря на определенные сложности с настройкой, бесплатный Адаптер СМЭВ является гибким, надёжным инструментом, который позволяет реализовывать высоконагруженные проекты. Он облегчает работу интеграторам и экономит средства Заказчиков.

Следите за нашим Телеграм-каналом, чтобы не пропускать самое важное!

Поделиться

Чтобы организация могла стать членом СМЭВ, необходимо выполнить следующие шаги:

  • Оформить заявку на присоединение к регламенту, а также заявку на регистрацию.
  • Доработать собственную информационную систему. Возможно потребуется разработать электронные сервисы/интерфейсы для взаимодействия СМЭВ. В этом вопросе необходимо отталкиваться от требований оператора узла и следовать методическим рекомендациям.
  • Задействовать мероприятия для защищенности канал связи между используемой в организации системой и непосредственно СМЭВ. При подаче заявки важно проконтролировать доступность сервиса.
  • Получить разрешение на предоставление доступа к сервису.

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

Узайте больше о возможностях КСК. Шлюз

Простое ваимодействие множества разнородных информационных систем

  • Единый протокол интеграции
  • Гарантированная доставка сообщений
  • Более 1000 готовых адаптеров
  • Мониторинг цепочек взаимодействия
  • Совместимость с технологиями СМЭВ 2 и СМЭВ 3

Функционал СМЭВ и обеспечение

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

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

Для быстрого и эффективного подключения предлагаем использовать готовое решение от «КСК. Технологии». Дальше рассказываем о продукте и его преимуществах.

Законодательная база

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

Для исполнения этого закона и реализации принципа «одного окна» ведомства самостоятельно осуществляют взаимодействия через СМЭВ — инстанции могут быстро обменяться документами и всей информацией, которая может потребоваться при оказании услуг. Такой подход ускоряет удобен для обеих сторон — ускоряет и упрощает предоставление услуги, гарантирует конфиденциальность и сохранность данных.

Также межведомственное взаимодействие регламентируется постановлениями РФ № 697 и № 1222.

Решение для интеграции

«КСК. Шлюз СМЭВ 3» — готовое решение для взаимодействия информационных систем клиента с единой системой межведомственного электронного взаимодействия. Продукт помогает реализовать такие задачи, как установка системы и подготовка пакета документов для регистрации в СМЭВ, установка видов сведений и вызовов видов сведений. Также Шлюз поддерживает интеграцию с ведомственными информационными системами и предоставляет алгоритм для обучения сотрудников.

Архитектура продукта состоит из таких элементов:

  • Модули ядра, поддерживающие работу внутренних механизмов шлюза.
  • Адаптеры для преобразования информационной части сообщения из одного формата в другой или, так называемые, модули-трансформеры.
  • Сервер приложений для размещений модулей.
  • Внутренняя СУБД для хранения сообщений.

Продукт разработан российской компанией на открытом ПО, соответствует требованиям импортозамещения. Эксперты «КСК ТЕХНОЛОГИИ» готовы проконсультировать и помочь с интеграцией, а также обучением сотрудников. Помимо «КСК. Шлюз» компания предлагает и другие отраслевые решения, например, «КСК. СИУМВВ» для межведомственного взаимодействия, «КСК. Реестр услуг» и другие.