Как исправить ошибку «Данные принимаются от узла с другим набором расширений» при обмене в РИБ?

← На главную

При работе с распределенными информационными базами (РИБ) разработчики часто сталкиваются со сложным поведением платформы 1С при синхронизации расширений конфигурации. Особенно остро эта проблема проявляется при создании начального образа подчиненного узла. Вы создаете абсолютно чистую периферийную базу из главного узла, запускаете первый обмен, но вместо успешной синхронизации система выдает ошибку: «Данные принимаются от узла с другим набором расширений, меняющих структуру данных. Необходимо произвести перенос расширений конфигурации в узел».

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

Почему возникает ошибка несовпадения расширений в абсолютно новой базе?

Для того чтобы понять природу этой ошибки, разберем внутреннюю логику работы платформы 1С с расширениями в распределенной базе. Когда мы создаем начальный образ подчиненного узла, система копирует основную конфигурацию и данные. Однако расширения конфигурации, особенно те, которые изменяют структуру данных (добавляют собственные справочники, документы, регистры или новые реквизиты в существующие объекты метаданных), ведут себя иначе.

При первом же сеансе обмена платформа выполняет жесткую проверку идентичности конфигураций и расширений в главном и подчиненном узлах. В XML-файле сообщения обмена передается информация о хэш-суммах установленных расширений. Эти данные располагаются в блоках заголовка сообщения v8de:Digest1 и v8de:Digest2, где в параметре Extensions зашифрован хэш структуры расширений главного узла.

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

Рассмотрим пошагово методы решения этой проблемы, начиная с самого простого и надежного практического алгоритма.

Решение 1. Пошаговый обходной путь с временным отключением активности расширений

Этот метод был найден опытным путем и отлично помогает обойти платформенные ошибки интеграции расширений при создании начального образа РИБ. Идея заключается в том, чтобы временно исключить влияние расширений, меняющих структуру данных, на момент создания и первичной инициализации подчиненного узла.

Выполним следующие шаги:

В центральной информационной базе (ЦБ) перейдем в меню Администрирование — Настройки — Расширения (или откроем список расширений через конфигуратор).
Для всех активных расширений, особенно тех, которые меняют структуру данных, временно снимаем флаг «Активно». При этом сами расширения удалять из базы не нужно — мы лишь временно деактивируем их исполнение.
Запускаем процедуру создания начального образа подчиненного узла РИБ. Поскольку все расширения в этот момент деактивированы, образ создается в «чистом» состоянии без расхождения хэш-сумм метаданных.
Переносим созданный файл начального образа на периферийный узел, разворачиваем базу и запускаем ее в режиме «Предприятие».
Настраиваем и выполняем первый сеанс обмена данными между базами. Так как расширения выключены и в центре, и на периферии, обмен должен пройти без каких-либо ошибок.
После успешного завершения первого обмена возвращаемся в центральную базу. Поочередно для каждого расширения устанавливаем флаги «Активно» и «Используется в РИБ».
При последующих сеансах обмена платформа начнет последовательно и корректно упаковывать метаданные расширений в пакеты обмена и передавать их в подчиненный узел, где они автоматически применятся.

Решение 2. Проверка и включение поддержки расширений в Плане обмена

Часто разработчики забывают, что возможность передачи расширений должна быть явно разрешена на уровне конфигурации для конкретного плана обмена. В типовых конфигурациях 1С (таких как УТ 11, ERP, КА, Розница) эта опция по умолчанию может быть отключена.

Проанализируем этот момент и включим необходимую настройку:

Откроем конфигурацию центральной базы в режиме «Конфигуратор». Если конфигурация находится на поддержке без возможности редактирования, необходимо включить возможность изменений через меню Конфигурация — Поддержка — Настройка поддержки (с сохранением поддержки).
Найдем используемый План обмена в дереве метаданных.
Откроем палитру свойств этого плана обмена и перейдем к свойству «Включать расширения конфигурации».
Убедимся, что напротив этого свойства установлен флаг «Истина». Если флаг снят, платформа просто не будет отправлять информацию о расширениях в подчиненные узлы, что гарантированно вызовет ошибку несовпадения структуры данных при первом же обмене.
Обновим конфигурацию базы данных.

Решение 3. Обновление справочника идентификаторов объектов метаданных

Если ваши расширения добавляют новые объекты (например, новые справочники, документы или регистры сведений), то для корректной работы механизмов БСП (Библиотеки стандартных подсистем) в центральной базе должны быть правильно заполнены технические справочники соответствия метаданных.

Для принудительного обновления идентификаторов объектов метаданных расширений в центральной базе перед созданием начального образа выполним следующий код (например, через внешнюю обработку или групповую обработку данных):


ЕстьОбновления = Ложь; 
ЕстьУдаленные = Ложь;
Справочники.ИдентификаторыОбъектовРасширений.ОбновитьДанныеСправочника(ЕстьОбновления, ЕстьУдаленные, Ложь);

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

Решение 4. Устранение ошибки «База данных заблокирована» на периферийном узле

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

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

Для успешного применения расширений выполним следующие правила:

Перед запуском обмена на подчиненном узле необходимо завершить сеансы всех пользователей в этой базе.
Следует временно отключить выполнение всех регламентных и фоновых заданий, так как запущенное в фоне задание мгновенно заблокирует базу и не позволит применить метаданные.
В Библиотеке стандартных подсистем используется константа ЗагрузитьРасширенияИзменяющиеСтруктуруДанных. При получении изменений система выставляет ее в значение Истина, сигнализируя о необходимости монопольного перезапуска сеанса для завершения обновления структуры.
В случае использования файлового варианта базы данных иногда помогает ручная очистка локального кэша конфигурации на рабочем компьютере пользователя, где запускается обмен, чтобы удалить устаревшие версии метаданных расширений.

Решение 5. Радикальный метод с временным отключением узла от РИБ (демеджик)

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

Рассмотрим этот алгоритм по шагам:

На периферийном узле открываем программу в режиме «Предприятие» и запускаем внешнюю обработку со следующим кодом для отключения связи с главным узлом: ПланыОбмена.УстановитьГлавныйУзел(Неопределено); После выполнения этого кода периферийная база становится полностью автономной, а в конфигураторе разблокируются все функции управления.
Запускаем Конфигуратор отключенной периферийной базы, заходим в список расширений и вручную удаляем проблемное расширение (или, наоборот, загружаем его актуальный файл .cfe, предварительно выгруженный из конфигуратора центральной базы).

Снова открываем базу в режиме «Предприятие» и запускаем код для обратного подключения к главному узлу:


СсылкаНаЦентр = ПланыОбмена.НайтиПоКоду("КодЦентральногоУзла"); // Укажите реальный код центрального узла
Если ЗначениеЗаполнено(СсылкаНаЦентр) Тогда
    ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
КонецЕсли;

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

Применяя предложенные методики, вы сможете быстро и безболезненно диагностировать и устранять любые коллизии, возникающие при совместном использовании механизмов РИБ и расширений конфигурации в 1С.