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

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

Проблема избыточной регистрации

Разберем стандартное поведение платформы: если в свойстве объекта Авторегистрация установлено значение Разрешить, то любое изменение объекта (даже полученное в ходе обмена) будет помещено в таблицу регистрации для всех узлов, входящих в этот план обмена. В схеме с «базой-посредником» и 60+ розничными точками это приводит к тому, что сообщение, пришедшее от «Точки-1», заставляет систему записывать 59 лишних строк в таблицу _ConfigChngRec. В результате время выгрузки увеличивается в геометрической прогрессии.

Решение 1: Отключение авторегистрации и переход на ручное управление

Первым и самым важным шагом является изменение настроек метаданных. Проанализируем, как это сделать правильно:

1. Откроем конфигуратор и найдем нужный план обмена.
2. В составе плана обмена для каждого объекта (документа, справочника) установим свойство Авторегистрация в значение Запретить.
3. Теперь регистрация изменений будет происходить только тогда, когда мы явно вызовем ее в коде.

Для программной регистрации изменений используем метод ПланыОбмена.ЗарегистрироватьИзменения(). Важно передавать в него массив конкретных узлов-получателей, а не всю выборку, чтобы избежать повторения проблемы «регистрации для всех».

Решение 2: Обработка свойства «ОбменДанных.Загрузка»

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

Если нам необходимо, чтобы при загрузке данных из «Центра» в «Клон» эти данные тут же регистрировались для «Розницы», мы должны модифицировать код в подписках на события. Типовая проверка выглядит так:

Если ОбменДанных.Загрузка Тогда
    Возврат;
КонецЕсли;

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

Процедура ПриЗаписиОбъектаДляОбмена(Источник, Отказ) Экспорт
    // Если это обычная запись пользователем - регистрируем всегда
    // Если это загрузка, проверяем, нужно ли нам проталкивать данные дальше
    Если Источник.ОбменДанных.Загрузка Тогда
        // Специальная логика регистрации для плана обмена "ОбменРозница"
        ПланыОбмена.ЗарегистрироватьИзменения(УзлыРозницы, Источник);
    Иначе
        // Стандартная регистрация
    КонецЕсли;
КонецПроцедуры

Решение 3: Использование события «ПриЗаписи» вместо «ПередЗаписью»

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

Оптимизация для высоконагруженных систем (60+ узлов)

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

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

Таким образом, комбинируя отключение Авторегистрации с грамотной обработкой свойства ОбменДанных.Загрузка в подписках на события ПриЗаписи, можно добиться существенного сокращения времени выгрузки сообщений и стабильной работы обмена с большим количеством розничных точек.