Назначение

СУД-Шлюз — это интеграционный сервис, который помогает вашей “инициирующей” информационной системе (ИИС) взаимодействовать с “целевыми информационными системами” (ЦИС) и порталами в автоматическом или автоматизированном режиме, когда прямое взаимодействие затруднено из-за особенностей обмена: сложные форматы, многошаговые сценарии, необходимость участия человека, нестабильное API и другие ограничения.

Участники взаимодействия

Инициирующая информационная система (ИИС) — система заказчика, которая формирует запросы/сообщения.
Сервис — принимает сообщения от ИИС, управляет очередью, преобразованием форматов, маршрутизацией и хранением.
Целевые информационные системы (ЦИС) — внешние порталы/сервисы, с которыми требуется взаимодействовать: порталы мировых судей, ГАС «Правосудие», портал арбитражного суда и другие (по сценарию заказчика).

Как работает СУД-Шлюз

1. ИИС формирует сообщение по формату, понятному шлюзу, и отправляет его в сервис.
2. Сервис принимает сообщение, проверяет права/учётную запись ИИС и сохраняет входные данные.
3. Если нужен обмен с внешним порталом, сервис:

• помещает запрос в очередь обработки;
• преобразует сообщение в формат, требуемый конкретной ЦИС;
• маршрутизирует запрос к ЦИС и получает ответ;
• при необходимости сохраняет сообщения в хранилище и выполняет очистку по настройкам;
• формирует ответ/статус для ИИС.

Что даёт заказчику

• Единая точка интеграции для разных порталов и сценариев.
• Очередь и устойчивость: обработка по мере готовности, управление повторами и статусами.
• Преобразование форматов и маршрутизация “под правила портала”.
• Контроль и диагностика: хранение и просмотр истории сообщений по настройкам.
• Автоматизация статусов: получение ответов/статусов по ранее отправленным сообщениям.

• какие целевые порталы (ЦИС) нужны в первом этапе (например, ГАС «Правосудие», порталы мировых судей, арбитраж и др.);
• какие типы отправок будут реализованы: заявления, пакеты документов, дополнительные вложения, запрос статусов, получение результата;
• какие статусы и ответы должны вернуться в вашу ИИС и как они должны выглядеть для операторов/системы;
• какие ограничения есть по безопасности, сетям, доступам и журналированию.

Внедрение СУД-Шлюза почти всегда упирается в организационные и инфраструктурные детали — мы закрываем их заранее:

• определяем, где разворачиваем шлюз (в вашем контуре, в выделенной зоне, в тестовом контуре для пилота);
• согласуем сетевые доступы к целевым порталам, правила выхода в интернет, прокси/межсетевые экраны (если применимо);
• создаём/подтверждаем учётные записи:

1. доступ в Форт.Бастион;
2. учётные данные целевых порталов, которые будут привязаны к клиентской учётной записи MSS;

• отдельно проговариваем требования порталов к “первичной” авторизации и подтверждениям.

• согласуем формат сообщения ИИС, включая обязательные поля, метаданные, вложения и идентификаторы;
• описываем правила сопоставления: как понять, что статус/ответ относится к конкретному заявлению;
• определяем, какие ответы считаются “успешными”, а какие — “ошибка/нужна обработка оператором”;
• при необходимости добавляем пред-проверки (валидации), чтобы снизить отказы на портале.

• настраиваем преобразование входного сообщения ИИС в формат, который требуется конкретному порталу;
• задаём маршрутизацию по порталам и сценариям (куда отправлять, какие шаги выполнять, что ждать в ответ);
• включаем обработку особенностей портала: многошаговые формы, “паузы”, подтверждения, нестандартные статусы.

• заявления не терялись и не уходили “вручную по одному”;
• повторная обработка не создавала дублей на портале;
• при временной недоступности портала запрос корректно повторялся по правилам;
• статусы были понятны: “в очереди / отправляется / отправлено / ожидает статус / завершено / ошибка”.

• включаем сохранение входных/исходящих сообщений и ответов (в пределах требований заказчика);
• настраиваем политику хранения и очистки (чтобы было достаточно данных для расследования, но без разрастания хранилища);
• договариваемся, как извлекаем цепочку по конкретному заявлению: от входа ИИС до ответа портала.

• настраиваем порядок актуализации авторизационных данных через Форт.Капонир (кто, когда и как обновляет);
• определяем регламент действий при “слете” авторизации и при изменениях на стороне портала;
• проверяем, что учётные данные действительно имеют права доступа на нужные операции.

• ИИС сформировала заявление → отправила в шлюз → шлюз поставил в очередь → преобразовал формат → отправил на портал → получил подтверждение/статус → вернул результат в ИИС.

• статусы по ранее отправленным заявлениям;
• обработку ошибок и повторов;
• ситуацию “портал временно недоступен”;
• предотвращение дублей.

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

• ответственный по процессу: какие заявления отправляем, какие статусы/результаты нужны в ИИС, правила повторов/исключений;
• ИТ-контакт: контуры, доступы, сети, правила выхода к порталам;
• перечень целевых порталов (ЦИС) и действующие учётные данные с необходимыми правами;
• примеры заявлений/пакетов и ожидаемых результатов;
• согласованный регламент актуализации авторизационных данных (в т.ч. через Форт.Капонир).

• перечень целевых порталов (ЦИС) и сценариев работы (ГАС «Правосудие», порталы мировых судей, арбитраж и др.; отправка заявлений/пакетов, получение статусов, получение результатов);
• сложность правил взаимодействия с порталами (многошаговые сценарии, особенности форматов, требования к вложениям, различия по регионам);
• настройка интеграции “ИИС ↔ СУД-Шлюз” (формат входных сообщений, метаданные, сопоставление статусов/ответов с исходными заявлениями, обработка ошибок);
• очередь обработки и правила повторов (таймауты, ретраи, предотвращение дублей, обработка недоступности порталов);
• авторизация на порталах и регламент актуализации учётных данных (наличие действующих аккаунтов, первичная авторизация, использование плагина для актуализации авторизационных данных);
• инфраструктура заказчика и ограничения сети (on-premise контур, правила выхода к порталам, прокси/VPN, сегментация, порядок удалённого доступа);
• требования к хранению и журналированию (что сохраняем по заявлению, сколько хранить, доступность цепочек для расследований);
• объём тестирования и пилота (количество сценариев, нагрузка, стабилизация на реальных потоках).

Стоимость внедрения СУД-Шлюза начинается от 200 000 (Двести тысяч) рублей. Итоговая стоимость определяется после обследования инфраструктуры, согласования перечня порталов и сценариев взаимодействия и фиксируется в договоре. Базовые почасовые ставки специалистов размещены в разделе «Цены».

• ваша ИИС умеет отправлять заявления/пакеты документов в судебные порталы через единый шлюз;
• работает очередь обработки и понятные статусы на каждом этапе;
• настроено преобразование форматов и маршрутизация “под правила портала”;
• настроено получение статусов/ответов и сопоставление с исходными заявлениями;
• определён порядок актуализации авторизации и действия при сбоях порталов;
• включены журналы/хранение для контроля и расследований;
• команда заказчика обучена и готова к промышленной эксплуатации.