MCP для 1С: один сервер на десять баз без доработки конфигураций

Подключить нейросеть к одной базе 1С несложно: MCP это обычный HTTP-сервис, полдня работы. Вопрос начинается на второй базе, а на десятой становится главным. Десять отдельных подключений означают десять конфигураций клиента, десять мест правки при любом изменении и живого человека, который помнит, где что лежит.

Ниже разбор схемы, в которой десять продуктивных баз в трёх странах обслуживаются через одну точку входа, а в самих базах живёт пятнадцать строк кода без предметной логики. Здесь схема целиком: разбор безопасности, коды ответов по слоям и порядок внедрения.

Сразу оговорка, без которой дальше читать не нужно: в продуктивных базах схема исполняет присланный ей код и работает в закрытом контуре. Вне его так делать нельзя, и раздел про безопасность ниже написан именно об этом.

Почему доступа к базе недостаточно

Первое, что выясняется на практике: модели мало доступа.

Модель, у которой есть доступ, но нет знания конфигурации, строит запросы к объектам, которых нет, вызывает несуществующие в этой конфигурации процедуры и путается в реквизитах. Ровно та же болезнь, что при работе через чат без выгрузки структуры, мы её разбирали отдельно в статье про выгрузку метаданных для нейросети.

Обратный случай: конфигурацию модель знает, доступа нет. Рассуждает она тогда убедительно, но в деталях промахивается, потому что сходить и посмотреть ей нечем.

Отсюда два слоя, и по отдельности они бесполезны:

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

Слой первый: исходники всех баз в одном месте

Выгружаются расширения, конфигурации и внешние обработки. И вот на обработках ждёт сюрприз, который стоит проверить у себя.

В справочнике дополнительных отчётов и обработок десяти баз набралось 575 позиций, от 20 у самой скромной базы до 194 у самой обросшей. Без пометки на удаление 548, опубликованы и реально работают 501. Расширений всего 29, активных из них 27.

Отличия баз друг от друга живут как раз в обработках, и как раз о них никто не помнит: конфигурация о них ничего не знает, документация тем более. Работающих обработок 501, и это 501 повод двум одинаковым с виду базам вести себя по-разному.

Попробуйте оценить своё число навскидку, до того как заглянуть в базу. А потом откройте справочник и посчитайте живые. Расхождение обычно на порядок. Следующий вопрос после подсчёта - что внутри этих файлов: чек-лист ручного ревью чужой обработки и то, чем он проверяется, у нас в разборе про анализ кода внешних обработок.

Объём выгрузки: 34,5 гигабайта, в 435 168 папках лежат 474 208 файлов, каталог на страну. На базу выходит объектов метаданных от 3,5 тысячи до 7,3 тысячи, смотря розница это или ERP.

Собирают выгрузку скрипты из планировщика, ночью и в три потока, а итог шлют в Telegram. Утренний отчёт заодно и мониторинг: перестала база выгружаться, это видно сразу.

Хэш-проверка: без неё схема не живёт

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

В отчёте это видно честно: “без изменений” укладывается в десять минут, “обновлено” занимает почти час. Последний полный проход по контуру занял 82 минуты 57 секунд, и 55 минут из них ушли на одну-единственную базу, где конфигурация изменилась. Без хэш-проверки каждая ночь стоила бы часов пять и наезжала бы на регламентные операции.

Слой второй: база технологического реестра

Основа второго слоя - отдельная служебная база 1С. Она знает о контуре всё, продуктивные же базы о ней не подозревают. Клиент общается только с ней.

Внутри лежат:

• справочник баз контура: адреса и каталоги выгрузки;
• учётки для входа в эти базы;
• справочник методов доступа;
• код всех баз, загруженный в виде записей;
• одна-единственная точка входа, к ней и подключён MCP.

Главное: базы, методы и учётки хранятся как данные. Конфигурацию ради них не трогаем, отсюда и дешёвое сопровождение.

Справочник баз. У каждой базы записаны адрес сервера и имя, страна, тип системы и окружение, версия платформы и каталог выгрузки. Новая база - это новая строка. Лежи адреса в конфиге сервера, каждая новая база означала бы правку файла и согласование.

Справочник методов. Каждый метод - один разрешённый способ обратиться к базе, например выполнить код, забрать логи и посчитать их, принять пакет или отправить уведомление. У записи есть наименование и код, описание и обработчик, HTTP-метод, признак активности и флаг редиректа. Метод добавляется строкой и выключается флажком, без выкатки и конфигуратора.

Учётные данные. Учётка, с которой реестр заходит в продуктивные базы, хранится в его константах. Авторизация идёт двумя независимыми кругами: клиент входит в реестр, а реестр уже в базы. Паролей продуктивных баз клиент не видит никогда. Сменить пароль нужно только в одном месте.

