Как обновлять измененные правила обмена в Конвертации данных 3.0 при потере комментариев?

Переход на технологию Конвертации данных 3.0 (КД 3.0) и использование универсального формата обмена EnterpriseData существенно изменили подход к интеграции систем 1С. В отличие от версии 2.1, где правила обмена представляли собой XML-файл, в КД 3.0 правила выгружаются в виде готового программного кода на встроенном языке 1С. Этот код помещается в модуль МенеджерОбменаЧерезУниверсальныйФормат.

Однако разработчики часто сталкиваются с серьезной проблемой: при генерации и выгрузке модуля менеджера обмена из информационной базы КД 3.0 полностью удаляются все комментарии. При выходе очередного обновления типовой конфигурации разработчику необходимо перенести свои доработки в новый типовой модуль менеджера обмена. Из-за отсутствия комментариев стандартное сравнение и объединение модулей в конфигураторе превращается в крайне трудоемкую задачу. Мы детально разберем причины этой проблемы и проанализируем основные практические подходы к ее решению.

Выясняем причину: почему пропадают комментарии?

В конфигурации «Конвертация данных 3.0» очистка комментариев происходит на этапе генерации текста модуля. Разработчики фирмы «1С» заложили этот алгоритм для минимизации объема выгружаемого программного кода. Поскольку правила для крупных конфигураций (таких как ERP, КА или УТ) содержат десятки тысяч строк, удаление ремарок и служебных комментариев позволяет сократить размер модуля менеджера обмена и ускорить его компиляцию платформой.

Тем не менее, для целей поддержки и обновления такой подход создает существенные препятствия. Ниже мы рассмотрим проверенные методики, которые позволяют успешно решать эту задачу в реальных проектах.

Метод 1. Сравнение «обескомментированных» версий правил

Если ваши доработки выполнены непосредственно внутри КД 3.0, и вы хотите сравнить старые доработанные правила с новыми типовыми, можно использовать метод выравнивания условий. Мы приводим обе конфигурации правил к одинаковому виду (без комментариев), что позволяет конфигуратору корректно сопоставить структуры кода.

Разберем этот процесс по шагам:

1. Загрузим новые типовые правила обмена из обновленной конфигурации в вашу базу КД 3.0 как новую версию правил.
2. Выполним выгрузку этих новых типовых правил в файл модуля (без внесения изменений). Назовем этот файл ТиповойМодуль_Новый_БезКомментариев.txt.
3. Выгрузим ваши старые измененные правила из КД 3.0 в другой файл. Назовем его ИзмененныйМодуль_Старый_БезКомментариев.txt.
4. Поскольку оба файла сгенерированы одной и той же версией КД 3.0, они оба полностью лишены комментариев и отформатированы по одинаковым правилам генератора кода.
5. Запустим сравнение этих двух файлов через встроенное сравнение файлов в Конфигураторе 1С или внешнюю утилиту (например, KDiff3 или Beyond Compare). Отсутствие комментариев в обоих файлах теперь не мешает сопоставлению, так как различия будут видны исключительно в логике измененных ПКО (Правил конвертации объектов), ПОД (Правил обработки данных) или ПКС (Правил конвертации свойств).

Метод 2. Канонический путь обновления внутри КД 3.0

Разработчики технологии КД 3.0 предполагали, что слияние и обновление правил должно происходить не на уровне сравнения текстовых файлов в Конфигураторе, а непосредственно внутри информационной базы «Конвертации данных». Этот подход исключает необходимость ручной правки сгенерированного кода.

Рассмотрим подробнее схему канонического обновления:

1. Обновление метаданных: Сначала загрузим в КД 3.0 обновленные структуры метаданных для обеих обменивающихся конфигураций (через обработку выгрузки метаданных).
2. Загрузка нового модуля: Загрузим новый типовой модуль менеджера обмена из поставки обновления в КД 3.0 как отдельную (новую) версию правил обмена.
3. Инструменты сопоставления КД 3.0: Используем встроенный в КД 3.0 механизм сравнения версий. В интерфейсе программы сопоставим ваши измененные правила (ПОД, ПКО, ПКС) с новыми правилами из поставки обновления.
4. Перенос доработок: Программно или интерактивно перенесем доработанные элементы из старой версии правил в новую.
5. Выгрузка результата: Сгенерируем итоговый модуль менеджера обмена. На выходе мы получим корректный, объединенный модуль без конфликтов разметки кода.

