Как организовать обмен с одной базой через несколько узлов одного плана обмена в 1С

← На главную

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

Зачем использовать два узла вместо одного?

Разберем типичную ошибку начинающих разработчиков. Кажется, что можно использовать один узел и просто фильтровать данные в правилах выгрузки в зависимости от времени суток. Однако здесь кроется критическая проблема — нумерация сообщений. Если система выгрузила сообщение №100, в которое попали только справочники, то при получении подтверждения (квитанции) от базы-приемника, платформа автоматически снимет с регистрации все изменения, которые были зафиксированы на момент формирования сообщения №100, включая документы, которые вы «отфильтровали» программно. В итоге документы просто не будут переданы.

Использование двух независимых узлов позволяет иметь две автономные очереди регистрации изменений и два независимых счетчика сообщений. Это гарантирует, что подтверждение доставки справочников по «узлу №1» никак не повлияет на регистрацию документов по «узлу №2».

Реализация механизма зеркальных узлов

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

В центральной базе (ЦБ) создаем два узла. Например, с кодами ПБ_НСИ (для справочников) и ПБ_ДОК (для документов).
В подчиненной базе (ПБ) также необходимо создать два узла, которые будут смотреть на центральную базу. Но самое важное: в подчиненной базе должно быть создано два «входящих» узла с соответствующими кодами, чтобы при загрузке файлов система понимала, кто отправитель.
Настраиваем уникальные префиксы для имен файлов. Если этого не сделать, файлы обмена от разных узлов будут перезаписывать друг друга в каталоге обмена.

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

ЦБ -> ПБ_НСИ (выгружаем справочники)
ЦБ -> ПБ_ДОК (выгружаем документы)
ПБ -> ЦБ_НСИ (ответ по справочникам)
ПБ -> ЦБ_ДОК (ответ по документам)

Настройка правил регистрации изменений

Для того чтобы данные автоматически распределялись по нужным узлам, нам потребуется настроить ПравилаРегистрацииОбъектов. Выясним причину, по которой это лучше делать программно или через специализированные правила. В коде регистрации мы можем проверить, для какого узла в данный момент срабатывает событие.

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


Процедура ПриЗаписиОбъектаДляОбмена(Источник, Отказ)
    
    ПланОбменаСсылка = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("Обмен с филиалом");
    
    // Получаем узлы: один для НСИ, другой для документов
    УзелНСИ = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("ПБ_НСИ");
    УзелДОК = ПланыОбмена.СинхронизацияДанныхЧерезУниversalныйФормат.НайтиПоКоду("ПБ_ДОК");
    
    Если Метаданные.Справочники.Содержит(Источник.Метаданные()) Тогда
        ПланыОбмена.ЗарегистрироватьИзменения(УзелНСИ, Источник);
    ИначеЕсли Метаданные.Документы.Содержит(Источник.Метаданные()) Тогда
        ПланыОбмена.ЗарегистрироватьИзменения(УзелДОК, Источник);
    КонецЕсли;
    
КонецПроцедуры

Альтернативный вариант: Перенос регистрации между узлами

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

Рассмотрим пример кода для переноса регистрации объектов:


Процедура ПеренестиРегистрациюМеждуУзлами(УзелИсточник, УзелПриемник)
    
    // Выбираем все изменения, зарегистрированные для документов на узле-источнике
    ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(УзелИсточник, 1);
    
    Пока ВыборкаИзменений.Следующий() Цикл
        ОбъектИзменения = ВыборкаИзменений.Получить();
        
        // Регистрируем на основном узле
        ПланыОбмена.ЗарегистрироватьИзменения(УзелПриемник, ОбъектИзменения);
        
        // Снимаем с регистрации на служебном узле
        ПланыОбмена.УдалитьРегистрациюИзменений(УзелИсточник, ОбъектИзменения);
    КонецЦикла;
    
КонецПроцедуры

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

Особенности использования в типовых конфигурациях (БСП)

В современных конфигурациях на базе Библиотеки стандартных подсистем создание нескольких настроек обмена с одной базой может блокироваться интерфейсом. Рассмотрим, как это обойти:

Создайте первую настройку стандартным мастером.
Для второй настройки используйте копирование существующей или создание новой с указанием другого кода узла.
Если БСП проверяет уникальность базы-корреспондента по УникальныйИдентификатор (GUID), возможно, потребуется создать запись в справочнике УзлыИнформационныхБаз программно или изменить настройки префиксов.

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