При сопровождении распределенных информационных баз (РИБ) на платформе 1С:Предприятие 8.3 специалисты часто сталкиваются с ситуацией «замкнутого круга» во время масштабных обновлений. Типичный сценарий: вы обновляете конфигурацию (например, 1С:Розница) в центральном узле, что требует повышения версии платформы и изменения режима совместимости как основной конфигурации, так и расширений. В этот момент штатный обмен с периферийными узлами может «сломаться». Мы разберем, почему это происходит и как правильно провести обновление, не прибегая к пересозданию образов подчиненных баз.
Проблема возникает из-за жесткой последовательности проверки метаданных при обмене. Когда в центральной базе (ЦБ) обновляется расширение с новым режимом совместимости, оно автоматически регистрируется к отправке в подчиненные узлы. Однако подчиненный узел (ПБ) при попытке принять это сообщение сталкивается с противоречием:
ПрочитатьИзменения пытается инициализировать расширение раньше, чем будет обновлена основная конфигурация.Ситуация осложняется, если администратор пытается «починить» обмен, удаляя расширения вручную. Это часто приводит к ошибке преобразования XML: Ошибка при вызове метода контекста (ПрочитатьИзменения): Ошибка преобразования данных XML. Это происходит потому, что в планах обмена остаются зарегистрированные изменения для объектов, которых в базе больше нет (они были в удаленном расширении).
Чтобы избежать блокировки обмена, мы должны строго соблюдать последовательность действий на всех узлах системы. Рассмотрим шаги, которые позволят нам плавно перевести всю сеть на новый релиз.
Шаг 1: Обновление платформы на всех точках. Прежде чем начинать любые манипуляции в конфигураторе, убедимся, что на всех серверах и рабочих станциях установлена версия платформы, поддерживающая новый режим совместимости. Это критически важно, так как старая платформа просто не сможет запустить базу после обновления конфигурации.
Шаг 2: Обновление центрального узла. Выполняем обновление основной конфигурации в ЦБ. После этого адаптируем расширение: исправляем ошибки кода и, что самое важное, устанавливаем в свойствах расширения тот же режим совместимости, который установлен в основной конфигурации.
Шаг 3: Синхронизация и передача изменений. Запускаем сеанс обмена в центральной базе. В этот момент формируется файл выгрузки, содержащий изменения основной конфигурации и метаданные нового расширения.
Шаг 4: Прием изменений в подчиненном узле. В периферийной базе запускаем обмен. Если база выдает ошибку совместимости, нам может потребоваться сначала обновить конфигурацию ПБ «пустым» обменом. Разберем ситуацию, если обмен не проходит автоматически:
F7), режим совместимости в нем станет актуальным.Проанализируем ситуацию, когда расширение уже было удалено, но обмен продолжает выдавать ошибку Ошибка преобразования данных XML. Это верный признак того, что в таблицах регистрации изменений остались «фантомные» записи. Рассмотрим, как очистить эти данные программно.
Для этого нам понадобится обработка «Регистрация изменений для обмена» (входит в состав БСП) или небольшой фрагмент кода, который поможет нам сбросить регистрацию для проблемных узлов. Мы можем воспользоваться методом УдалитьРегистрациюИзменений().
// Пример очистки регистрации изменений для конкретного узла
УзелОбмена = ПланыОбмена.Розница.НайтиПоКоду("ПБ1");
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);
Важно: полное удаление регистрации заставит систему «забыть» о непереданных документах. Поэтому лучше удалять регистрацию выборочно, только для метаданных, связанных с расширениями. После очистки регистрации в обоих узлах (и в центре, и в периферии) необходимо выполнить повторную выгрузку конфигурации из центра.
Разберем важный нюанс, упомянутый в обсуждении: наличие новых справочников или регистров внутри расширения. Если ваше расширение не просто меняет логику кода, но и хранит данные в собственных таблицах, категорически запрещено удалять расширение для «починки» обмена.
При физическом удалении расширения из базы 1С все данные, накопленные в его объектах, удаляются безвозвратно. В РИБ это особенно опасно: если вы удалите расширение в подчиненном узле, а потом оно придет из центра через обмен, таблицы создадутся заново, но они будут пустыми. Если данные в расширении важны (например, специфические настройки магазина или дополнительные реквизиты чеков), используйте только метод обновления расширения через файл .cfe или через штатный механизм РИБ.
Проанализируем свойство расширения Использовать в распределенной информационной базе. Чтобы управление расширениями в РИБ было стабильным, придерживайтесь следующих правил:
В завершение отметим, что большинство проблем при обновлении РИБ с расширениями решается правильной подготовкой платформы и контролем за очередью регистрации изменений. Если обмен «завис», первым делом проверьте соответствие режимов совместимости и очистите регистрацию метаданных расширений в планах обмена.