Зачем нужны "ПравилаОбменаКорреспондента" в приемнике при синхронизации данных через БСП?

← На главную

При настройке и кастомизации синхронизации данных между конфигурациями 1С на базе Библиотеки стандартных подсистем (БСП) разработчики часто сталкиваются с неочевидной логикой работы макетов правил. На первый взгляд структура XML-файла сообщения содержит в себе всё необходимое: и сами выгруженные данные, и правила их конвертации. Возникает логичный вопрос: зачем в базе-приемнике вообще хранить макет ПравилаОбменаКорреспондента, если теоретически система могла бы прочитать правила напрямую из входящего XML-файла?

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

Архитектура двустороннего обмена: зеркальность макетов

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

ПравилаОбмена — правила, по которым текущая база выгружает свои данные в базу-корреспондент.
ПравилаОбменаКорреспондента — правила, по которым база-корреспондент должна выгружать данные в текущую базу. По сути, это те же самые ПравилаОбмена, но «глазами» другой стороны.

Давайте проанализируем схему взаимодействия макетов в базах при двустороннем обмене:

Когда База А выполняет выгрузку в Базу Б, она использует свой макет ПравилаОбмена.
Когда База Б принимает эти данные от Базы А, она использует свой макет ПравилаОбменаКорреспондента.
При обратном потоке (из Базы Б в Базу А) База Б выгружает данные по своим ПравилаОбмена, а База А загружает их, опираясь на свои ПравилаОбменаКорреспондента.

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

Ключевой фактор: Информационная безопасность и защита от инъекций кода

Главная причина, по которой БСП игнорирует секцию правил конвертации во входящем XML-файле — это безопасность выполнения кода (концепция Sandbox). Рассмотрим эту ситуацию подробнее.

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

Правила обмена в формате «Конвертации данных 2.1» — это не просто разметка сопоставления полей. Они содержат в себе произвольный исполняемый код на встроенном языке 1С, который выполняется в различных обработчиках событий (например, ПередЗагрузкой, ПриЗагрузке, ПослеЗагрузки, ПослеЗагрузкиОбъекта).

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

Регламентные задания синхронизации данных обычно выполняются под учетными записями с максимальными правами (роль ПолныеПрава или запуск в привилегированном режиме).
Внедрение вредоносного кода в обработчик ПослеЗагрузки позволило бы выполнить на сервере 1С абсолютно любые действия: от удаления или искажения данных в СУБД до выполнения системных команд ОС через ЗапуститьПриложение.

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

Почему изменения в правилах источника срабатывают в приемнике? Анализ практического кейса

Рассмотрим частую ситуацию, которая вызывает путаницу у разработчиков: мы добавили новое поле (например, перенос реквизита «Комментарий» из источника в реквизит «Примечание» приемника) только в макет ПравилаОбмена на стороне источника. Приемник мы не трогали, его макет ПравилаОбменаКорреспондента остался старым. Тем не менее данные успешно перенеслись и заполнились. Почему так происходит, если правила в XML игнорируются?

Давайте разберем этот процесс по шагам:

Этап выгрузки (в источнике): Источник, используя свои обновленные ПравилаОбмена, видит соответствие полей. Он берет значение из реквизита «Комментарий» и записывает его в XML-файл уже под целевым именем приемника. В XML-сообщении это выглядит так:
```
<Свойство Имя="Примечание" Тип="Строка">
    <Значение>Важный комментарий к документу</Значение>
</Свойство>
```
Этап загрузки (в приемнике): Приемник начинает последовательно читать XML-файл. Движок загрузки БСП сопоставляет свойства «на лету». Видя тег свойства с именем "Примечание", загрузчик просто пытается записать это значение в соответствующий реквизит объекта в базе данных. Для выполнения этого стандартного платформенного действия никакие правила обмена на стороне приемника не требуются. Если реквизит с таким именем физически существует в метаданных документа базы-приемника, он будет успешно заполнен.

Таким образом, простые сопоставления реквизитов, не требующие написания кода в обработчиках загрузки, успешно отрабатывают сразу после обновления правил на стороне источника.

Когда макет "ПравилаОбменаКорреспондента" критически необходим в приемнике?

Локальные правила на стороне приемника вступают в работу только тогда, когда стандартного сопоставления объектов и реквизитов платформой недостаточно. Нам обязательно понадобятся актуальные ПравилаОбменаКорреспондента в приемнике в следующих случаях:

Использование обработчиков событий загрузки: Если логика интеграции требует написания кода в событиях ПриЗагрузке, ПослеЗагрузки, ПередЗаписью загружаемого объекта. Этот код будет извлечен исключительно из локальных правил приемника.
Сложные алгоритмы поиска (ПКС / Поля поиска): Если поиск существующего объекта в базе-приемнике выполняется не по стандартному уникальному идентификатору (GUID) или коду/наименованию, а по сложному алгоритму, описанному в обработчике ПоляПоиска.
Создание и инициализация объектов «на лету»: Когда при создании нового объекта в приемнике требуется заполнить дефолтные значения (например, подставить текущую организацию, склад или ответственного), задействуя обработчики инициализации.

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


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

Если бы мы обновили этот обработчик только в источнике, то при загрузке в приемник он бы просто проигнорировался ради безопасности всей системы.

Резюме

Подведем итоги нашего анализа:

Макаеты ПравилаОбменаКорреспондента необходимы в приемнике для безопасного выполнения исполняемого кода обработчиков (таких как ПослеЗагрузки, ПоляПоиска).
БСП целенаправленно игнорирует блок правил внутри XML-файла обмена для исключения возможности внедрения и выполнения вредоносного кода.
Простые изменения реквизитов (без написания кода в обработчиках загрузки) могут работать без обновления правил в приемнике, так как сопоставление наименований свойств происходит на этапе выгрузки в источнике, а приемник лишь считывает готовые пары "Ключ - Значение".

Для стабильной работы сложных обменов всегда поддерживайте актуальность макетов правил с обеих сторон обменивающихся информационных систем.