← На главную

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

Концептуальное отличие: «Прямой обмен» против «Универсального формата»

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

1. Подход Конвертации данных 2.0 (Прямой маппинг): правила обмена связывают структуру базы-источника напрямую со структурой базы-приемника. Формируется единый файл правил, содержащий инструкции по выгрузке объектов конкретной конфигурации А в конкретную конфигурацию Б. Если в обмене участвует 5 различных конфигураций, для каждой пары приходится создавать и сопровождать отдельные правила обмена (N * (N - 1) связей).
2. Подход Конвертации данных 3.0 (Формат-посредник): обмен строится вокруг единого стандартизированного формата данных (канонической модели EnterpriseData на базе XDTO). Каждая конфигурация знает только то, как выгрузить свои объекты в формат XDTO и как из формата XDTO загрузить данные в свои объекты. Конфигурация А ничего не знает о структуре конфигурации Б, они общаются через единый стандартизированный протокол.

Рассмотрим понятную аналогию с логистикой: в КД 2.0 отправитель упаковывает груз и прикладывает подробную инструкцию, в какую конкретно ячейку на складе получателя положить каждую вещь. В КД 3.0 отправитель раскладывает вещи по стандартным отсекам единого контейнера. Получатель сам открывает стандартный контейнер и раскладывает вещи по своему складу согласно своим внутренним правилам.

Главное практическое преимущество КД 3.0

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

1. Настроена регулярная синхронизация между 1С:Управление торговлей 11 и 1С:Бухгалтерия предприятия 3.0.
2. База бухгалтерии обновляется еженедельно под изменения законодательства и форм отчетности, а база торговли дорабатывалась программистами и обновляется редко (например, раз в год).
3. В КД 2.0: при изменении структуры метаданных в очередном релизе бухгалтерии правила обмена ломаются, что требует срочной доработки правил или обновления обеих конфигураций до строго совместимых версий.
4. В КД 3.0: обе базы ориентируются на фиксированную версию формата EnterpriseData. Обновление конфигурации-приемника не ломает схему входящих данных, и обмен продолжает стабильно функционировать без вмешательства разработчика.

Архитектурные особенности и генерация кода

Выясним, как технически выполняются правила в КД 3.0:

1. Компиляция в программный код: в отличие от КД 2.0, где файл правил выгружался в XML и интерпретировался универсальной обработкой «на лету», в КД 3.0 правила компилируются непосредственно в программный код на встроенном языке 1С.
2. Модули менеджера обмена: сгенерированный код размещается в модуле менеджера обмена через универсальный формат (или общих модулях конфигурации). Это обеспечивает максимальное быстродействие выполнения алгоритмов.
3. Изоляция этапов: процесс конвертации строго разделен на два независимых шага — конвертация объекта ИБ в объект XDTO (сторона источника) и конвертация объекта XDTO в объект ИБ (сторона приемника).

Идентификация и поиск объектов (ПКИ)

Посмотрим, как настраивается поиск и сопоставление элементов в базе-приемнике. Для этого в КД 3.0 используются Правила конвертации идентификации (ПКИ).

ПКИ поддерживают гибкую многоуровневую логику поиска:

1. Поиск по уникальному идентификатору (GUID): приоритетный способ при регулярной синхронизации между базами.
2. Поиск по полям идентификации: если объект по GUID не найден, выполняется сопоставление по ключевым реквизитам (например, для справочника Контрагенты — по полям ИНН и КПП, для Номенклатура — по артикулу или штрихкоду).
3. Программные алгоритмы: возможность переопределить логику поиска через код обработчиков событий в правилах идентификации.

Доработка обмена без снятия конфигурации с поддержки

Разберем способы кастомизации правил обмена в типовых конфигурациях:

1. Использование механизма расширений: модуль менеджера обмена можно дорабатывать в расширении конфигурации с помощью аннотаций &ИзменитьИКонтролировать, &Вместо или &После, не снимая основную конфигурацию с поддержки.
2. Использование свойства «ДополнительныеРеквизиты»: большинство объектов формата EnterpriseData содержат встроенную коллекцию ДополнительныеРеквизиты (структура вида «Свойство — Значение»). Если требуется передать кастомное поле без изменения XSD-схемы пакета, его можно упаковать в данную коллекцию на стороне источника и прочитать на стороне приемника.
3. Расширение XSD-схемы: при необходимости передачи совершенно новых сущностей (например, нетипового документа) создается собственный XDTO-пакет расширения формата, который подключается к модулям обмена.

Отладка и диагностика правил

Так как правила КД 3.0 представляют собой штатный код конфигурации на встроенном языке 1С, процесс отладки значительно упрощается:

1. Для поиска ошибок не требуются внешние отладчики правил. Достаточно установить точку останова в модуле менеджера обмена через стандартный конфигуратор.
2. Тестирование выгрузки или загрузки конкретного объекта можно выполнять точечно вызовом процедур модуля менеджера обмена через внешнюю обработку или консоль кода, без необходимости запускать полный сеанс фонового обмена.

Когда использовать КД 2.0, а когда КД 3.0?

Сформулируем критерии выбора инструмента под конкретную задачу:

1. Конвертацию данных 3.0 (EnterpriseData) выбираем: для постоянного, регулярного обмена между типовыми и нетиповыми конфигурациями (особенно при разном графике их обновления), а также для интеграции 1С со сторонними системами (веб-сервисы, мобильные приложения, сайты), умеющими работать с форматом XML/JSON по XSD-схеме.
2. Конвертацию данных 2.0 выбираем: для разовых переносов данных, исторических остатков, миграции при переходе с устаревших конфигураций (например, 1С:Предприятие 7.7 или обычных форм 8.2), а также для прямого переноса сильно кастомизированных сложных структур между двумя базами с идентичной конфигурацией.