Работа с распределенными информационными базами (РИБ) в среде «1С:Предприятие 8.3» накладывает определенные обязательства на администратора системы. Одной из самых загадочных проблем является ситуация, когда обмен данными между узлами проходит успешно (документы и справочники мигрируют), но изменения программного кода — модулей, форм или макетов — упорно игнорируются периферийными узлами. Рассмотрим детально, почему это происходит и как гарантированно доставить изменения конфигурации до каждого узла.
Для начала проанализируем, как платформа понимает, что конфигурацию пора обновлять. В РИБ существует два типа изменений: изменения данных и изменения метаданных. За регистрацию последних отвечает скрытый внутренний механизм. Когда мы вносим правки в центральном узле, система должна поместить признак изменения конфигурации в таблицу регистрации для конкретного узла. Однако программный код (модули объектов, общие модули) и структура данных (новые реквизиты, таблицы) обрабатываются платформой по-разному.
Важный нюанс: изменение структуры метаданных (например, добавление реквизита) почти всегда инициирует жесткую перестройку таблиц базы данных и надежно регистрируется для обмена. В то же время изменение только текста модуля может быть проигнорировано механизмом регистрации из-за программных сбоев или накопленных ошибок в кэше конфигурации.
Если мы столкнулись с ситуацией, когда код модуля не уходит в узлы, самым простым «бытовым» способом является создание триггера для системы. Выясним, как заставить платформу увидеть изменения:
ТехническийФлагОбновления с типом Строка.При таком действии платформа видит изменение структуры (DBSchema) и принудительно ставит конфигурацию в очередь на выгрузку для всех подчиненных узлов. Как показывает практика, вместе с этим «фиктивным» изменением уходит и весь обновленный программный код, который до этого игнорировался.
Рассмотрим более профессиональный подход, который не требует изменения метаданных. Мы можем использовать встроенный язык 1С для принудительной регистрации изменений конфигурации по конкретному узлу. Для этого создадим внешнюю обработку и проанализируем следующий код:
// Выбираем узел, который перестал получать обновления
УзелСсылка = ПланыОбмена.ПоОрганизациям.НайтиПоКоду("003");
Если Не УзелСсылка.Пустая() Тогда
// Регистрируем изменения всей конфигурации для выбранного узла
ПланыОбмена.ЗарегистрироватьИзменения(УзелСсылка, Метаданные.Конфигурация);
Сообщить("Конфигурация успешно зарегистрирована для узла: " + УзелСсылка);
КонецЕсли;
Этот метод хорош тем, что он напрямую воздействует на таблицу регистрации изменений, минуя алгоритмы автоматического определения разницы (delta) версий. После выполнения этого кода следующее же сообщение обмена, сформированное в центре, будет содержать полный пакет обновлений конфигурации.
Выясним причину, по которой конфигурация может «зависнуть». В среде разработчиков 1С существует термин «демоническое обновление» — это динамическое обновление конфигурации без завершения работы пользователей. При частом использовании этого механизма в базе накапливаются несоответствия версий в таблицах Config и ConfigSave.
Если периферийный узел «считает», что он уже обладает актуальной версией (из-за неверного номера версии в заголовке сообщения), он просто пропустит блок <v8config> в XML-файле обмена. Чтобы вылечить это, проанализируем состояние кэша:
srvinfo) и локальный кэш пользователя, под которым запускается сеанс обмена./UpdateDBCfg -Force, чтобы принудительно пересобрать текущую конфигурацию БД.Если никакие программные методы не помогают, и узел продолжает принимать только данные, проигнорировав изменения кода, придется прибегнуть к ручному приведению конфигураций к идентичности. Посмотрим на алгоритм действий:
.cf).
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
.cf файл.
УзелЦентр = ПланыОбмена.ПоОрганизациям.НайтиПоКоду("001"); // Код центрального узла
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентр);
Внимание: После такой процедуры крайне важно убедиться, что номера принятых и отправленных сообщений в обоих узлах совпадают, иначе обмен может заблокироваться из-за нарушения нумерации.
Проанализируем ситуацию автора: использование платформы 8.3.11 на старой конфигурации «Бухгалтерия предприятия 2.0». Эта конфигурация построена на обычных формах, и механизмы синхронизации в ней могут конфликтовать с новыми оптимизациями фоновых заданий платформы 8.3.
В платформе 8.3.11 был изменен алгоритм работы с временными таблицами и фоновым обновлением конфигурации. Если во время синхронизации в периферийном узле кто-то из пользователей зашел в программу, захватив таблицу Config, регистрация изменений может просто «отвалиться» по таймауту, не выдав при этом явной ошибки в журнал регистрации. Поэтому рекомендуется проводить обмен в моменты отсутствия активных сеансов, либо использовать регламентные задания с монопольным доступом.
Подводя итог, можно сказать, что проблема «невидимых» обновлений кода в РИБ чаще всего связана с механизмом регистрации. Если вы столкнулись с подобным, начните с Метода 1 (изменение длины строки константы) — это решает 90% проблем. Если же база «тяжелая» и структура меняется слишком долго, используйте Метод 2 для точечной регистрации изменений через объект ПланыОбмена. Помните, что залогом здоровья РИБ является отказ от динамических обновлений в центральном узле.