Как адаптировать обмены при удалении механизма правил XML и Конвертации данных 2 из типовых конфигураций 1С?

← На главную

В рамках развития Библиотеки стандартных подсистем (БСП) и подсистемы синхронизации данных фирма 1С выводит из эксплуатации классический механизм обмена по правилам XML (технология «Конвертация данных 2.0»). Разберем, какие именно изменения происходят в типовых решениях, почему это происходит и какие практические варианты перехода существуют для действующих интеграций.

Какие изменения происходят в типовых конфигурациях

Проанализируем состав запланированных изменений в типовых релизах конфигураций 1С:

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

Выясним причины такого отказа. Главный фактор — архитектурные ограничения безопасности и контроля качества. В правилах КД 2.0 весь исполняемый код обработчиков передается в теле XML-файла и вызывается динамически с помощью конструкций Выполнить() и Вычислить(). Это нарушает политики безопасного режима платформы, работу в модели сервиса (SaaS) и делает невозможным статическую валидацию кода линтерами и системами контроля версий (CI/CD). В отличие от XML, логика обмена в EnterpriseData (КД 3) полностью содержится в коде общих модулей конфигурации.

Вариант 1. Переход на формат EnterpriseData и технологии КД 3

Основным штатным направлением интеграции между современными конфигурациями 1С является формат EnterpriseData (ED). Рассмотрим особенности адаптации обменов под этот механизм:

Использование предопределенного пакета XDTO: структура передаваемых сообщений описывается схемой XDTO. Вся логика сопоставления, выборки и заполнения реквизитов размещается в общем модуле МенеджерОбменаЧерезУниверсальныйФормат (или аналогичных отраслевых модулях интеграции).
Расширение формата под нетиповые реквизиты: если требуется передать кастомные справочники или документы, необходимо расширить схему XDTO и дописать обработчики выгрузки и загрузки объектов в менеджере обмена.
Перенос движений и наборов записей регистров: поскольку формат EnterpriseData ориентирован на объектные сущности (документы и справочники), движения регистров «из коробки» не передаются. Для их переноса движения упаковываются в дополнительные свойства/структуры XDTO в теле документа, а в обработчиках загрузки выполняется явная запись наборов записей.

Посмотрим на пример переопределения логики выгрузки свойства объекта в менеджере обмена EnterpriseData:


Процедура ПКО_Документ_РеализацияТоваровУслуг_Реквизиты_ПередВыгрузкой(Источник, Приемник, КомпонентыОбмена)
    // Заполняем кастомное свойство XDTO из реквизита документа
    Если ЗначениеЗаполнено(Источник.ДоговорКонтрагента) Тогда
        Приемник.Вставить("ДоговорИдентификатор", Строка(Источник.ДоговорКонтрагента.УникальныйИдентификатор()));
    КонецЕсли;
КонецПроцедуры

Вариант 2. Выделение механизма КД 2.0 в собственную изолированную подсистему

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

Разберем по шагам, как сохранить функционал КД 2.0 в обновляемой базе:

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


УстановитьБезопасныйРежим(Ложь);
// Запуск выполнения логики конвертации объектов по правилам XML
ОбработкаОбмена = Обработки.НетиповойОбменДаннымиXML.Создать();
ОбработкаОбмена.ИмяФайлаПравил = ПутьКПравилам;
ОбработкаОбмена.ВыполнитьВыгрузку();

Вариант 3. Переход на прямую интеграцию через HTTP-сервисы и JSON

Для задач односторонней или двусторонней репликации произвольных срезов данных (например, передача данных в моделирующую базу, витрину отчетов или аналитическую песочницу) эффективной альтернативой правилам XML является использование HTTP-сервисов и формата JSON.

Рассмотрим преимущества такого подхода:

Гибкость структур: передача независимых регистров сведений, движений документов и срезов таблиц без ограничений строгих схем XDTO.
Контроль версий: весь код сериализации и десериализации пишется на встроенном языке 1С, проверяется синтаксическим контролем и хранится в репозитории конфигурации.
Отсутствие накладных расходов XML: формат JSON компактнее и обрабатывается платформенным объектом ЗаписьJSON / ЧтениеJSON существенно быстрее.

Посмотрим на пример простой отправки пакета данных через HTTP-сервис:


Функция ОтправитьДанныеВПриемник(СтруктураПакета, АдресСервиса)
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, СтруктураПакета);
    ТелоЗапроса = ЗаписьJSON.Закрыть();
    
    HTTPЗапрос = Новый HTTPЗапрос("/api/v1/exchange/push");
    HTTPЗапрос.УстановитьТелоИзСтроки(ТелоЗапроса, КодировкаТекста.UTF8);
    
    HTTPСоединение = Новый HTTPСоединение(АдресСервиса, 443, , , , 30, Новый ЗащищенноеСоединениеOpenSSL());
    HTTPОтвет = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
    
    Возврат (HTTPОтвет.КодСостояния = 200);
КонецФункции

Сравнение подходов к архитектуре обменов

Проанализируем выбор инструмента в зависимости от сценария использования:

EnterpriseData (КД 3 / БСП): стандартный выбор для типовых конфигураций (ERP, КА, УТ, БП, ЗУП). Требует поддержки схем XDTO, но гарантирует совместимость при типовых обновлениях.
Изолированная подсистема КД 2.0: временный вариант для сохранения работоспособности сложных кастомных обменов между сильно доработанными базами при обновлении версий БСП.
HTTP-сервисы / шины данных (JSON): предпочтительный вариант для интеграций с нестандартными структурами, передачи движений регистров и взаимодействия со сторонними системами.