Как массово обновить правила обмена данными в распределенных узлах базы 1С?

Рассмотрим распространенную архитектурную ситуацию в территориально распределенной сети магазинов на базе конфигурации 1С:Розница. Нередко внедренцы разделяют потоки передачи данных и конфигурации. Центральный узел (ЦУ) используется исключительно для распространения конфигурации подчиненным узлам (ПУ) через распределенную информационную базу (РИБ). При этом сами торговые узлы отправляют и получают бизнес-данные напрямую в управляющую центральную базу (ЦБР) по правилам конвертации и регистрации данных.

Когда в конфигурации изменяются метаданные (например, добавляются новые реквизиты в справочники или документы), возникает задача: как централизованно и без ручного входа в сотни магазинов обновить правила конвертации и регистрации данных на стороне торговых точек? Разберем правильные архитектурные подходы и детальный алгоритм реализации на основе типовых механизмов Библиотеки стандартных подсистем (БСП).

Архитектурное решение: поставка правил через макеты плана обмена

Если логика выгрузки во всех подчиненных узлах идентична, наиболее надежный и штатный способ — встроить обновленные правила прямо в метаданные конфигурации. В таком сценарии файл конфигурации распространяется штатным механизмом РИБ из ЦУ во все ПУ, а при обновлении информационной базы правила автоматически считываются из макетов и перезаписывают данные в системных регистрах.

Разберем по шагам, как устроен этот механизм в подсистеме ОбменДанными:

1. Размещение правил в макетах: в плане обмена, по которому происходит взаимодействие ПУ с ЦБР, создаются или обновляются двоичные макеты с именами ПравилаОбмена (для правил конвертации) и ПравилаРегистрации (для правил регистрации объектов). Если используется двусторонний обмен с контролем корреспондента, также актуализируется макет ПравилаОбменаКорреспондента.
2. Проверка интеграции плана обмена с БСП: план обмена должен быть полноценно подключен к подсистеме обмена данными. Для этого проверяем наличие плана обмена в общем модуле ОбменДаннымиПереопределяемый в экспортной функции ПолучитьПланыОбмена():
   Скопировать код

   
   Процедура ПолучитьПланыОбмена(ПланыОбменаПодсистемы) Экспорт
       ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.ОбменРозницаЦентральнаяБаза);
   КонецПроцедуры
   

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

   
   Процедура ОпределитьНастройки(Настройки) Экспорт
       Настройки.ИспользоватьПравилаКонвертации = Истина;
       Настройки.ИспользоватьПравилаРегистрации = Истина;
   КонецПроцедуры
   

Важные технические нюансы при обновлении через РИБ

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

1. Режим использования правил в регистре сведений: в типовой БСП правила физически хранятся в регистре сведений ПравилаДляОбменаДанными. Автоматическая перезапись из макетов при обновлении выполняется процедурой ОбменДаннымиСервер.ВыполнитьОбновлениеПравилДляОбменаДанными() только в том случае, если в регистре установлен источник «Из конфигурации». Если ранее администратор или внедренцы загрузили правила вручную из файла через интерфейс, система сохраняет флаг внешнего источника и проигнорирует новые макеты из конфигурации. В таком случае потребуется программно переключить признак источника.
2. Момент срабатывания обновления: само по себе получение пакета РИБ с конфигурацией не обновляет данные в регистрах. Обработчики обновления информационной базы отрабатывают при первом запуске предприятия или при запуске с параметром командной строки /UpdateCfg. Если узлы работают в автоматическом режиме без регулярного перезапуска сеансов предприятия под правами администратора, правила останутся прежними до фактического выполнения процедур обновления БСП.
3. Регистрация уже существующих объектов: важно помнить, что правила регистрации объектов (ПРО) отрабатывают в момент записи данных в подписках на события. Обновление правил в узлах само по себе не зарегистрирует объекты, которые были созданы до обновления. Чтобы накопленные данные по новому реквизиту ушли в ЦБР, необходимо инициировать принудительную перерегистрацию изменений.

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

УзелЦБР = ПланыОбмена.ОбменРозницаЦентральнаяБаза.НайтиПоКоду("ЦБР");
Если ЗначениеЗаполнено(УзелЦБР) Тогда
    ПланыОбмена.ЗарегистрироватьИзменения(УзелЦБР, Метаданные.Справочники.ФизическиеЛица);
КонецЕсли;

Альтернативные способы доставки правил без наката конфигурации

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

1. Централизованная загрузка из сетевого ресурса или сервиса: можно настроить регламентное задание в ПУ, которое периодически обращается к общему сетевому ресурсу, FTP-серверу или веб-сервису, проверяет дату изменения файла правил и при наличии новой версии программно загружает ее через менеджер регистра сведений ПравилаДляОбменаДанными.
2. Включение регистра правил в состав РИБ: по умолчанию регистры настроек обмена исключены из авторегистрации РИБ, чтобы узлы не перезаписывали индивидуальные настройки. Однако можно реализовать служебный механизм (или отдельный неразделенный регистр сведений), через который файл правил передается внутри стандартного сообщения РИБ из ЦУ в ПУ, после чего локальный обработчик переносит двоичные данные в рабочий регистр правил обмена.

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