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

Статья написана в развитие темы, поднятой в предыдущей публикации – «Шишки, набитые при работе с адаптером СМЭВ». Рассматривается практический опыт реализации интеграционного решения на базе Адаптера СМЭВ. В роли адаптера используется бесплатное решение, представленное на технологическом портале СМЭВ 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. Приложение, как и вся библиотека, поставляется с исходными кодами. Теперь вместо одного файла подписываются все файлы, находящиеся в папке, имя которой передаётся в командной строке, а подписи помещаются в другую папку, передаваемую там же.

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

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

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

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

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

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

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

Результаты проекта

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

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

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

Благодарности

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

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

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

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