Интеграция со СМЭВ, как это было

Хабр, привет! Меня зовут Волков Дмитрий, и я являюсь руководителем отдела развития интеграционных шлюзов Страхового Дома ВСК. В августе 2023 стала доступна возможность подать сведения о ДТП через портал гос. услуг. Страховая компания должна в течение 5 минут принять ваше заявление, уведомить вас об этом и запустить процесс рассмотрения и урегулирования вашего заявления.

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

1. Что же это такое – СМЭВ;

2. Внедрение Адаптера в архитектуру ВСК;

3. Плюшки от интеграции со СМЭВ 3.

Что же такое СМЭВ и с чем его едят?

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

Чтобы стать участником СМЭВ необходимо:

1. Пройти путь официальной регистрации;

2. Организовать защищённый канал связи (был настроен ранее в рамках аутентификации клиентов через ЕСИА);

3. Настроить/реализовать интеграционный модуль для подключения к СМЭВ (Адаптер);

4. Получить доступ к нужным данным.

Внедрение Адаптера в архитектуру ВСК

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

• формирование конечных XML запросов к СМЭВ;

• подписание запросов;

• пересылка вложений;

• возврат статусных сообщений.

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

1. Сервисы-адаптеры — нужны для маппинга входящих/исходящих данных;

2. Платформенные сервисы — содержат в себе внутреннюю логику ВСК для работы с интеграционным модулем и инфраструктурными приложениями.

3. Адаптер СМЭВ — общается с самим СМЭВ.

Получилась следующая архитектура:

Наше решение реализовано на следующем стэке:

• .NET;

• PostgreSQL;

• Kafka;

• Minio.

На реализацию платформенных сервисов и сервиса-адаптера для ДУУ ОСГАО ушло примерно 2,5-3 месяца чистого времени для Agile-команды из 6 человек.

 Под реализацией понимается:

• подготовка требований;

• разработка платформенных сервисов и сервиса-адаптера;

• интеграция с внутренней системой учёта убытков;

• интеграция с внутренней системой маршрутизации файлов;

• тестирование;

• ввод в эксплуатацию.

Теперь рассмотрим детальнее каждый из слоев приложения:

Сервисы-адаптеры

Каждый сервис является независимым и несёт в себе логику преобразования формата данных ВСК в формат данных для Адаптера и наоборот, преобразует ответ Адаптера в удобный вид для приложений ВСК.

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

Взаимодействие с данными сервисам реализуется как с использованием API, будь то REST или gRPC, так и с использованием событийной шины — Kafka, в зависимости от процесса и потребностей. Сейчас для каждого нового сервиса-адаптера в среднем требуется примерно 1 спринт на реализацию.

Платформенные сервисы

В данных сервисах реализована логика:

• доставки вложений до Адаптера (да-да, файлы должны быть физически расположены рядом с модулем, иначе он их не увидит);

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

• опроса Адаптера о наличии новых сообщений от СМЭВ;

• маршрутизации ответов СМЭВ к сервисам-адаптерам в зависимости от ВС.

Взаимодействие между платформенными сервисами и сервисами-адаптерами осуществляется через Kafka.

Я, конечно, рассказал бы об этом подробнее, но последующее раскрытие информации несет в себе коммерческую тайну 🙂

Адаптер СМЭВ

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

Плюшки от интеграции со СМЭВ 3

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

На текущий момент в ВСК осуществляется:

• приём заявлений для дистанционного урегулирования убытка ОСАГО;

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

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

• электронное подписание документов с клиентами через приложение «Гос.ключ»;

• получение разрешённых данных клиента ФЛ из цифрового профиля;

• получение разрешённых данных клиента ЮЛ из цифрового профиля;

• приём заявления на создание полиса ДМС Мигрант.

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

Сейчас на пороге стоит интеграция со СМЭВ 4, продолжение следует…