← На главную

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

Главное концептуальное отличие: схема «Многие-ко-многим»

Главный недостаток КД 2 заключается в том, что правила конвертации связывают две конкретные базы напрямую: источник и приемник. Если у нас есть три разные информационные базы (например, Управление торговлей, Бухгалтерия предприятия и Зарплата и управление персоналом), то для всестороннего обмена между ними в КД 2 потребуется создать и постоянно поддерживать 6 независимых комплектов правил.

Проанализируем, как эта задача решается в КД 3:

1. Обмен строится не между конкретными конфигурациями, а через единый универсальный формат обмена — EnterpriseData (ED).
2. Для каждой конфигурации создается только один комплект правил: правила выгрузки из этой конфигурации в формат EnterpriseData и правила загрузки из формата в эту же конфигурацию.
3. Для связи трех баз в КД 3 достаточно описать всего 3 комплекта правил (по одному на каждую конфигурацию) вместо 6 в КД 2. При добавлении четвертой базы мы просто создаем для нее один комплект правил, и она сразу начинает обмениваться со всеми остальными.

Использование BSL-кода вместо XML-интерпретатора

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

В КД 3 результат работы — это не XML-схема с правилами, а готовый программный код на языке 1С (BSL). Инструмент выгружает код модуля менеджера обмена, который встраивается в конфигурацию (или подключается как внешняя обработка/расширение) и исполняется средствами Библиотеки Стандартных Подсистем (БСП).

Разберем основные плюсы такого подхода:

1. Полноценная отладка в Конфигураторе: Разработчик может устанавливать стандартные точки останова прямо в BSL-коде модуля обмена и пошагово отслеживать выгрузку и загрузку данных.
2. Высокая скорость работы: Исполнение чистого BSL-кода происходит быстрее интерпретации XML-структур.
3. Возможность точечной доработки: Корректировки в правила можно вносить прямо в конфигураторе 1С через модуль обмена или расширение, без обязательного открытия конфигурации «Конвертация данных 3.0».

Основные сущности и архитектура правил в КД 3

Разберем, из каких основных элементов состоят правила обмена в КД 3:

1. ПОД (Правила обработки данных): Определяют выборку объектов метаданных 1С при отправке или выборку элементов формата при загрузке.
2. ПКО (Правила конвертации объектов): Описывают сопоставление реквизитов конкретного объекта конфигурации (например, справочника Контрагенты) и сущности формата EnterpriseData.
3. ПКПД (Правила конвертации предопределенных данных): Отвечают за сопоставление перечислений и предопределенных элементов справочников.

Идентификация и поиск объектов при загрузке выполняются через Варианты идентификации (по уникальному идентификатору GUID или по комбинации ключевых полей поиска, таких как ИНН/КПП или Код/Наименование). При успешном поиске по полям GUID объекта в базе-приемнике обновляется для упрощения последующих синхронизаций.

Специфика работы с нетиповыми реквизитами и регистрами

Выясним особенности работы с нестандартными данными в формате EnterpriseData:

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

Когда выбираем КД 2, а когда КД 3?

Проанализируем критерии выбора инструмента для конкретной задачи:

Выбирайте КД 3, если:

• Обмен настраивается между типовыми конфигурациями на базе БСП, поддерживающими формат EnterpriseData (БП 3.0, УТ 11, ERP, ЗУП 3 и др.).
• Планируется объединить в единую сеть обмена три и более информационные базы.
• Требуется стандартная синхронизация бизнес-данных (НСИ, документы) с минимальными трудозатратами на сопровождение при обновлениях.

Выбирайте КД 2, если:

• Необходимо настроить разовый или узкоспециализированный обмен между двумя сильно доработанными или устаревшими конфигурациями (например, УПП 1.3 или решения на платформах 7.7 / 8.2 без БСП).
• Требуется передавать напрямую наборы записей регистров или специфические технические данные без проведения документов.
• Идет работа с конфигурациями, в которых отсутствует поддержка XDTO и подсистемы обмена данными БСП.