Исходники записями. Выгрузка попадает в реестр в виде объектов метаданных, у каждого есть имя и тип, база и дата обновления, модули вместе с числом строк, а также реквизиты и табличные части. На обработку приходится одна карточка. С этими записями модель и работает, по ним она ищет, сравнивает и собирает ответ.

Пятнадцать строк в целевой базе

Кое-что в продуктивных базах всё же стоит: по пятнадцать строк на каждую из десяти.

Функция CodeExecute(Запрос)

    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(Запрос.ПолучитьТелоКакСтроку());
    Данные = ПрочитатьJSON(ЧтениеJSON, Ложь);

    РезультатВыполнения = "Код выполнен";

    Попытка
        Выполнить(Данные.ТекстКода);
    Исключение
        РезультатВыполнения = ОписаниеОшибки();
    КонецПопытки;

    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.УстановитьТелоИзСтроки(РезультатВыполнения, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать);

    Возврат Ответ;

КонецФункции

Ставится это шаблоном URL в HTTP-сервисе с методом POST, по пятнадцать минут на базу.

Обратите внимание на то, как возвращается результат. Переменная РезультатВыполнения объявлена раньше, чем вызывается Выполнить(), поэтому динамически выполняемый код её видит. Он записывает в переменную своё значение, и оно же уходит в ответ. Протокол сериализации не нужен, на выходе всегда строка, а разбор строки лежит на клиенте, где ему и положено быть.

На стороне реестра проксирование занимает одну функцию в 115 строк, на стороне базы пятнадцать, и это вся схема.

В этих пятнадцати строках нет ни капли предметной логики, поэтому и обновлять в них нечего. Любой новый тип запроса или проверки появляется в реестре и сразу работает во всех базах. Стоит первой предметной проверке переехать сюда, придётся вести версии, и главное преимущество схемы пропадёт. Следить нужно как раз за неизменностью: чтобы испортить пятнадцать строк, хватит одной шестнадцатой.

Безопасность: чем вы платите за такую схему

Раздел, ради которого стоит читать всё остальное. Вызов Выполнить() в продуктивной базе это исполнение произвольного кода на сервере 1С под правами учётной записи реестра. Не “риск”, а буквально то, что схема делает по назначению.

Что это значит по факту.

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

Что с этим делать, по убыванию эффекта.

1. Начинать с точки входа только на чтение, устроенной так, что изменить ничего физически не может. Большая часть задач диагностики закрывается здесь, и закрывается безопасно. Паттерн read-only доступа через транзакцию с безусловным откатом мы разбирали отдельно - “Безопасный доступ ИИ к боевой базе 1С”.
2. Изменяющий вход делать отдельной точкой со своими правами, белым списком операций и аудитом. И появляться он должен, только когда ясно, чего конкретно не хватает.
3. Ограничить права учётной записи реестра в целевых базах до необходимого минимума. Соблазн дать полные права велик, потому что так всё работает сразу, но именно это превращает удобный инструмент в единственную точку отказа. Разобрать, что кому доступно, помогает выгрузка матрицы прав.
4. Держать контур закрытым. Никакой публикации точки входа наружу и никаких серых зон вроде “временно открыли для теста”.
5. Логировать каждый вызов с телом запроса. Без этого разбор инцидента невозможен в принципе: вы не сможете ответить на вопрос, что именно выполнялось в базе в такой-то час.

Честный вывод: схема пригодна для закрытого контура, где вы отвечаете за все десять баз и за всех, у кого есть доступ. Для подрядчика на чужой инфраструктуре она не годится, там нужен режим только на чтение и ничего больше.

Коды ответов: развести слои с первого дня

Массовый вызов по десяти базам приносит пачку ответов, и если коды не разведены, разбираться в ней нечем.

Код	Что означает	Повтор поможет
502 от самого реестра	не достучались до базы	да
502 от веб-сервера по истёкшему ожиданию пула	база жива, вызов не дождался свободного соединения	сразу нет, встанет в хвост той же очереди
404	базы нет в реестре	нет
405	метод не разрешён	нет
200 с текстом ошибки в теле	упал присланный код	зависит от кода

На этих кодах строится автоматика повторов, и это единственный способ отличить “база лежит” от “я неправильно позвал”. Неправильный вызов лучше ловить ещё на входе ответом 400: как проверять параметры HTTP-сервиса 1С.

По самому коду эти два 502 не отличить, поэтому автоматике нужен признак, кто его отдал. Почему веб-сервер отвечает 502 при живом сервере 1С и как проверить пул публикации, разобрано на странице чек-апа веб-публикации. Если же MCP не подключается к базе вовсе, по каждому коду ответа от 401 до 500 есть отдельный справочник: что значит код и что проверить.

Второе, что стоит заложить сразу, это проверка связности. Отдельный вызов без всякого содержательного кода, который лишь опрашивает все базы: “ты жива?”. Не сделаете его, и первый же массовый запрос выдаст вперемешку результаты и отказы.