Метод 3. Использование расширений конфигурации (современный стандарт)

Самым надежным и современным способом кастомизации обмена через универсальный формат является полный отказ от изменения типового модуля МенеджерОбменаЧерезУниверсальныйФормат в основной конфигурации. Вместо этого все доработки реализуются с помощью расширений конфигурации.

Платформа 1С:Предприятие 8.3 предоставляет мощный механизм заимствования процедур менеджера обмена. Мы можем использовать аннотации для переопределения логики:

• Аннотация &ИзменениеИКонтроль: Позволяет заимствовать конкретную процедуру заполнения правил или обработчик события и внести туда точечные изменения. При обновлении конфигурации платформа автоматически проверит, не изменился ли типовой код внутри заимствованной процедуры, и предупредит разработчика в случае конфликта.
• Аннотация &После: Отлично подходит для программного расширения правил. Мы можем переопределить процедуру инициализации ПКО и добавить туда новые правила конвертации свойств без изменения основного тела модуля.

Рассмотрим пример кода в расширении, который программно добавляет новое правило конвертации свойства (ПКС) в существующее правило конвертации объекта (ПКО) при инициализации правил обмена:

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

КонецПроцедуры

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

Метод 4. Использование поля AdditionalInfo (Дополнительные сведения)

Если задача доработки правил обмена заключается исключительно в передаче нескольких нетиповых реквизитов, которых нет в стандартном формате XDTO, можно полностью избежать изменения структуры формата и перегенерации правил в КД 3.0.

Для этого задействуем стандартное свойство AdditionalInfo, которое присутствует практически у каждого объекта в формате EnterpriseData. В это свойство можно поместить любые текстовые данные, например, структуру в формате JSON или XML-строку.

Проанализируем пример схемы реализации:

1. В расширении конфигурации-источника перехватываем событие отправки данных и заполняем поле AdditionalInfo нужными значениями:

&Перед("ПередОтправкойДанных")
Процедура Расш1_ПередОтправкойДанных(ДанныеXDTO, КомпонентОбмена)
    
    // Проверим наличие свойства AdditionalInfo в схеме объекта XDTO
    Если ДанныеXDTO.Свойства().Получить("AdditionalInfo") <> Неопределено Тогда
        // Записываем сериализованные данные
        ДанныеXDTO.AdditionalInfo = "СпецПараметр=ЗначениеПараметра;ВторойПараметр=123;";
    КонецЕсли;

КонецПроцедуры

2. В расширении конфигурации-приемника перехватываем процедуру получения данных, считываем значение из поля AdditionalInfo, парсим его и записываем данные в нужные реквизиты объекта информационной базы.

Этот способ позволяет сохранить модуль обмена в обеих конфигурациях в абсолютно типовом виде.

Метод 5. Разделение модуля менеджера обмена в КД 3.0

В КД 3.0 предусмотрен встроенный механизм разделения кодовой базы. Если проект обмена очень масштабный, мы можем активировать в настройках КД 3.0 разделение модуля менеджера.

При использовании этого механизма огромный модуль МенеджерОбменаЧерезУниверсальныйФормат разбивается на несколько частей (базовый модуль, предопределенные модули и пользовательские модули под конкретные типы объектов метаданных). Также существует возможность выгружать правила непосредственно в модули менеджера самих объектов метаданных конфигурации. Это значительно локализует изменения: при обновлении конфигурации вам придется анализировать не один гигантский модуль на 100 000 строк, а лишь несколько небольших измененных файлов, что существенно снижает критичность отсутствия комментариев.

Резюме

Мы проанализировали различные варианты работы с измененными правилами обмена в Конвертации данных 3.0. Наиболее перспективным и соответствующим современным стандартам разработки 1С является вынос всех доработок в расширения конфигурации с использованием программного описания правил или механизма &ИзменениеИКонтроль. Если же обойтись без использования КД 3.0 невозможно, рекомендуется применять методику выгрузки "обескомментированной" типовой версии для последующего точного сравнения текстовых файлов в Конфигураторе.