Почему «1С:Конвертация данных 3.0» ломает модуль «МенеджерОбменаЧерезУниверсальныйФормат» и как это исправить?

← На главную

Разработчики, регулярно работающие с механизмом синхронизации данных через универсальный формат (EnterpriseData) и конфигурацией «1С:Конвертация данных 3.0» (КД3), часто сталкиваются с крайне неприятной проблемой. При попытке загрузить типовые правила обмена из современных конфигураций (например, 1С:Бухгалтерия 3.0, 1С:ERP или 1С:Управление торговлей 11), внести в них изменения и выгрузить обратно в модуль МенеджерОбменаЧерезУниверсальныйФормат, конфигуратор 1С начинает выдавать ошибки компиляции общего модуля.

Проанализируем ситуацию: в процессе выгрузки правил обратно в модуль менеджера обмена создаются дублирующиеся процедуры с одинаковыми именами. Например, процедуры обработчиков превращаются в нечто подобное:


Процедура ПКО_АннулированиеПодарочныхСертификатов_Получение_()
    // ...
КонецПроцедуры

Процедура ПКО_АннулированиеПодарочныхСертификатов_Получение_()
    // ...
КонецПроцедуры

Естественно, платформа 1С:Предприятие не допускает существования двух процедур с одинаковыми именами в рамках одного программного модуля, из-за чего обновление конфигурации становится невозможным. Выясним глубинную техническую причину этой проблемы и детально разберем все способы ее решения.

Причина сбоя: почему КД3 обрезает имена процедур

Данная проблема кроется непосредственно в архитектуре метаданных самой конфигурации «Конвертация данных 3.0». Для хранения правил конвертации объектов в ней используется справочник ПравилаКонвертацииОбъектов (ПКО).

Разберем по шагам логику работы КД3 при импорте и последующем экспорте правил:

В типовой конфигурации КД3 длина реквизита Наименование у справочника ПравилаКонвертацииОбъектов жестко ограничена и составляет всего 50 символов.
При импорте правил обмена или разборе общего модуля МенеджерОбменаЧерезУниверсальныйФормат13 КД3 автоматически создает элементы в справочнике ПКО. Если имя объекта метаданных длинное (например, АннулированиеПодарочныхСертификатов), то полное наименование правила превышает лимит в 50 символов и обрезается платформой до АннулированиеПодарочныхСертификатов_Получение_.
Когда мы вносим изменения и генерируем модуль менеджера обмена обратно, КД3 формирует имена процедур-обработчиков по стандартному шаблону: ПКО_[ИмяПКО]_[ИмяОбработчика].
Поскольку имя ПКО в базе данных КД3 уже было обрезано при импорте, КД3 пытается сгенерировать имена процедур для разных событий (например, для событий ПриКонвертацииДанныхXDTO и ПередЗаписьюПолученныхДанных), используя усеченную строку. В результате уникальные окончания процедур отбрасываются, и на выходе мы получаем дублирующиеся методы.

К счастью, существует несколько надежных способов обойти это ограничение. Рассмотрим их подробнее.

Способ 1. Модернизация метаданных КД3 (Рекомендуемый системный подход)

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

Выполним следующие действия по шагам:

Откроем базу «Конвертация данных 3.0» в режиме Конфигуратора.
Создадим новое расширение конфигурации или откроем существующее.
Добавим в расширение справочник ПравилаКонвертацииОбъектов.
Увеличим длину стандартного реквизита Наименование со значения 50 до 150 символов.
Аналогичным образом добавим в расширение справочники ПравилаОбработкиДанных (ПОД) и Алгоритмы, также увеличив длину их наименований до 150 символов. Дело в том, что длинные имена правил обработки данных и произвольных алгоритмов тоже могут вызывать аналогичные коллизии при генерации модуля.
Применим изменения в базе данных КД3.

