Bridge-and-Join-s/internal/lkgateway/web/templates/admin_help_systems.html

{{define "content"}}
<p style="margin-bottom:16px"><a href="/admin/help">← все инструкции</a></p>

<div class="card">
  <h2>Внешние системы</h2>
  <p class="muted">Как Bridge-and-Join-s взаимодействует с тремя главными внешними сторонами: НРД (через ИШ), команда Fansy (ETL в БД), уведомления операторам.</p>
</div>

<div class="card">
  <h2>1. Интеграционный шлюз НРД (ИШ) и контуры тестирования</h2>
  <p>Основной канал отправки M2M-сообщений в НРД — Web-сервис <strong>ONYX</strong> через ИШ. ИШ сам подписывает пакеты ЭДО, поэтому в этом канале нам криптография не требуется. Дистрибутив ИШ скачивается с сайта НРД: <code>www.nsd.ru/workflow/system/programs/#0-widget-faq-0-4</code></p>
  <p>Адреса контуров (из <code>DOC/Ссылки для доступа в тестовые контуры.pdf</code>):</p>
  <table>
    <thead><tr><th>Сервис</th><th>GUEST · ГОСТ</th><th>GUEST · RSA</th><th>TEST3 · ГОСТ</th><th>TEST3 · RSA</th></tr></thead>
    <tbody>
      <tr>
        <td><strong>WEB-сервис ONYX</strong> (нужен нам)</td>
        <td><code>gost-gt.nsd.ru</code></td>
        <td><code>rsa-gt.nsd.ru</code></td>
        <td><code>gost-t3.nsd.ru</code></td>
        <td><code>rsa-t3.nsd.ru</code></td>
      </tr>
      <tr>
        <td>Единый кабинет администратора НРДирект</td>
        <td colspan="2"><code>cabinet-gt.nsd.ru/wr-admin/</code></td>
        <td colspan="2"><code>cabinet-t3.nsd.ru/wr-admin/</code></td>
      </tr>
      <tr>
        <td>WEB-сервис Agate (WSAlameda)</td>
        <td colspan="2"><code>gost-gt.nsd.ru/WSAlamedags/</code> · <code>rsa-gt.nsd.ru/WSAlamedags/</code></td>
        <td colspan="2"><code>gost-t3.nsd.ru/WSAlameda/</code> · <code>rsa-t3.nsd.ru/WSAlameda/</code></td>
      </tr>
      <tr>
        <td>Депозитарно-клиринговых услуг (новый)</td>
        <td colspan="2" class="muted">отсутствует</td>
        <td><code>cabinet-t3.nsd.ru/dcs_new/</code></td>
        <td class="muted">—</td>
      </tr>
    </tbody>
  </table>
  <p class="muted">Полный URL WSL для ONYX: <code>https://&lt;host&gt;/onyx-ms/OnyxEdoWSService/OnyxEdo</code>. Для прод-контура ссылки опубликованы в Анкете НРД ЭДО (<code>anketa_nrd_edo_2022_07_11.pdf</code> на сайте НРД). IP <code>gost.nsd.ru</code> — 91.208.232.151 (для настройки межсетевого экрана).</p>
  <p><strong>Что указать в Настройка → ИШ:</strong></p>
  <ul>
    <li>Профиль (например, <code>test3-gost</code>) — при выборе URL и контейнер заполняются автоматически</li>
    <li>URL ONYX — например <code>https://gost-t3.nsd.ru/onyx-ms/OnyxEdoWSService/OnyxEdo</code></li>
    <li>Ключевой контейнер — имя контейнера КриптоПро с ключами ЭДО НРД (выдаются УЦ НРД, см. ниже)</li>
  </ul>
  <p class="muted">Без настроенного ИШ система работает в <strong>mock-режиме</strong>: bj-server эмитирует синтетический Decision через 3 секунды для каждой заявки. Это удобно для дев-демо и не требует подключения к НРД.</p>
</div>

<div class="card">
  <h2>1а. Сертификаты УЦ НРД (для проверки квитанций)</h2>
  <p>НРД подписывает все исходящие пакеты ЭДО ГОСТ-подписью своего УЦ. Для проверки этих подписей на нашей стороне нужно импортировать корневые сертификаты УЦ НРД в хранилище <code>mroot</code> (доверенные корневые).</p>
  <ol>
    <li>Скачать сертификаты с сайта УЦ НРД: <code>www.nsd.ru/workflow/system/cryptography/</code> (или из дистрибутива ИШ).</li>
    <li>В <a href="/admin/setup">/admin/setup</a> → раздел «Импорт сертификата» → выбрать файл <code>.cer</code>, тип хранилища <code>mroot — корневой УЦ</code>, нажать «Импортировать». Под капотом выполняется <code>certmgr -inst -file root.cer -store mroot</code>.</li>
    <li>Промежуточные сертификаты УЦ — в хранилище <code>uRoot</code>.</li>
    <li>Для проверки подписей самой системы НРД (квитанции ЭДО) — импортировать сертификат подписи НРД в <code>uMy</code> (как корреспондента), либо оставить в <code>mroot</code>, если он самоподписной.</li>
  </ol>
  <p><strong>Наши сертификаты для отправки в НРД</strong> (получаются из другого УЦ — нашей организации):</p>
  <ol>
    <li>Сертификат подписи нашей организации (с приватным ключом в виде <code>.pfx</code>/<code>.p12</code> или на Рутокен) — импортировать в <code>uMy</code> с PIN.</li>
    <li>Цепочка сертификатов вашего УЦ — в <code>mroot</code> (корневой) и <code>uRoot</code> (промежуточные).</li>
    <li>После импорта проверить: <code>certmgr -list -store uMy</code> и <code>cpverify</code>.</li>
  </ol>
  <p class="muted">Полный цикл обмена сертификатами с НРД описан в <code>DOC/Инструкция M2M.pdf</code> и <code>DOC/Презентация MOEX MOST.pdf</code>.</p>
