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