После проведения этой несложной процедуры необходимо заново импортировать правила обмена из XML-файла или модуля менеджера в базу КД3. Теперь имена правил будут импортироваться полностью, без усечения, и при обратной выгрузке генератор КД3 сформирует корректные, уникальные имена для всех процедур-обработчиков.

Способ 2. Разработка правил обмена напрямую в коде через Расширения (Best Practice)

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

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

Создаем расширение в нашей рабочей конфигурации (например, в «1С:Бухгалтерии 3.0»).
Заимствуем в расширение общий модуль МенеджерОбменаЧерезУниверсальныйФормат13 (или ту версию модуля, которая используется в вашей текущей интеграции).
Пишем доработки необходимых обработчиков, используя аннотации расширения. Чаще всего применяется директива &ИзменениеИКонтроль, которая позволяет точечно переопределить логику работы конкретной процедуры, или директивы &После и &Перед для выполнения дополнительного кода.

Посмотрим на пример использования аннотации &После для доработки стандартного обработчика формирования данных:


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

Этот метод гарантирует, что при очередном обновлении типовой конфигурации ваши изменения не «затрутся» и не вызовут конфликтов компиляции, а сама среда разработки не пострадает от ограничений КД3.

Способ 3. Передача нестандартных данных через AdditionalInfo

Бывают ситуации, когда вам нужно передать между базами новые реквизиты, которых нет в стандартном формате EnterpriseData. Вместо того чтобы переопределять сложные ПКО в КД3 и дорабатывать схемы XDTO, можно воспользоваться стандартным свойством AdditionalInfo (Дополнительные сведения), которое поддерживается практически всеми объектами в универсальном формате.

Рассмотрим, как это реализовать программно в модуле менеджера без изменения структуры правил КД3.

На стороне базы-источника в процедуре отправки данных мы можем принудительно добавить произвольные данные в структуру AdditionalInfo:


// Запись дополнительных реквизитов в объекте-источнике
ДополнительныеСвойстваОбъекта = Новый Структура;
ДополнительныеСвойстваОбъекта.Вставить("ОсобыйРежимДоставки", Истина);
ДополнительныеСвойстваОбъекта.Вставить("КодВнешнейСистемы", "EXT-99823");

ДанныеXDTO.Вставить("AdditionalInfo", ДополнительныеСвойстваОбъекта);

На стороне базы-приемника в обработчике получения данных мы можем легко прочитать эту структуру и записать данные в соответствующие реквизиты объекта информационной базы:


// Чтение дополнительных реквизитов на стороне приемника
Если ДанныеXDTO.Свойство("AdditionalInfo") И ДанныеXDTO.AdditionalInfo <> Неопределено Тогда
    СтруктураСвойств = ДанныеXDTO.AdditionalInfo;
    
    // Проверяем наличие наших кастомных свойств
    Если СтруктураСвойств.Свойство("КодВнешнейСистемы") Тогда
        ДанныеИБ.ДополнительныеСвойства.Вставить("КодВнешнейСистемы", СтруктураСвойств.КодВнешнейСистемы);
    КонецЕсли;
КонецЕсли;

Использование свойства AdditionalInfo избавляет от необходимости усложнять структуру правил конвертации в КД3, минимизирует вероятность ошибок при генерации модуля обмена и позволяет обмениваться любыми произвольными типами данных.

Способ 4. Использование режима разделения модуля менеджера

Если проект обмена масштабный, а общий модуль менеджера обмена разросся до десятков тысяч строк кода, ориентироваться в нем становится крайне сложно. Начиная с версии КД 3.1, разработчики фирмы «1С» добавили штатную возможность разделения огромного модуля менеджера обмена на несколько частей.

При включении специального флага «Режим разделения модуля менеджера» в настройках конвертации КД3 разделяет один гигантский общий модуль на группу более мелких вспомогательных модулей (по направлениям обмена, по типам метаданных или по конкретным объектам). Это существенно упрощает групповую разработку, позволяет использовать современные инструменты (такие как 1С:Enterprise Development Tools / EDT) и снижает нагрузку на платформу при компиляции конфигурации.