Три грабли, на которых теряется время

Регистр букв в имени публикации. При публикации имя базы меняет регистр и получает слэш в конце, и запросы отправляются на перенаправление. Ответы 301, 302 и 307 надо обрабатывать вручную, а иначе часть запросов молча пропадает, и со стороны это похоже на плохую сеть. Отладчик тут бессилен, потому что ошибка сидит на участке от клиента до веб-сервера. Флаг редиректа в справочнике методов появился как раз из-за неё.

Асинхронный режим не заработал. Идею с фоновым заданием в целевой базе и опросом его статуса пришлось бросить: задание отчитывалось об успехе, а на деле ничего не происходило. Ложный зелёный опаснее честного падения, всплывает он через неделю. Остался синхронный вызов с таймаутом на стороне клиента.

Тонкость, которую лучше записать: если связь оборвалась, операция на сервере всё равно доработает. Нет ответа - ещё не значит, что нет эффекта, поэтому операцию надо либо сделать безопасной при повторе, либо снабдить признаком выполнения.

Таймаут. Изначальных 120 секунд не хватило на пересчёт итогов регистров, пришлось поднять до 600. Побочное следствие: вызывающая сторона теперь может ждать ответа до десяти минут.

Что это даёт в работе

Пять минут на сравнение объекта между локализациями. Раньше вопрос о том, чем в рознице трёх стран различаются модули объекта чека ККМ, стоил двух конфигураторов и вечера переключения между окнами с риском что-то пропустить. Теперь модель обходит реестр, строит по шести розничным базам дифф и отдаёт разбор: где встречается ветка про подарочные сертификаты, где своя процедура печати, где определяется аналитика хозяйственной операции. Сомнительные места тут же проверяются в живых базах прямо из чата.

Обмен, проверенный с двух сторон. Выгрузили в одной базе, загрузили в другую и сверили результат снова в первой. Раньше такое делали вдвоём, и каждый верил другому на слово.

Один стандарт кода на десять баз. Если код всех баз лежит рядом и доступен запросу, вопрос “где ещё встречается такой же кусок” уже не требует исследования.

Неожиданно крупным вышел побочный эффект. По тому же каналу технические журналы стали уходить в архив, и на продуктивной базе освободилось 52 гигабайта. Про то, куда вообще уходит место в базе, у нас есть отдельный разбор - “Что растёт в базе 1С помимо документов”.

Кому это не подойдёт

С одной базой выигрыша не будет, с двумя-тремя он под вопросом: реестр и двойная аутентификация обходятся дороже прямого подключения. Окупается схема там, где обойти все базы руками за рабочий день уже не получается.

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

За базу реестра кто-то должен отвечать. С виду это утилита разработчика, но по факту она входит в продуктивный ландшафт, и обновления, резервные копии и мониторинг ей нужны так же, как остальным базам.

Порядок внедрения

Если решите повторять, порядок важнее скорости:

1. Выгрузка исходников и хэш-проверка. Полезна ещё до появления доступа к базам и сразу показывает, в каком состоянии контур на самом деле.
2. Справочник баз плюс проверка связности, пока без выполнения какого-либо кода. На этом шаге уже понятно, доступны ли все базы и верно ли разобраны публикации.
3. Точка входа, которая только читает. Большинство задач решается уже на ней.
4. Изменяющий вход в виде отдельной точки с собственными правами, аудитом и белым списком.
5. Проверить, что будет, если реестр недоступен, раньше, чем на него завяжутся процессы.

При таком порядке рабочий инструмент появляется уже после первого шага, а самая опасная часть откладывается напоследок. У нас вышло иначе: мы сразу взялись выполнять код в базах и ловили на живом контуре ложные зелёные статусы и перенаправления, не имея ещё ни выгрузки, ни проверки связности. Отлаживать в таких условиях просто нечем, нельзя понять даже, база промолчала или запрос попал не по адресу.

Коротко

Одного доступа к базам не хватит, одного знания кода тоже, результат даёт только их связка. Первым делом выгрузите исходники, так вы впервые увидите контур целиком. Базы и методы храните записями в справочниках, и конфигурацию трогать не придётся совсем. И считайте безопасность частью схемы, а не примечанием к ней: Выполнить() в проде это ровно то, чем он выглядит.

Готовые обработки по теме:

• Выгрузка структуры метаданных 1С для нейросети - если полноценный контур пока избыточен, а объяснить модели устройство базы надо уже сейчас.
• Матрица прав доступа 1С для нейросети - разобрать, под какими правами ходит учётная запись и что ей доступно.
• Анонимизатор выгрузки 1С PRO - когда данные уходят во внешнюю модель, а не в закрытый контур.

Если нужен такой контур, но нет людей на его сборку, это часть нашей работы по обслуживанию баз 1С: разворачиваем реестр, выгрузку и мониторинг, оставляем документацию и не привязываем вас к себе.