В процессе разработки и настройки синхронизации данных между конфигурациями на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с неочевидным поведением системы: даже если в XML-файл обмена включен пакет правил конвертации, база-приемник их игнорирует. Вместо этого система использует правила, которые были предварительно загружены в настройки синхронизации (регистры Библиотеки стандартных подсистем). В этой статье мы подробно разберем, почему архитекторы 1С выбрали именно такой подход, как это связано с безопасностью и как эффективно работать в таких условиях.
Проанализируем главную причину такого поведения системы. Основным драйвером изменений в механизмах обмена данными стала разработка и внедрение облачной инфраструктуры 1С:Fresh (SaaS-модель). В облаке базы данных разных организаций могут физически находиться на одном сервере, а процессы обмена могут быть автоматизированы.
Рассмотрим ситуацию с точки зрения безопасности. Технология Конвертация данных 2.0 предполагает наличие обработчиков событий (например, Перед загрузкой, После загрузки, При загрузке объекта), которые представляют собой произвольный код на языке 1С. Если бы база-приемник слепо доверяла правилам из входящего файла, злоумышленник мог бы подменить файл обмена (например, перехватив его в почтовом трафике) и вставить в него вредоносный код. Проанализируем пример такого «вредоноса», который мог бы содержаться в правилах:
// В обработчике "После загрузки данных"
Набор = РегистрыСведений.Контактная Информация.СоздатьНаборЗаписей();
Набор.Записать(); // Полная очистка контактной информации всех контрагентов
Именно поэтому в современных версиях Библиотеки стандартных подсистем (БСП) был внедрен механизм, при котором база-приемник использует только те правила, которые администратор явно загрузил в информационную базу. Проверенные правила хранятся в защищенном виде (в регистрах сведений), и система доверяет только им.
Выясним, как технически реализован этот приоритет в коде. В типовых конфигурациях за загрузку данных отвечает программный интерфейс БСП, в частности модули ОбменДаннымиСервер и ОбменДаннымиСобытия. Когда инициируется процесс синхронизации, система выполняет следующие шаги:
Правила для обмена данными (или аналогичных в зависимости от версии БСП).CorrespondentExchangeRules — правила базы-корреспондента), они программно передаются в обработку УниверсальныйОбменДаннымиXML.<ПравилаОбмена> внутри XML-файла передается другой текст правил, БСП принудительно подставляет свои данные, перекрывая поток из файла.Таким образом, дублирование правил в базе-источнике и базе-приемнике — это не ошибка, а обязательное требование для обеспечения целостности и безопасности данных. Источнику правила нужны, чтобы знать, что и как выгружать, а приемнику — чтобы знать, как интерпретировать и куда записывать полученные данные, используя доверенный алгоритм.
Ситуация, когда правила приходится обновлять в двух местах, часто приводит к ошибкам, если программист забыл обновить правила в одной из баз. Разберем, как минимизировать этот «сизифов труд»:
1. Использование «трехпакетного» файла правил. Хотя приемник может игнорировать правила внутри файла обмена, сам механизм загрузки правил в настройках синхронизации позволяет загрузить один и тот же файл (содержащий правила выгрузки, правила загрузки и правила очистки) в обе базы. При настройке синхронизации через помощник БСП часто предлагает обновить правила в «той базе» автоматически, если есть прямое соединение.
2. Режим совместимости в правилах конвертации. Посмотрим на настройки в самой Конвертации данных 2.0. В некоторых версиях БСП поведение системы может зависеть от флага режима совместимости. Однако в современных реалиях (начиная с БСП 2.4+) приоритет всегда остается за правилами в базе.
3. Переход на Конвертацию данных 3.0. Проанализируем современную альтернативу. В технологии EnterpriseData (КД 3.0) проблема передачи исполняемого кода в файлах решена принципиально. Вместо правил с кодом 1С используется фиксированный формат (XSD-схема). Логика преобразования данных в формат обмена и обратно «зашита» непосредственно в модули менеджера конфигурации. В этом случае файл содержит только данные, а база-приемник использует свой встроенный программный код для их обработки. Это исключает необходимость передавать правила и дублировать их в файлах.
Если вам все же необходимо проверить работу правил именно из файла (например, в процессе разработки), рассмотрим несколько способов обхода стандартного поведения БСП:
V8Exch82.epf (Универсальный обмен данными в формате XML). При ручном запуске этой обработки и указании файла обмена она будет использовать правила, находящиеся внутри этого файла, так как механизмы БСП в этом случае не задействуются.ОбменДаннымиСервер) можно найти момент инициализации правил и временно закомментировать подстановку из регистра, однако это крайне не рекомендуется для рабочих баз из-за рисков безопасности, описанных выше.Правила для обмена данными. Если вы обновили правила в конфигураторе (как макет), они могут не обновиться в регистре автоматически, если не была запущена процедура обновления версии конфигурации или ручная загрузка.Мы выяснили, что игнорирование правил из файла — это осознанное архитектурное решение фирмы 1С. Оно направлено на:
Для эффективной работы рекомендуется принять это поведение как стандарт и автоматизировать процесс доставки правил в обе базы через штатные средства Библиотеки стандартных подсистем или рассмотреть переход на формат EnterpriseData.