Как настроить синхронизацию неидентичных конфигураций без правил обмена и исправить ошибку ПрочитатьXML?

← На главную

Рассмотрим частую задачу, с которой сталкиваются разработчики при интеграции баз 1С: необходимо настроить регулярную синхронизацию между двумя конфигурациями (например, 1С:ЗУП 3), одна из которых является типовой, а вторая — сильно доработанной. При попытке использовать типовой обмен без правил конвертации мы можем столкнуться с тем, что измененные объекты (например, справочник должностей с добавленными реквизитами) отказываются загружаться в базу-приемник.

В процессе обмена система выдает ошибку:


{ОбщийМодуль.ОбменДаннымиСервер.Модуль(6190)}: Ошибка при вызове метода контекста (ПрочитатьXML)
Данные = ПрочитатьXML(ЧтениеXML);
по причине:
Ошибка преобразования данных XML: ...

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

Почему возникает ошибка сериализации XML?

При типовом обмене «без правил конвертации», который рассчитан исключительно на идентичные конфигурации, платформа 1С использует жесткую сериализацию XML. Этот механизм напрямую опирается на структуру метаданных. При десериализации (чтении файла на стороне приемника) критически важным является не только точное совпадение имен всех реквизитов, но и их строгий порядок в дереве метаданных.

Если в одной из баз добавлен новый реквизит, структура генерируемого платформой XDTO-типа меняется. В результате базовый метод ПрочитатьXML завершается с ошибкой, так как не находит нужный тег в ожидаемом месте. Использование метода СериализаторXDTO.ПрочитатьXML также не решает проблему напрямую: при малейшем расхождении структур он выбрасывает ошибки вида «Поле объекта не обнаружено» или «Объект XDTO не может быть прочитан».

Для понимания того, как инициализируется подобный обмен, посмотрим на пример программной настройки параметров синхронизации с использованием библиотеки стандартных подсистем:


Процедура ПриПолученииНастроек(Настройки) Экспорт
    Настройки.Алгоритмы.ПриПолученииВариантовНастроекОбмена = Истина;
    Настройки.Алгоритмы.ПриПолученииОписанияВариантаНастройки = Истина;
КонецПроцедуры

Процедура ПриПолученииВариантовНастроекОбмена(ВариантыНастроекОбмена, ПараметрыКонтекста) Экспорт
    ВариантНастройки = ВариантыНастроекОбмена.Добавить();
    ВариантНастройки.ИдентификаторНастройки = "";
    ВариантНастройки.КорреспондентВЛокальномРежиме = Истина;
КонецПроцедуры

Но как обойти ошибку, если конфигурации уже не идентичны? Разберем несколько подходов.

Решение 1: Автоматическое создание правил в «Конвертации данных 2.1»

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

Выгрузим описания структур метаданных обеих баз (типовой и доработанной) с помощью стандартной обработки MD83Exp.epf.
Загрузим эти описания в конфигурацию «Конвертация данных 2.1».
Запустим инструмент «Синхронизация объектов» — система автоматически сопоставит все справочники, документы и регистры, а также создаст правила конвертации объектов (ПКО) и свойств (ПКС) для всех совпадающих по именам элементов.
Перейдем в настройки ПКО для проблемного справочника (в нашем случае — «Должности»).
В таблице свойств найдем нестандартные (добавленные) реквизиты и просто снимем с них флажок выгрузки.

Этот метод занимает минимум времени, но полностью решает проблему конфликта структур метаданных при автоматических обменах.

Решение 2: Синхронизация через Универсальный формат (EnterpriseData)

Поскольку речь идет о современных конфигурациях (таких как ЗУП 3), рассмотрим использование обмена через Универсальный формат (EnterpriseData). Это более отказоустойчивый подход для баз с доработками.

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

Решение 3: XSLT-преобразование XML-файла «на лету»

Если мы принципиально хотим оставить обмен без правил конвертации, можно использовать обходной путь — XSLT-преобразование. Суть метода заключается в редактировании структуры XML-документа до того, как он попадет в строгий метод ПрочитатьXML.

Для этого пишется короткий XSLT-скрипт, который парсит входящий файл и вырезает из него узлы, соответствующие нетиповым реквизитам. Получив «очищенный» и валидный с точки зрения типовой конфигурации XML, платформа без проблем его десериализует.

Решение 4: Построчное чтение и адаптивные обработки

Существуют ситуации, когда необходимо реализовать полуавтоматический обмен без внешних правил. В этом случае программисты прибегают к алгоритмам, построенным на ручном парсинге дерева XML. Как это работает:

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

Подобный по-теговый алгоритм чтения и сравнения можно подсмотреть в механизмах встроенного версионирования объектов платформы (например, при сравнении версий на хранилище значений в БСП). Однако, стоит отметить, что для регулярного ежедневного обмена самостоятельная разработка такого парсера трудозатратна, и целесообразнее использовать автоматизированные правила КД 2.1 или формат EnterpriseData.