Как зарегистрировать изменения при обмене данными без использования сообщений планов обмена?

Стандартный механизм обмена данными в платформах 1С основан на использовании объектной модели планов обмена и формировании файлов с помощью ЗаписьСообщенияОбмена. Однако в практической разработке регулярно возникают задачи, когда необходимо передавать данные во внешние системы (JSON, REST API, брокеры сообщений RabbitMQ/Kafka) или оптимизировать производительность высоконагруженных систем, избегая лишних транзакционных блокировок. Проанализируем ситуацию и разберем архитектурные варианты решения этой задачи.

1. Использование плана обмена только для регистрации изменений

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

Разберем по шагам порядок работы при таком подходе:

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

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

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	НоменклатураИзменения.Ссылка КАК Ссылка
    |ИЗ
    |	Справочник.Номенклатура.Изменения КАК НоменклатураИзменения
    |ГДЕ
    |	НоменклатураИзменения.Узел = &УзелОбмена";

Запрос.УстановитьПараметр("УзелОбмена", УзелНазначения);
Результат = Запрос.Выполнить().Выгрузить();

После обработки полученного массива данных удаляем регистрацию для отправленных объектов:

Для Каждого Строка Из Результат Цикл
    ПланыОбмена.УдалитьРегистрациюИзменений(УзелНазначения, Строка.Ссылка);
КонецЦикла;

2. Регистрация изменений через независимый регистр сведений

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

При таком подходе создается независимый регистр сведений (например, ОчередьВыгрузки) со следующей структурой измерений и ресурсов:

• ИдентификаторЗаписи (Число или УникальныйИдентификатор) — уникальный ключ события;
• ОбъектВыгрузки (ЛюбаяСсылка) — ссылка на измененный элемент или документ;
• ДатаСоздания (Дата) — время фиксации изменения.

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

3. Формирование и выгрузка данных непосредственно при записи объекта

Рассмотрим события, когда накопительная регистрация изменений не требуется, а выгрузка должна происходить мгновенно (событийно-ориентированная интеграция или Event-Driven Architecture).

В этом случае в подписке на событие ПриЗаписи или ПослеЗаписи выполняется прямая сериализация объекта в нужный формат (XML, JSON) и сохранение в определенный каталог или отправка по протоколу HTTP/HTTPS.

Обратите внимание на важные особенности данного способа:

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

4. Полная выгрузка данных при каждом сеансе обмена

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