Как удалить расширение в периферийной базе РИБ, если оно осталось после удаления в центральном узле?

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

Почему расширение «застревает» в периферийном узле?

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

Способ 1: Ручная очистка через временное отключение главного узла

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

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

Пример кода для отключения и включения главного узла:

// Отключение главного узла
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

// После выполнения удаления расширения в интерфейсе - включение обратно
УзелЦентр = ПланыОбмена.Полный.НайтиПоКоду("ЦБ"); // Укажите ваш план обмена и код центра
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентр);

Способ 2: Программное удаление расширения без выхода из базы

Если ручное удаление через интерфейс по каким-то причинам неудобно (например, узлов очень много), мы можем воспользоваться программным методом удаления объекта метаданных РасширениеКонфигурации. Выясним, как это сделать правильно:

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

// Программное удаление расширения по имени
ИмяРасширения = "ИмяВашегоЗависшегоРасширения";
МассивРасширений = РасширенияКонфигурации.Получить();

Для Каждого ТекущееРасширение Из МассивРасширений Цикл
    Если ТекущееРасширение.Имя = ИмяРасширения Тогда
        Попытка
            ТекущееРасширение.Удалить();
            Сообщить("Расширение успешно удалено");
        Исключение
            Сообщить("Ошибка удаления: " + ОписаниеОшибки());
        КонецПопытки;
    КонецЕсли;
КонецЦикла;

Борьба с «Ошибкой формата представления изменений»

Часто после удаления расширения и восстановления связи с ЦБ при первом же обмене возникает ошибка: «Ошибка формата представления изменений». Это происходит из-за того, что в файле обмена (XML) передается заголовок v8de:Config с определенными значениями Digest1 и Digest2 (хэш-суммы конфигурации).

Рассмотрим, как синхронизировать эти значения:

• Обновление конфигурации в ЦБ: Внесите любое фиктивное изменение в центральной базе (например, измените комментарий в любом неважном объекте) и обновите конфигурацию базы данных (F7). Это заставит платформу пересчитать хэш и сформировать новый пакет изменений для периферийных узлов.
• Загрузка CF-файла: В некоторых случаях помогает выгрузка конфигурации из ЦБ в файл .cf и последующая загрузка в ПБ через «Конфигурация — Загрузить конфигурацию из файла» (при отключенном главном узле). Это полностью перезаписывает структуру метаданных и выравнивает хэш-суммы.

Правильный алгоритм удаления расширений (профилактика)

Чтобы не сталкиваться с проблемой «зависших» расширений в будущем, проанализируем правильный порядок действий при их выводе из эксплуатации в распределенной системе:

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

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

Резюме

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