Минкомсвязи продолжает закручивать гайки вокруг Системы межведомственного электронного взаимодействия. Ведомство формулирует требования к ИТ-системам участников СМЭВ – от форматов сообщений до журналирования операций. Это не рекомендации, а условия подключения: система, которая им не отвечает, к продуктивному контуру не пройдёт. Для ведомств, МФЦ и поставщиков услуг это означает конкретный фронт работ на ближайшие месяцы.

Что именно требует регулятор

Требования бьют по трём слоям. Первый – транспорт и форматы. Участник обязан обмениваться сообщениями через защищённую сеть передачи данных, упаковывать данные в SOAP-конверты и строго соблюдать структуру электронных сервисов, описанную в WSDL и XSD. Любое отклонение от схемы – отказ на стороне узла СМЭВ, а не «попробуем разобрать как-нибудь».

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

Третий слой – прослеживаемость. Регулятор требует вести журнал всех входящих и исходящих сообщений, хранить их в неизменном виде и предъявлять по запросу. Фактически каждая транзакция должна остаться в системе с отметкой времени, статусом и привязкой к подписи. Здесь логика смыкается с задачей электронного архива документов: межведомственный обмен сам по себе порождает архив, который надо хранить и уметь поднять при разборе спорной ситуации.

Где это бьёт по существующим системам

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

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

Вторая проблема – рассогласование справочников. ФИО, адреса, коды документов в разных системах кодируются по-разному, а СМЭВ требует общих классификаторов. Без нормализации данных запросы возвращаются с ошибками валидации, и услуга для гражданина «зависает» между ведомствами.

Что делать поставщику и заказчику

Реалистичный план – не переписывать ядро, а ставить адаптер. Между ведомственной ИС и узлом СМЭВ выстраивается интеграционный слой: он принимает SOAP-запросы, валидирует по схеме, накладывает и проверяет подпись, ведёт журнал и транслирует данные во внутренние форматы системы. Такой шлюз изолирует регуляторные требования от прикладной логики – при следующем изменении методических рекомендаций меняется адаптер, а не вся ИС.

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

Вывод

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