zuevav/Bridge-and-Join-s
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5fa6ea6ab1af7d84a569c1c15d87d035b8c8f394
Bridge-and-Join-s/REPORT.md
T
fontvielle 5fa6ea6ab1 feat(robot): эмулятор робота-автотеста НРД + help-страница + REPORT.md 
Реализован внутренний робот-эмулятор в internal/nsdadapter/mock/robot.go.
Источник правил: DOC/instruktsiya-po-testirovaniyu-s-robotom.pdf (от
12.05.2026). Когда mock.Sender видит Header.ReceiverCode == MC0012500000
и DocumentSeries в {1111, 2001, 2002, 3333} — формирует Decision по
выбранному сценарию вместо default-логики.

Сценарии:
- 1111 «Ответ с отказом»: все бумаги Rejection, код ошибки берётся из
  последних 2 символов DocumentNumber (01..09 → M2M01..M2M09)
- 2001 «Принять все бумаги»: все Confirmation; i-й символ DocumentNumber
  = номер депозитария-получателя для i-й секции (1/2)
- 2002 «Принять частично»: 0 = отклонить с M2M05, иначе номер депозитария
- 3333 «Выступить принимающей стороной»: пока только первое сообщение
  (отказ M2M05). Встречный M2MTransferRequest от робота — TODO
  (требует приёмной стороны bj-server)

Тестовые наборы депозитариев (ИНН 7702165310, depcode MC0012500000,
счёт HL2603250011, разделы 31MC0012500000F00 и 36MC0012500000F00)
зашиты в robotDepositary — соответствуют таблице из инструкции.

Help-страница /admin/help/robot с полным описанием: коды робота,
сценарии, управление через DocumentNumber, тестовые данные, коды ошибок
M2M01-M2M09, как переключиться на реальный TEST3 после получения ИШ.

REPORT.md — сводный отчёт для руководства о ходе работ: ~65% общей
готовности системы, ~80% готовности к интеграционному тесту с роботом
(остальное — внешние блокеры: дистрибутив ИШ, сертификат УЦ МБ).
Расписан план первичного тестирования после получения ИШ — 2-3 недели
до продакшена.

