Мультибазовость в Расширенной редакции

·
  • multibase
  • расширенная
  • a3

Один процесс mcp-1c-advanced подключается к нескольким базам 1С одновременно. Конфигурация через --base, отдельные подключения, общий MCP-сервер.

В реальной работе разработчик редко сидит ровно над одной базой. Доработка тиражного решения часто требует прыгать между несколькими стендами: dev-копия, тестовая, эталонный дамп, регрессионный набор. Запускать отдельный процесс mcp-1c-advanced на каждую базу неудобно: разные порты, разные настройки клиентов AI-ассистента, путаница в идентификаторах.

В Расширенной редакции есть мультибазовый режим. Один процесс подключается ко всем нужным базам сразу и предоставляет MCP-инструмент list_bases для переключения контекста.

Конфигурация

Базы перечисляются через повторяющийся флаг --base:

mcp-1c-advanced \
    --base "dev=Srvr=localhost;Ref=acc-dev" \
    --base "test=Srvr=test-server;Ref=acc-test" \
    --base "ref=File=./baseline-dump"

Каждая запись это пара имя=строка_подключения. Имя выбирается произвольно, оно используется AI-ассистентом для адресации запросов. Строка подключения совпадает с тем, что обычно указывается в файлах настроек 1С: серверная база, файловая, или путь к выгруженному дампу.

Как это работает

При старте процесс открывает подключение к каждой базе и кэширует метаданные. Кэш делается лениво и индивидуально на базу, поэтому время старта не растёт линейно от количества баз. Bleve-индекс полнотекстового поиска тоже инициализируется на каждую базу отдельно.

В режиме MCP-сервера в каждом запросе клиент указывает base_id. Сервер маршрутизирует запрос к нужному подключению. Если AI забыл указать базу, в ответе приходит подсказка с доступными именами.

Список доступных баз

MCP-инструмент list_bases возвращает массив с именем, типом подключения (server/file/dump) и состоянием кэша:

{
  "bases": [
    {"name": "dev", "type": "server", "cached": true},
    {"name": "test", "type": "server", "cached": false},
    {"name": "ref", "type": "dump", "cached": true}
  ]
}

AI-ассистент через этот инструмент видит окружение и сам решает, в какой базе выполнять конкретный запрос. Например, для регрессионного теста он сначала спросит метаданные у ref, потом проверит то же место в dev.

Когда полезно

  • Разработка под несколько типовых одновременно: одна база БП, одна ЗУП, одна УТ.
  • Работа над миграцией: исходная конфигурация в одной базе, новая в другой, дамп в третьей.
  • Параллельный анализ нескольких клиентских внедрений: каждое внедрение как отдельная база, общий процесс mcp-1c-advanced для всех.

Ограничения

Подключения держатся постоянно. Если база недоступна, процесс не падает, но запросы к ней будут возвращать ошибку до восстановления связи. Кэш метаданных не инвалидируется автоматически при изменении конфигурации, для перечитывания используется refresh_cache.

Ко всем статьям