Как добавить собственный объект в несколько версий пакетов EnterpriseData без дублирования?

При адаптации типового обмена EnterpriseData под специфику бизнеса регулярно возникает задача расширения формата новыми объектами. Однако в типовых конфигурациях одновременно присутствуют до десяти и более версий формата (например, от 1.5 до 1.10 и выше). Поддерживать актуальную структуру одного и того же дополнительного типа данных вручную в каждом отдельном XDTO-пакете трудозатратно и неизбежно ведет к ошибкам рассинхронизации.

Проанализируем технические ограничения платформы 1С:Предприятие и подсистемы БСП, а также разберем проверенные подходы, позволяющие избежать ручного копирования структуры объектов.

В чем заключается архитектурное ограничение XDTO и БСП?

Выясним причину, по которой нельзя просто привязать один созданный XDTO-пакет ко всем версиям обмена:

1. Неразрывная связь с пространством имен (Target Namespace): В модели XML Schema и платформенном механизме XDTO любой тип жестко принадлежит конкретному пространству имен. Каждая версия формата EnterpriseData использует свой уникальный URI. Поэтому пакет расширения обязан явно импортировать базовое пространство имен конкретной версии и иметь собственный дочерний URI, привязанный к этой версии.
2. Механизм регистрации расширений в БСП: Регистрация расширяющих пакетов выполняется в процедуре ОбменДаннымиПереопределяемый.ПриПолученииДоступныхРасширенийФормата. В коллекцию соответствия в качестве ключа передается пространство имен расширяющего пакета, а значением выступает номер версии формата. Так как ключ соответствия уникален, один и тот же URI физически невозможно зарегистрировать для двух разных версий формата.

Следовательно, для каждой поддерживаемой версии EnterpriseData в системе должен существовать физически отдельный XDTO-пакет. Разберем практические способы решения этой проблемы без монотонного ручного труда.

Решение 1. Архитектурная фиксация единой версии обмена

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

Разберем последовательность шагов по оптимизации состава версий:

1. Определим минимальную версию EnterpriseData, которую поддерживают все базы-участники интеграции (например, наименее обновленная база поддерживает версию 1.8, а наиболее свежая — 1.11).
2. Зафиксируем версию 1.8 (или наиболее актуальную для вашей инфраструктуры) в качестве единственной рабочей для обмена между этими узлами.
3. В настройках узлов планов обмена отключим автоопределение версий и возможность использовать устаревшие форматы.
4. Создадим ровно один расширяющий XDTO-пакет только для выбранной версии формата.

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

Решение 2. Подход «Single Source of Truth» с автоматической генерацией схем

Если специфика распределенной архитектуры требует одновременной отдачи нового объекта во все поддерживаемые версии формата, применим паттерн единого источника истины (Single Source of Truth) с кодогенерацией.

Разберем по шагам реализацию данного процесса:

1. Создание мастер-схемы: Опишем структуру нового объекта формата один раз во внешнем файле XML Schema (.xsd). При этом все изменяемые пространства имен и ссылки на версии EnterpriseData оформляются в виде подстановочных маркеров (плейсхолдеров).
2. Хранение в системе контроля версий: Поместим мастер-схему в репозиторий (Git). Любые изменения состава реквизитов, типов данных или табличных частей вносятся исключительно в этот эталонный файл.
3. Скрипт сборки: Напишем консольный скрипт (например, на OneScript или Python), который обходит список целевых версий формата, подставляет нужные пространства имен, формирует результирующие .xsd-файлы и обновляет пакеты XDTO в исходниках расширения или конфигурации.
4. Регистрация пакетов: В коде модуля ОбменДаннымиПереопределяемый регистрируем сгенерированные пакеты для каждой версии:

Процедура ПриПолученииДоступныхРасширенийФормата(ПравилаОбработки, ДоступныеРасширения) Экспорт
    
    // Регистрируем сгенерированные расширяющие пакеты под каждую версию
    ДоступныеРасширения.Вставить("http://v8.1c.ru/edi/edi_app/EnterpriseData/1.8/custom", "1.8");
    ДоступныеРасширения.Вставить("http://v8.1c.ru/edi/edi_app/EnterpriseData/1.9/custom", "1.9");
    ДоступныеРасширения.Вставить("http://v8.1c.ru/edi/edi_app/EnterpriseData/1.10/custom", "1.10");
    
КонецПроцедуры

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

Решение 3. Передача данных через стандартное свойство AdditionalInfo

Рассмотрим альтернативный вариант, позволяющий передать произвольные данные вообще без добавления собственных XDTO-пакетов и без правки схемы формата.

В базовом типе Object схемы EnterpriseData предусмотрено служебное строковое свойство AdditionalInfo. Это свойство присутствует во всех версиях формата.

Посмотрим на логику работы с этим полем:

1. Если новые данные логически дополняют существующий объект (например, справочник или документ), упакуем структуру этих данных в строку формата JSON или XML.
2. В обработчике менеджера обмена ПКО_..._ПриОтправкеДанных поместим сериализованную строку в свойство AdditionalInfo.
3. На стороне приемника в обработчике ПКО_..._ПриПолученииДанных прочитаем строку из AdditionalInfo, десериализуем ее и запишем сведения в соответствующие реквизиты или регистры сведений.

Преимущество этого метода — абсолютная универсальность. Код заполнения и чтения работает одинаково во всех версиях EnterpriseData, а конфигурация и расширения остаются полностью независимыми от модификаций XDTO-пакетов.