.gitignore: исключены DOC/*.pdf.bak (бэкапы doc-watcher'a).
2026-05-14 16:53:52 +03:00

18 KiB
Raw Blame History

Bridge-and-Join-s — отчёт о ходе работ

Дата: 14.05.2026 Контур: дев-стенд РЕД ОС 8 (10.10.10.22), bj-server на :8080, lk-emulator на :8083 Целевая интеграция: сервис MOEX МОСТ (M2M) через НКО АО НРД

Готовность по областям

Область Готовность Статус
Контракты и модели M2M (XSD → Go) 100% ✅ Готово
Журнал сделок (PostgreSQL + in-memory) 100% ✅ Готово
Бизнес-логика FSM (стейт-машина заявок) 100% ✅ Готово
Веб-интерфейс администратора 95% ✅ Готово
Мастер настройки (wizard) для оператора 100% ✅ Готово
Установка и конфигурация КриптоПро CSP через UI 100% ✅ Готово
Авто-загрузка сертификатов УЦ (мониторинг + ежесуточное обновление) 100% ✅ Готово
Контейнеры КриптоПро с флешки (импорт в HDIMAGE) 80% ⚠ Без UI-импорта сертификата из контейнера
Лента новостей + мониторинг сайта НРД (doc-watcher) 100% ✅ Готово
Эмулятор робота-автотеста НРД (внутренний mock) 90% ⚠ Сценарий 3333 — частично
Реальное подключение к роботу на TEST3 НРД 0% ⏳ Заблокировано на ИШ и сертификате
Интеграционный шлюз НРД (ИШ) 0% ⏳ Не скачан, не установлен
Сертификат УЦ Московской Биржи для подписи 0% ⏳ Не получен
Подключение реального ЛК ESIA Finance 20% ⚠ Эмулятор lk-emulator работает, реальный URL не указан
Контракт с Fansy (ETL) 30% ⚠ Контракт документирован, ETL не реализован стороной Fansy
Уведомления (e-mail, мессенджеры) 0% ⏳ M3-M4
Тесты, CI/CD 40% ⚠ Unit-тесты компонентов, нет E2E против реального НРД

Общая готовность системы: ≈ 65% (по объёму функциональности) Готовность к интеграционному тесту с роботом: ≈ 80% (зависит только от внешних факторов — ИШ, сертификат)

Что сделано (28 коммитов)

Архитектура и ядро (M1)

  • Реализованы Go-модели всех M2M-сообщений (M2MTransferRequest, Response, Decision, History, Movement) с валидацией.
  • Стейт-машина обработки заявок (FSM): draft → validated → submitted_to_nsd → awaiting_decision → confirmed/rejected/timed_out → done + ветка ручного разбора.
  • Один исполняемый бинарник bj-server (вместо запланированных микросервисов) — рассчитано на нагрузку до 1000 сделок/день.
  • Хранилище: PostgreSQL 16 в контейнере podman (один клик «Поднять автоматически» в UI), миграции для двух схем — fansy.* (данные от Fansy) и m2m_core.* (журнал сделок). Fallback на in-memory для дева.

Криптография

  • Переход с КриптоПро JCP (~82 000₽, Java) на КриптоПро CSP (~30-50 000₽, нативный) — экономия лицензии в ~2 раза. Подходит для нашего объёма (100-1000 сделок/день).
  • Go-клиент к СКЗИ через стандартный PKCS#11 интерфейс (internal/cryptocli). Один клиент работает с КриптоПро CSP, Рутокен ЭЦП 2.0, Валидата, ViPNet — меняется только путь к .so модулю.
  • UI-кнопка «Загрузить дистрибутив КриптоПро»: загружаешь tar/tgz/rpm, система сама распаковывает и устанавливает через sudo rpm -Uvh.
  • Активация лицензии через UI (cpconfig -license -set под капотом).
  • Импорт сертификатов (.pfx/.p12 с PIN, .cer/.crt без) в хранилища uMy/mroot/uRoot через certmgr -inst.
  • Авто-обнаружение контейнеров КриптоПро на USB-флешках (формат name.000): сканирует /run/media/$USER/, /media/, /mnt/; кнопка «Скопировать в локальное хранилище» переносит контейнер в /var/opt/cprocsp/keys/$USER/.
  • Авто-обнаружение сертификатов на Рутокене ЭЦП 2.0 — список заполняется автоматически после подключения токена в USB.

Сертификаты УЦ

  • Авто-загрузка корневых и подписных сертификатов УЦ по списку URL: SHA-256 дедуп, импорт в mroot/uRoot через certmgr.
  • Ежесуточная фоновая горутина обновляет сертификаты, в ленте новостей появляется уведомление «Обновлён сертификат УЦ: ».
  • За 14 дней до истечения сертификата — отдельное предупреждение в ленте.

Веб-интерфейс администратора (порт 8080)

6 разделов меню:

  • Дашборд — счётчики сделок, состояние подсистем, последние заявки, блок «Новости» сверху.
  • Мастер настройки — пошаговая настройка (5 шагов) с прогресс-баром, подсказки «?» и «Где взять?» рядом с каждым полем.
  • Настройка — расширенные параметры всех подсистем.
  • Заявки — журнал + карточка заявки с историей FSM.
  • Статус системы — health-check всех подсистем.
  • Инструкции — 5 help-страниц: БД, API ЛК, КриптоПро, Внешние системы, Тестирование с роботом.
  • Новости — лента событий + кнопка «Проверить обновления документации НРД сейчас».

Все надписи на русском.

Мониторинг НРД (doc-watcher)

  • Раз в сутки скачивает страницы с сайта НРД, парсит ссылки на PDF, обновляет файлы в DOC/ (старые версии переименовываются в .YYYY-MM-DD.pdf.bak для аудита).
  • Каждое обновление публикуется как новость в ленту.
  • Уже скачаны три свежие инструкции от 12.05.2026:
    • instruktsiya-po-testirovaniyu-s-robotom.pdf — инструкция по роботу-автотесту
    • instruktsiya-...-fizicheskim-litsom-samomu-sebe.pdf — обмен при self-transfer
    • servis-most-m2m.pdf — обзор сервиса

Робот-автотест MOEX МОСТ

  • Реализован внутренний робот-эмулятор: bj-server понимает код робота MC0012500000 и 4 тестовых сценария (1111/2001/2002/3333) через DocumentSeries.
  • Это позволяет проверить нашу логику обработки ответов до того, как у нас появится реальный ИШ + сертификат + доступ к TEST3.
  • Help-страница /admin/help/robot с полной документацией (коды ошибок M2M01-M2M09, тестовые наборы депозитариев, схема обмена).
  • Когда подключим реальный ИШ — переключение прозрачное, те же заявки пойдут на реальный TEST3.

Безопасность и надёжность

  • Баннер «🟡 РЕЖИМ ЭМУЛЯЦИИ» отображается на каждой странице админки пока не настроен ИШ или СКЗИ — оператор не сможет случайно принять mock-результат за реальный.
  • Контекстная навигация после действий (после POST возврат на ту же страницу, не в /admin/setup).
  • HTTP-клиенты для запросов на nsd.ru/cryptopro.ru идут напрямую (игнорируют корпоративный прокси), браузерный User-Agent для обхода антибот-фильтров.
  • systemd-unit deploy/systemd/bj-server.service с Environment=LD_LIBRARY_PATH=/opt/cprocsp/lib/amd64, ProtectSystem=strict, NoNewPrivileges, и т.п.

Что в процессе и в очереди

Внешние блокеры (без них не двинемся к реальному НРД)

  1. Дистрибутив ИШ НРД

    • Где взять: https://www.nsd.ru/workflow/system/programs/#0-widget-faq-0-4
    • Что неизвестно: системные требования (ОС, СКЗИ — JCP или CSP, БД, Java), нужен ли отдельный договор/лицензия. В наших документах эти детали отсутствуют — они в «Руководстве по установке ИШ», которого у нас нет.
    • Что нужно сделать: запросить «Руководство по установке и настройке ПО Интеграционный шлюз НРД» у НРД (контакт: M2MOST@nsd.ru).
    • Срок: зависит от ответа НРД.

  2. Сертификат подписи УЦ Московской Биржи (ca.moex.com)

    • Нужен для подписи отправляемых сообщений (через ИШ — кладётся в ИШ; без ИШ — в bj-server).
    • Что нужно: оформить заявку в УЦ МБ от организации, получить сертификат + приватный ключ (на токене или в контейнере).
    • Срок: зависит от УЦ.

  3. Сертификаты УЦ НРД (для проверки квитанций)

    • Где взять: https://www.nsd.ru/workflow/system/cryptography/ — сейчас отдаёт 404 на нашем дев-стенде (вероятно перенесено в ЛК НРД депонента).
    • В коде уже есть форма «Авто-загрузка сертификатов УЦ» в /admin/setup — как только получим прямые URL .cer, добавим их.

  4. Окно техработ TEST3: 18.05.2026 — 22.05.2026

    • Полевое тестирование в этот период невозможно. Реальные прогоны — до 18-го или после 22-го мая.

  5. Доступ к API реального ЛК ESIA Finance

    • Сейчас bj-server работает с встроенным эмулятором lk-emulator на :8083.
    • Что нужно: URL продакшен/тест ЛК, Basic-auth учётка.

Внутренние задачи (можем делать параллельно)

Задача Приоритет Эффект
Завершить сценарий 3333 робота — приёмная сторона bj-server (входящие M2MTransferRequest) средний Полное покрытие тестов с роботом
UI для импорта сертификата из контейнера КриптоПро (после копирования с флешки) низкий Сейчас делается вручную через certmgr
Уведомления: SMTP, Yandex Messenger, Telegram (плагины через единый интерфейс Notifier) средний (M3) Операторам — критичные события в мессенджеры
Расширение тестов: unit + интеграционные с mock-роботом, нагрузочные низкий Уверенность перед прод
Документация для команды Fansy (ETL): передача контракта, согласование SLA, прописывание IP в pg_hba.conf средний Запуск ETL-потока

Что после получения ИШ и сертификата (план первичного тестирования с роботом)

  1. День 0 (получили дистрибутив ИШ + сертификат + руководство)
    • Поставить ИШ на dev-ВМ.
    • Положить сертификат в ИШ-хранилище.
    • В bj-server: /admin/setup → ИШ профиль test3-gost, URL ИШ.
  2. День 1 (smoke-тест)
    • Отправить через bj-server заявку с ReceiverCode = MC0012500000, DocumentSeries = 2001, DocumentNumber = 111111 → ожидаем «принять все бумаги» от робота.
    • Проверить: квитанция от НРД, Decision от робота, callback в lk-emulator, статус в журнале → confirmed.
  3. День 2-3 (полное покрытие сценариев)
    • 1111 (отказ M2M01..M2M09) — все коды ошибок.
    • 2001 / 2002 — все депозитарии, все варианты частичного приёма.
    • 3333 — встречный перевод (когда доделаем приёмную сторону).
  4. День 4-5 (нагрузка)
    • 50-100 одновременных заявок, проверка очередей, БД, корректность статусов.
  5. День 6 (живой контрагент)
    • Согласовать с любым подключённым к НРД депозитарием тестовый обмен.
    • Это последний шаг перед присоединением к Правилам ЭДО НРД (продакшен).

Реалистичный срок от получения ИШ до готовности к продакшену: 2-3 недели (включая обкатку, fix багов, документацию).

Стоимостная сводка

Статья Сумма (руб) Статус
Лицензия КриптоПро CSP (сервер) ~30 000-50 000 Демо 3 мес. — активна
Лицензия КриптоПро CSP (рабочее место оператора, опц.) ~2 000-3 000 Не куплена
Рутокен ЭЦП 2.0 для оператора (железо, опц.) ~3 000-5 000 Не куплено
Сертификат УЦ МБ для организации по тарифам УЦ Не получен
Сэкономлено против КриптоПро JCP ~30 000-50 000 (отказ от Java-стека)

Ключевые архитектурные решения

  1. Один бинарник вместо микросервисов — рассчитано на наш объём (100-1000 сделок/день). Упрощает деплой, отладку, мониторинг. Все компоненты в одном процессе с понятными границами пакетов (internal/m2mcore, internal/nsdadapter, internal/lkgateway, ...).
  2. PKCS#11 как единый интерфейс к СКЗИ — позволяет менять провайдер (CSP/Рутокен/Валидата) без изменения кода bj-server.
  3. Двух-уровневая БД (fansy.* для входных данных, m2m_core.* для журнала сделок) — позволяет команде Fansy писать в свою схему без знания о нашем pipeline.
  4. Mock-робот внутри bj-server — даёт возможность работать без живого НРД для значительной части интеграционного тестирования.
  5. «Дружественный» UI — установка/настройка не требует SSH-доступа: всё через веб (КриптоПро, лицензии, сертификаты, контейнеры с флешки).

Готов к интеграционному тестированию с роботом на TEST3: да, как только будет ИШ + сертификат. Готов к продакшену: ориентировочно через 3-4 недели после получения всех внешних компонентов.

— Команда разработки Bridge-and-Join-s

Reference in New Issue View Git Blame Copy Permalink