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-сообщений в НРД. ИШ сам подписывает пакеты ЭДО, нам криптография в этом канале не нужна.</p>
  <p><strong>Профили</strong> (см. <a href="/admin/setup">Настройка → Интеграционный шлюз НРД</a>):</p>
  <table>
    <thead><tr><th>Профиль</th><th>Среда</th><th>Криптография</th></tr></thead>
    <tbody>
      <tr><td><code>guest-gost</code></td><td>Гостевой контур (без проверок)</td><td>ГОСТ Р 34.10-2012</td></tr>
      <tr><td><code>guest-rsa</code></td><td>Гостевой контур</td><td>RSA</td></tr>
      <tr><td><code>test3-gost</code></td><td>Тестовый контур TEST3</td><td>ГОСТ</td></tr>
      <tr><td><code>test3-rsa</code></td><td>TEST3</td><td>RSA</td></tr>
      <tr><td><code>prod-gost</code></td><td>Продуктивный</td><td>ГОСТ</td></tr>
      <tr><td><code>prod-rsa</code></td><td>Продуктивный</td><td>RSA</td></tr>
    </tbody>
  </table>
  <p><strong>Что указать в Настройка → ИШ:</strong></p>
  <ul>
    <li>Профиль (например, <code>test3-gost</code>)</li>
    <li>URL ИШ — обычно <code>http://localhost:8080</code> если ИШ установлен на той же ВМ</li>
    <li>Ключевой контейнер — имя на стороне ИШ, например <code>TEST3_GOST_CONTAINER</code></li>
  </ul>
  <p class="muted">Без настроенного ИШ система работает в <strong>mock-режиме</strong>: bj-server эмитирует синтетический Decision через 3 секунды для каждой заявки. Это удобно для дев-демо и не требует подключения к НРД.</p>
  <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}}