← На главную

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

Принцип разделения ответственности между источником и приемником

Проанализируем, как устроен типовой процесс передачи данных в формате КД 2.0:

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

Таким образом, правила направления «Источник-Приемник» являются единым логическим комплектом, но исполняются раздельно: выгрузка работает по правилам источника, а логика создания, заполнения и проведения объектов в целевой базе управляется правилами, хранящимися в самом приемнике.

Безопасность и защита от подмены исполняемого кода

Главная причина, по которой конфигурация-приемник игнорирует исполняемый код из входящего XML-пакета, — это информационная безопасность. В ранних версиях подсистем обмена существовала возможность передачи правил внутри транспортного контейнера. Это создавало уязвимость: при передаче файла обмена через незащищенные каналы (FTP, общие сетевые папки, внешнюю почту) злоумышленник мог внедрить произвольный код на встроенном языке 1С в текст обработчика загрузки, который затем выполнился бы на сервере целевой базы.

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

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

Практическая проверка работы обработчиков

Посмотрим на наглядный эксперимент, подтверждающий этот механизм. Предположим, для правила конвертации объекта (ПКО) в обработчик ПослеЗагрузки мы помещаем управление переменной Отказ.

Рассмотрим два сценария:

1. Сценарий 1: В правилах базы-источника прописан код:
   Скопировать код

   
   // Обработчик "После загрузки" в Источнике
   Отказ = Истина;
   

   В правилах базы-приемника для этого же ПКО задано:
   Скопировать код

   
   // Обработчик "После загрузки" в Приемнике
   Отказ = Ложь;
   

   Результат: Объект успешно создается и записывается в базе-приемнике, так как код из правил источника при загрузке был полностью проигнорирован.
2. Сценарий 2: В источнике оставляем Отказ = Ложь, а в правилах приемника задаем Отказ = Истина.
   Результат: Документ не загружается в базу-приемник, так как сработал локальный обработчик приемника.

Особенности хранения и обновления правил в БСП

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

1. Встроенные макеты vs Регистр сведений: По умолчанию система использует правила из макетов конфигурации. Если для узла обмена включено использование внешних правил, они считываются из регистра ПравилаДляОбменаДанными.
2. Рассинхронизация при обновлении: Если база-источник обновлена на новый релиз конфигурации, а база-приемник осталась на старом (или наоборот), структуры данных и состав полей могут не совпасть. В этом случае выгрузка сформирует XML-структуру с новыми тегами, которые старые правила приемника не смогут корректно обработать. При изменении логики конвертации необходимо синхронно обновлять правила в обеих информационных базах.
3. Отладка обработчиков загрузки: Поскольку код обработчиков генерируется динамически через конструкцию Выполнить(), точки останова для событий загрузки сработают исключительно в сеансе базы-приемника при подключении отладчика к серверному процессу фонового задания обмена.

Альтернативный подход: EnterpriseData (КД 3.0)

В более современной концепции обмена через универсальный формат EnterpriseData (КД 3.0) концепция передачи файлов правил отсутствует вовсе. Вся логика сопоставления вынесена в специализированные общие модули каждой базы (модули менеджеров обмена). База-источник только сериализует свои данные в формат XDTO, а база-приемник самостоятельно читает XDTO-пакет и трансформирует его в объекты своих метаданных по внутренним строго зафиксированным алгоритмам.