Переход с «Конвертации данных 2.1» на версию 3.1 часто вызывает сложности у разработчиков, привыкших к классической схеме «Источник — Приемник». В новой парадигме правила строятся вокруг универсального формата обмена, что требует иного подхода к проектированию и доработке систем. Разберем подробно, какие материалы стоит изучить и как технически реализовать расширение типового формата EnterpriseData.
Проанализируем главное различие между этими инструментами. В КД 2.1 мы создавали жесткую связку между двумя конкретными конфигурациями. Если менялась структура одной из них, приходилось переписывать правила. В КД 3.1 используется посредник — формат EnterpriseData (ED) на базе XDTO. Каждая информационная база теперь отвечает только за свою часть работы: преобразование данных из внутреннего объекта в формат XML и наоборот.
Рассмотрим, что это дает на практике. База-отправитель ничего не знает о структуре базы-получателя. Она просто выгружает данные, соответствующие схеме XSD. Это позволяет обновлять конфигурации независимо друг от друга, если формат обмена остается неизменным.
Выясним причину отсутствия фундаментальных учебников по КД 3.1, подобных книгам Бояркина по КД 2. Дело в том, что КД 3.1 — это не просто редактор правил, а часть экосистемы Библиотеки стандартных подсистем (БСП). Основная логика обмена заложена в программном коде модулей менеджеров обмена.
Для глубокого изучения рекомендуем использовать следующие ресурсы и подходы:
EnterpriseData. Именно под этим брендом публикуется большинство технических инструкций по работе с универсальным форматом.МенеджерОбменаЧерезУниверсальныйФормат в любой современной конфигурации (например, УТ 11 или БП 3.0). Это лучший способ понять, как реализованы сложные преобразования.Разберем ситуацию, когда в типовом наборе объектов EnterpriseData не хватает полей или целых документов. В этом случае мы не правим основную схему, а используем механизм расширения XDTO. Посмотрим на последовательность действий:
1. Создание расширения XDTO в конфигураторе. Нам необходимо создать новый пакет XDTO. Важно, чтобы его Namespace отличался от стандартного. Обычно добавляют префикс, например: http://www.1c.ru/SSL/Exchange/EnterpriseDataCustom.
2. Наследование свойств. В новом пакете мы можем создавать типы, которые базируются на существующих типах EnterpriseData. Это позволяет добавить новые реквизиты к стандартным объектам, например, к документу «Реализация товаров и услуг».
3. Настройка в КД 3.1. После подготовки схемы в конфигураторе, загрузим её в информационную базу «Конвертация данных 3.1». При настройке маппинга (сопоставления) объектов мы укажем, что система должна использовать нашу расширенную версию формата.
В отличие от КД 2.1, где большая часть логики писалась внутри обработчиков в самой программе КД, в версии 3.1 основной объем работы ложится на Модуль менеджера обмена. Рассмотрим ключевые обработчики, которые нам понадобятся:
ПередВыгрузкойОбъекта: Здесь мы можем программно дополнить данные или отменить выгрузку.ПриВыгрузкеДанных: Используется для заполнения сложных структур, которые не удалось сопоставить в визуальном редакторе.ПослеЗагрузкиОбъекта: Важнейший этап, на котором выполняется проведение документов или установка дополнительных связей в базе-приемнике.Проанализируем пример того, как может выглядеть программное заполнение дополнительного реквизита в модуле менеджера обмена:
Процедура ПКО_Документ_РеализацияТоваровУслуг_ПриВыгрузке(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
// Добавляем значение в расширенное поле формата
Если ДанныеИБ.ДополнительныеРеквизиты.Количество() > 0 Тогда
ДанныеXDTO.Вставить("CustomProperty_MyField", "Значение из базы");
КонецЕсли;
КонецПроцедуры
Если база находится на строгой поддержке, мы можем расширить логику обмена через механизм Расширений конфигурации (.cfe). Разберем этот процесс по шагам:
XDTO.&Вместо или &После для перехвата методов в модуле МенеджерОбменаЧерезУниверсальныйФормат.Такой подход позволяет сохранить конфигурацию «чистой» и минимизировать сложности при последующих обновлениях от фирмы 1С.
Рассмотрим ситуации, когда использование КД 3.1 может быть избыточным. Если перед нами стоит задача разового переноса данных из старой самописной конфигурации, которая не содержит актуальных механизмов БСП, внедрение поддержки EnterpriseData может занять слишком много времени. В таких случаях проще использовать старую добрую КД 2.1 или даже ручное формирование XML через объекты ЗаписьXDTO, как упоминалось в обсуждении.
Однако для настройки регулярного обмена между современными типовыми конфигурациями знание КД 3.1 и механизмов расширения формата является обязательным стандартом для современного разработчика 1С.