</div>
  <p><strong>Документация по подключению</strong>: <code>DOC/instr_podkl_stend_v3.pdf</code>, <code>DOC/Ссылки для доступа в тестовые контуры.pdf</code>.</p>
</div>

<div class="card">
  <h2>2. Команда Fansy (ETL в БД)</h2>
  <p>Команда Fansy на своей стороне настраивает ETL, который пишет в схему <code>fansy_staging.*</code> нашей БД. Мы переливаем оттуда в <code>fansy.*</code> после валидации.</p>
  <p><strong>Что от вас как заказчика нужно:</strong></p>
  <ol>
    <li>Передать команде Fansy ссылку на каталог <code>docs/fansy-contract/v1/</code> (тег <code>fansy-contract-v1</code>).</li>
    <li>Согласовать SLA свежести и расписание (по умолчанию — портфели за 1 минуту, остальное за 5 минут, справочники раз в сутки).</li>
    <li>Завести в БД учётную запись с ролью <code>fansy_etl</code> и передать команде Fansy. Пароль выдать через защищённый канал.</li>
    <li>Прописать IP/подсеть Fansy в <code>pg_hba.conf</code> на стороне PostgreSQL (только TLS, <code>sslmode=verify-full</code>).</li>
  </ol>
  <p>Полный контракт: <code>docs/fansy-contract/v1/etl-requirements.md</code>. Семантика полей: <code>docs/fansy-contract/v1/data-dictionary.md</code>.</p>
</div>

<div class="card">
  <h2>3. Уведомления операторам</h2>
  <p>В M3-M4 будет раздел <strong>Настройка → Уведомления</strong>. Архитектура — провайдеры-плагины с единым интерфейсом <code>Notifier { Send(ctx, recipient, template, data) }</code>:</p>
  <table>
    <thead><tr><th>Провайдер</th><th>Назначение</th><th>Что вводить</th></tr></thead>
    <tbody>
      <tr><td>SMTP</td><td>E-mail (внутренний или внешний сервер)</td><td>хост, порт, логин/пароль, from-адрес</td></tr>
      <tr><td>Yandex Messenger (Yandex 360)</td><td>Корпоративный мессенджер. У заказчика уже есть готовый бот — дотягиваем его</td><td>API-token, webhook, chat-id / user-id</td></tr>
      <tr><td>Telegram</td><td>Опционально для отдельных операторов</td><td>bot-token, chat-id</td></tr>
      <tr><td>Mattermost / Rocket.Chat</td><td>Корпоративные мессенджеры (если используются)</td><td>webhook URL</td></tr>
      <tr><td>WebSocket в admin-ui</td><td>Мгновенный push если оператор открыл вкладку</td><td>встроено, без настроек</td></tr>
    </tbody>
  </table>
  <p><strong>Логика маршрутизации:</strong> критичный этап (ручное согласование, &gt;80% SLA, отказ НРД) → параллельно e-mail + Messenger + WS-push. Обычные события — только e-mail. Маршрутизация по ролям настраивается в UI.</p>
</div>

<div class="card">
  <h2>4. Контакты команд</h2>
  <table>
    <thead><tr><th>Внешняя сторона</th><th>Что согласовать</th></tr></thead>
    <tbody>
      <tr><td>НРД (Национальный расчётный депозитарий)</td><td>Тестовые сертификаты GUEST/TEST3, дистрибутив ИШ, доступ к личному кабинету УЦ НРД</td></tr>
      <tr><td>Команда ЛК (ESIA Finance)</td><td>Базовый URL ЛК, Basic-auth учётные данные, очерёдность подключения (сначала эмулятор, потом реальный ЛК)</td></tr>
      <tr><td>Команда Fansy</td><td>Контракт <code>docs/fansy-contract/v1/</code>, SLA, окна обслуживания, IP-allowlist</td></tr>
      <tr><td>КриптоПро</td><td>Серийный номер лицензии CSP, актуальный дистрибутив, поддержка <code>support@cryptopro.ru</code></td></tr>
      <tr><td>Брокеры-контрагенты MOST</td><td>БКС (ИНН 5406121446), Ренессанс (7709258228), Альфа-Банк (7728168971) — уже в seed</td></tr>
    </tbody>
  </table>
</div>
{{end}}