Как эффективно использовать Конвертацию данных 3.0 и решать проблемы при сравнении правил обмена?

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

Философия КД 3.0: Отказ от прямых связей

Для начала проанализируем, зачем 1С вообще выпустила третью версию конвертации. В КД 2.0 мы строили прямые соответствия между метаданными источника и приемника. Если у нас было 5 различных баз, для организации обмена «каждый с каждым» требовалось написать и поддерживать десятки пар правил. КД 3.0 внедряет принципиально иной подход — использование универсального формата обмена EnterpriseData.

Рассмотрим преимущества этой архитектуры:

1. Отвязка источника от приемника: Каждая база теперь «знает» только то, как преобразовать свои данные в формат XML (EnterpriseData) и как получить данные из этого формата. Ей не важно, кто будет получателем.
2. Масштабируемость: Если вы добавляете в экосистему новую конфигурацию, вам достаточно один раз описать правила её взаимодействия с форматом EnterpriseData, и она автоматически сможет обмениваться данными со всеми остальными базами.
3. Использование кода 1С: Правила теперь не хранятся в огромных XML-файлах, а представляют собой программный код в модуле менеджера обмена. Это ускоряет выполнение обмена, так как исключается этап парсинга сложных деревьев правил в памяти.

Почему текст правил «плывет» при выгрузке?

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

Различия возникают из-за того, что:

• Порядок процедур и функций может определяться алгоритмами генератора, а не исходным порядком в типовом модуле.
• Автоматически расставляются регионы (#Область), комментарии и пробелы.
• Типовые правила часто содержат логику сразу для нескольких версий формата (например, 1.3, 1.5, 1.10). Если при загрузке в КД 3.0 вы указали только одну конкретную версию, генератор «отсечет» всё лишнее, и итоговый код будет значительно короче.

Метод «Round-trip» — решение проблемы сравнения

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

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

1. Возьмите старые типовые правила из прошлого релиза и загрузите их в КД 3.0. Тут же выгрузите их обратно в файл. Назовем его «Типовые_Нормализованные_Старые».
2. Возьмите ваши измененные правила и выгрузите их из КД 3.0. Назовем их «Мои_Правила».
3. Возьмите новые типовые правила из свежего релиза конфигурации, загрузите их в ту же КД 3.0 и выгрузите в файл «Типовые_Нормализованные_Новые».

Теперь у вас есть три файла, созданных одним и тем же генератором кода. Их можно смело сравнивать через Сравнить файлы в конфигураторе или внешними утилитами типа KDiff3. Различия будут касаться только реальной логики, а не оформления текста.

Практические советы по работе с модулем менеджера обмена

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

Рассмотрим пример того, как выглядит обработка данных в правилах КД 3.0. Вместо ПКО и ПКС здесь используются процедуры преобразования данных в XDTODataObject. Например, заполнение дополнительных реквизитов может выглядеть так:

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

Использование расширений — современный путь

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

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

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

Итоги

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