Как организовать квитирование и удаление регистрации изменений при файловом обмене через УниверсальныйОбменДаннымиXML?

← На главную

При настройке регулярного обмена данными между информационными базами через файлы часто встает задача гарантированной доставки данных. Если мы запускаем обработку УниверсальныйОбменДаннымиXML в фоновом режиме, то сталкиваемся с вопросом: как узнать, что файл в базе-приемнике успешно прочитан, и в какой момент можно безопасно очистить регистрацию изменений в базе-источнике?

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

Почему возникают ошибки при прямом подключении и типовой синхронизации

Прежде чем перейти к схеме квитирования, выясним причины сбоев, о которых часто упоминают разработчики при попытке настроить прямое подключение или стандартный обмен:

Ошибка передачи мутабельного значения: возникает при прямом вызове через COM-соединение, когда контекст выполнения пытается вернуть или передать объекты, состояние которых может динамически меняться. В частности, к ним относятся ссылки на формы, несериализуемые выборки, сеансовые данные или сам ДокументОбъект при проведении в неразделенном серверном или клиентском контексте. Файловый обмен полностью изолирует базы друг от друга, поэтому такая ошибка исключена.
Счетчик сообщений растет, но данные не загружаются: если стандартная синхронизация фиксирует факт отправки, но данные в приемнике не появляются, частой причиной является сбой нумерации сообщений. Если номер входящего пакета меньше или равен номеру последнего успешно принятого сообщения в базе-приемнике, система отклоняет данные как устаревшие (коллизия фиксируется в журнале регистрации). Вторая причина — несовпадение кодов узлов: код предопределенного узла ЭтотУзел в одной базе должен в точности соответствовать коду узла-корреспондента в другой базе.

Способ 1. Использование механизма сообщений обмена платформы

Обработка УниверсальныйОбменДаннымиXML при стандартной выгрузке по узлу плана обмена формирует тело XML-документа, но не создает платформенный заголовок пакета обмена, где содержится номер сообщения. Посмотрим, как встроить платформенный механизм квитирования изменений с помощью объектов ЗаписьСообщенияОбмена и ЧтениеСообщенияОбмена.

Разберем по шагам схему выгрузки данных с привязкой к номеру сообщения:

Создаем объект ЗаписьXML и открываем файл для выгрузки.
Инициализируем объект ЗаписьСообщенияОбмена и связываем его с открытым файлом XML.
Вызываем метод НачатьЗапись(), передав узел плана обмена. Платформа автоматически сформирует заголовок с новым номером сообщения обмена и номером подтвержденного входящего сообщения.
Выбираем зарегистрированные изменения с помощью ПланыОбмена.ВыбратьИзменения(), зафиксировав их за данным исходящим номером.
Выгружаем данные объектов и завершаем запись сообщением ЗакончитьЗапись().

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


ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.ОткрытьФайл(ИмяФайлаОбмена);

ЗаписьСообщения = ПланыОбмена.СоздатьЗаписьСообщения();
ЗаписьСообщения.НачатьЗапись(ЗаписьXML, УзелКорреспондент);

// Номер текущего формируемого сообщения зафиксирован в заголовке
НомерОтправленного = ЗаписьСообщения.НомерСообщения;

// Выборка зарегистрированных изменений с фиксацией за текущим номером пакета
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелКорреспондент, НомерОтправленного);

// Здесь выполняется запись данных через XML-поток...

ЗаписьСообщения.ЗакончитьЗапись();
ЗаписьXML.Закрыть();

Рассмотрим подробнее, как происходит подтверждение доставки (квитирование):

База-приемник открывает файл через ЧтениеXML и ЧтениеСообщенияОбмена, считывает заголовок методом НачатьЧтение() и загружает данные.
После успешного завершения транзакции загрузки база-приемник формирует ответный файл-квитанцию для узла-источника. В качестве номера принятого сообщения приемник указывает номер только что прочитанного пакета.
База-источник при очередном сеансе сначала считывает квитанцию из приемника. Из заголовка извлекается номер подтвержденного сообщения (НомерПринятого).
Для очистки регистрации изменений вызывается метод ПланыОбмена.УдалитьРегистрациюИзменений(УзелКорреспондент, НомерПринятого).

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

Способ 2. Контроль выгрузки через регистр сведений и файлы-ответы

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

Разберем логику работы этого варианта:

Регистрация очереди: создаем непериодический регистр сведений, например, ОчередьВыгрузки, с измерениями Объект (ссылка на выгружаемый элемент) и НомерПакета (число).
Формирование пакета: перед началом выгрузки фоновое задание присваивает очередную порцию данных новому номеру пакета и выгружает сформированный список через УниверсальныйОбменДаннымиXML. В тело выгрузки или отдельный файл-дескриптор помещается идентификатор (номер) текущего пакета.
Загрузка в приемнике: база-приемник обрабатывает XML-файл. При успешном завершении загрузки формируется простой ответный XML-файл или JSON-квитанция, содержащая статус выполнения и подтвержденный номер пакета.
Очистка очереди: база-источник проверяет каталог обмена на наличие файлов-ответов. Считав номер подтвержденного пакета, фоновое задание удаляет записи из регистра сведений ОчередьВыгрузки с соответствующим номером пакета, а также снимает регистрацию с самого узла плана обмена при необходимости.

Способ 3. Переход на штатный файловый транспорт БСП или РИБ

Если обмен настраивается между полностью идентичными конфигурациями одного релиза, разработка собственных механизмов выгрузки через УниверсальныйОбменДаннымиXML часто оказывается избыточной. Рассмотрим штатные альтернативы:

Файловый транспорт БСП: типовая подсистема синхронизации данных позволяет настроить обмен без использования COM-соединения. Достаточно выбрать канал передачи «Общий сетевой ресурс» или «Каталог обмена». При этом система автоматически формирует zip-пакеты, инкрементирует номера сообщений и квитирует доставку без риска ошибок передачи мутабельных значений.
Распределенная информационная база (РИБ): для двух баз одинаковой конфигурации создание узла РИБ является наиболее отказоустойчивым решением. Вся работа по фиксации номеров сообщений, разрешению коллизий и удалению регистрации изменений выполняется непосредственно ядром платформы 1С:Предприятие.