При использовании распределенных информационных баз (РИБ) многие разработчики сталкиваются с ограничением: система ожидает идентичности конфигураций во всех узлах. Если в основной базе и во вспомогательной базе установлены разные расширения, при попытке типовой синхронизации 1С может выдавать ошибки о несовпадении версий конфигурации, что приводит к замедлению или полной остановке обмена данными. Давайте разберемся, как настроить этот процесс, чтобы обеспечить корректную работу.
Механизм РИБ в 1С изначально предполагает, что конфигурации в главном и подчиненном узлах должны совпадать до мелочей. Когда вы подключаете РасширениеКонфигурации, 1С по умолчанию пытается включить его в состав метаданных, передаваемых при обмене. Если вы пытаетесь «подружить» базы с разными расширениями, система воспринимает это как конфликт структур. Чтобы решить задачу, нам необходимо разделить понятие «обмен данными» и «обмен конфигурацией».
Самое важное действие, которое необходимо выполнить — это настроить ПланОбмена так, чтобы он не пытался синхронизировать сами расширения между узлами. Если в ваших расширениях нет пересекающихся объектов метаданных, требующих принудительного обновления структуры, вам не нужно, чтобы 1С пыталась «доставить» расширение из главного узла в периферийный.
ПланОбмена в конфигураторе.Когда опция передачи расширений отключена, каждый узел базы данных продолжает работать со своим набором доработок автономно. При выполнении обмена 1С будет передавать только измененные данные (документы, справочники), не анализируя состав расширений на соответствие.
Многие опасаются, что при отключении передачи расширений возникнут проблемы с обновлением самой типовой конфигурации. Практика показывает, что если вы не используете расширения для изменения критических для обмена объектов (например, состава реквизитов регистров, участвующих в обмене), то типовая конфигурация будет обновляться штатно. Важно придерживаться правила: не меняйте структуру метаданных через расширения, если эти объекты должны участвовать в обмене данными, иначе вы получите ошибку при записи объекта, так как принимающая сторона не «узнает» новый реквизит.
Если в вашем расширении появились новые объекты метаданных (например, РегистрСведений или Справочник), которые должны быть доступны в обеих базах, то РИБ в чистом виде здесь не подойдет. РИБ предназначен для передачи данных, структура которых известна обеим сторонам. В этом случае мы рекомендуем:
ПланОбмена, чтобы система их не «искала» при приеме данных.Рассмотрим несколько советов, которые помогут избежать проблем при эксплуатации системы:
Контроль состава объектов: Всегда проверяйте, что ПланОбмена не пытается выгрузить объекты, которые есть в одном узле, но отсутствуют в другом. Это приводит к ошибкам десериализации XML при получении сообщения обмена.
Работа с удалением объектов: Механизм РИБ автоматически регистрирует факт пометки на удаление или физического удаления объекта в ПланОбмена. Вам не нужно писать дополнительный код для этого — система сама добавит запись в таблицу регистрации изменений. Ваша задача — следить за тем, чтобы объекты, подлежащие удалению, существовали в обоих узлах, иначе узел-приемник выдаст ошибку отсутствия ссылки.
Использование универсального обмена: Если вы понимаете, что логика обмена становится слишком сложной из-за различий в базах, не пытайтесь «взломать» РИБ. Переходите на УниверсальныйОбменДанными через XML или формат EnterpriseData. Это позволит вам гибко настраивать правила конвертации данных (КД 3.0), где соответствие объектов между базами настраивается через правила, а не через идентичность конфигураций.
В завершение проанализируем ситуацию: если расширения содержат только логику (алгоритмы, формы), то их различие не препятствует обмену данными через РИБ. Достаточно просто исключить их передачу через настройки плана обмена, и система будет работать стабильно, не обращая внимания на отсутствие идентичности в «дополнительном слое» конфигурации.