Интеграция со СМЭВ, как это было
Хабр, привет! Меня зовут Волков Дмитрий, и я являюсь руководителем отдела развития интеграционных шлюзов Страхового Дома ВСК. В августе 2023 стала доступна возможность подать сведения о ДТП через портал гос. услуг. Страховая компания должна в течение 5 минут принять ваше заявление, уведомить вас об этом и запустить процесс рассмотрения и урегулирования вашего заявления.
Для Страхового Дома ВСК прямое взаимодействие со СМЭВ 3 стало новым вызовом, которого мы не испугались и пройдя весь путь интеграции и наладки своих процессов стали первой страховой компанией, чей убыток был урегулирован через гос. услуги. В данной статье я хочу рассказать о нашем удачном опыте, как мы реализовали своё взаимодействие со СМЭВ 3 и подробно остановимся на следующих моментах:
Что же это такое — СМЭВ;
Внедрение Адаптера в архитектуру ВСК;
Плюшки от интеграции со СМЭВ 3.
Что же такое СМЭВ и с чем его едят?
Подробно о СМЭВ можно почитать здесь, а если коротко, то СМЭВ — это государственная информационная система, маршрутизирующая запросы между потребителем услуги и поставщиком и следящая за безопасностью этого взаимодействия. Потребителем в данном случае выступают разного рода организации, как государственные, так и частные, поставщиком услуг — орган государственной власти (МВД, ЗАГС и т.п.).
Организация взаимодействия в СМЭВ
Чтобы стать участником СМЭВ необходимо:
Пройти путь официальной регистрации;
Организовать защищённый канал связи (был настроен ранее в рамках аутентификации клиентов через ЕСИА);
Настроить/реализовать интеграционный модуль для подключения к СМЭВ (Адаптер);
Получить доступ к нужным данным.
Внедрение Адаптера в архитектуру ВСК
В силу сжатых сроков реализации мы решили воспользоваться готовым интеграционным модулем от гос. услуг — Адаптер, который хранит в себе все секреты взаимодействия со СМЭВ:
формирование конечных XML запросов к СМЭВ;
подписание запросов;
пересылка вложений;
возврат статусных сообщений.
Изучив документацию по Адаптеру, мы развернули его внутри своей сети в виде отдельного сервиса, взаимодействие с которым у нас осуществляется через протокол REST. Следующим шагом нужно было научить приложения ВСК работать с этим Адаптером. Чтобы унифицировать этот процесс, мы разбили взаимодействия со СМЭВ на 3 слоя:
Сервисы-адаптеры — нужны для маппинга входящих/исходящих данных;
Платформенные сервисы — содержат в себе внутреннюю логику ВСК для работы с интеграционным модулем и инфраструктурными приложениями.
Адаптер СМЭВ — общается с самим СМЭВ.
Получилась следующая архитектура:
Архитектура приложения «Шлюз гос.органов»
Наше решение реализовано на следующем стэке:
.NET;
PostgreSQL;
Kafka;
Minio.
На реализацию платформенных сервисов и сервиса-адаптера для ДУУ ОСГАО ушло примерно 2,5–3 месяца чистого времени для Agile-команды из 6 человек.
Под реализацией понимается:
подготовка требований;
разработка платформенных сервисов и сервиса-адаптера;
интеграция с внутренней системой учёта убытков;
интеграция с внутренней системой маршрутизации файлов;
тестирование;
ввод в эксплуатацию.
Теперь рассмотрим детальнее каждый из слоев приложения:
Сервисы-адаптеры
Каждый сервис является независимым и несёт в себе логику преобразования формата данных ВСК в формат данных для Адаптера и наоборот, преобразует ответ Адаптера в удобный вид для приложений ВСК.
Структура запроса для Адаптера унифицирована, но она содержит в себе блок с бизнес-данными конкретного Вида Сведений (далее — ВС). В терминах СМЭВ вид сведений — это описание формата запроса и ответа для конкретного взаимодействия. Т.е. если мы синтегрировались со СМЭВ по какому-то конкретному ВС, это ещё не значит, что для всех последующих ВС мы просто получаем доступ и наслаждаемся реализованным процессом обмена. Каждый ВС требует своей обработки и наши сервисы-адаптеры с этим успешно справляются.
Взаимодействие с данными сервисам реализуется как с использованием API, будь то REST или gRPC, так и с использованием событийной шины — Kafka, в зависимости от процесса и потребностей. Сейчас для каждого нового сервиса-адаптера в среднем требуется примерно 1 спринт на реализацию.
Платформенные сервисы
В данных сервисах реализована логика:
доставки вложений до Адаптера (да-да, файлы должны быть физически расположены рядом с модулем, иначе он их не увидит);
подготовки финального запроса к Адаптеру;
опроса Адаптера о наличии новых сообщений от СМЭВ;
маршрутизации ответов СМЭВ к сервисам-адаптерам в зависимости от ВС.
Взаимодействие между платформенными сервисами и сервисами-адаптерами осуществляется через Kafka.
Я, конечно, рассказал бы об этом подробнее, но последующее раскрытие информации несет в себе коммерческую тайну :)
Адаптер СМЭВ
Как было упомянуто ранее, в нём скрыты все процессы подготовки XML запроса к СМЭВ, подписание запросов, валидация подписи входящих запросов, отправка статусных сообщений. Адаптер имеет свой веб-интерфейс, через который осуществляется часть настройки Адаптера и который позволяет просматривать историю запросов.
Плюшки от интеграции со СМЭВ 3
Как итог, помимо соблюдения регуляторных требований и сохранения своей лицензии, мы открыли для себя новый источник информации, который помогает нам снизить риски мошенничества за счет верификации данных в СМЭВ.
На текущий момент в ВСК осуществляется:
приём заявлений для дистанционного урегулирования убытка ОСАГО;
проверка действительности паспортов клиентов;
проверка сведений о факте смерти клиента;
электронное подписание документов с клиентами через приложение «Гос.ключ»;
получение разрешённых данных клиента ФЛ из цифрового профиля;
получение разрешённых данных клиента ЮЛ из цифрового профиля;
приём заявления на создание полиса ДМС Мигрант.
А также, интеграция со СМЭВ открывает возможность автоматизации части процессов по взаимодействию с государственными органами. Например, регистрация дел исполнительного производства и получение их статусов в Федеральной системе судебных приставов (ФССП).
Сейчас на пороге стоит интеграция со СМЭВ 4, продолжение следует…
