При переходе с технологии Конвертации данных 2.0 (КД2) на Конвертацию данных 3.0 (КД3) многие разработчики сталкиваются с концептуальными трудностями. Основное отличие заключается в том, что КД3 базируется на технологии EnterpriseData (ED) — универсальном формате обмена, основанном на XDTO. В этой статье мы подробно разберем, как правильно включить новый документ в план обмена, нужно ли для этого менять XDTO-пакет и как минимизировать сложности при последующих обновлениях конфигурации.
Для начала проанализируем фундаментальное различие систем. В КД2 правила описывали жесткую связь: Объект Источника → Объект Приемника. В КД3 реализуется трехзвенная концепция: Объект Источника → Универсальный формат (XDTO) → Объект Приемника.
Это означает, что база-источник ничего не знает о структуре базы-приемника. Она лишь «выстреливает» данными в формате XML, соответствующем схеме XDTO, а приемник должен уметь этот XML прочитать и интерпретировать. Рассмотрим, что из этого следует при решении задачи добавления нового документа.
Если в вашей конфигурации появился новый документ (например, специфическая «Внутренняя заявка»), который по смыслу и структуре полей очень похож на типовой объект (например, «Заказ покупателя»), существующий в формате EnterpriseData, вам не нужно менять XDTO-пакет. Это самый простой и предпочтительный путь.
В этом случае алгоритм действий будет следующим:
МенеджерОбменаЧерезУниверсальныйФормат описываются правила выгрузки вашего документа в существующий тип XDTO-объекта.Разберем ситуацию на примере. Выясним причину, почему это удобно: вы не нарушаете «универсальность» формата, и другие базы, участвующие в обмене, продолжат работать со стандартным пакетом без ошибок.
Если же ваш новый документ принципиально отличается от того, что заложено в EnterpriseData, придется расширять формат. Рассмотрим подробнее, как это сделать правильно, чтобы не «мучиться с обновлениями», как было замечено в обсуждении.
Важный нюанс: Напрямую менять типовой XDTO-пакет EnterpriseData в конфигурации крайне не рекомендуется. Вместо этого следует использовать механизм расширений (.cfe).
Рассмотрим шаги по реализации этого подхода:
Такой подход позволяет сохранить основную конфигурацию на поддержке. Однако помните: если вы изменили формат (даже через расширение), эти изменения должны быть продублированы во всех базах, которые должны понимать этот новый объект. В противном случае приемник просто проигнорирует неизвестный ему узел XML.
В КД3 вся логика конвертации сосредоточена в общем модуле МенеджерОбменаЧерезУниверсальныйФормат. В отличие от КД2, здесь нет огромных XML-файлов правил, всё описывается кодом на языке 1С. Для добавления нового документа нам понадобятся два ключевых понятия: ПОД (Правила Обработки Данных) и ПКО (Правила Конвертации Объектов).
Проанализируем, за что отвечает каждый элемент:
Пример структуры процедур в менеджере обмена для отправки данных:
Процедура ПКО_Документ_ВашНовыйДокумент_Отправка(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена, СтекВыгрузки)
// Заполнение реквизитов из базы в формат XDTO
ДанныеXDTO.Номер = ДанныеИБ.Номер;
ДанныеXDTO.Дата = ДанныеИБ.Дата;
// Сложная логика заполнения
ЗаполнитьРеквизитыКонтрагента(ДанныеXDTO, ДанныеИБ.Контрагент);
КонецПроцедуры
А вот пример для получения данных на стороне приемника:
Процедура ПКО_Документ_ВашНовыйДокумент_Получение(ДанныеXDTO, ДанныеИБ, КомпонентыОбмена, СтекЗагрузки)
// Сопоставление данных из XML с объектом базы данных
ДанныеИБ.Комментарий = "Загружено из обмена: " + ДанныеXDTO.ДополнительнаяИнформация;
КонецПроцедуры
Существует «легальный» способ передать несколько кастомных полей, не меняя структуру XDTO-пакета и не создавая расширений. В большинстве объектов EnterpriseData предусмотрена коллекция ДополнительныеРеквизиты (тип «Ключ-Значение»).
Посмотрим, как это можно использовать на практике:
ПКО_..._Отправка вы упаковываете свои данные в эту коллекцию.ПКО_..._Получение вы извлекаете их по ключу и записываете в нужные реквизиты объекта или дополнительные сведения.Это позволяет сохранить формат абсолютно универсальным и избежать необходимости обновлять XDTO-пакеты в других базах.
Важно помнить про версионирование формата. При настройке обмена базы «договариваются» об использовании определенной версии (например, 1.3 или 1.15). Если вы реализовали поддержку нового документа в версии 1.15, а база-приемник настроена на работу с версией 1.10, ваши данные не будут загружены. Всегда проверяйте совместимость версий в настройках синхронизации.
Для отладки процесса используйте инструменты из состава БСП (Библиотеки стандартных подсистем). В КД3 можно включить режим отладки непосредственно в модуле менеджера обмена. Это позволяет ставить точки останова и пошагово проходить код формирования XML-сообщения прямо в конфигураторе 1С, что является огромным преимуществом по сравнению с КД2.
Подведем итог нашего анализа. Если вы добавляете новый документ в КД3:
ДополнительныеРеквизиты.МенеджерОбменаЧерезУниверсальныйФормат, используя ПОД и ПКО.Такой подход обеспечит стабильность обмена и упростит поддержку системы в будущем.