Какую версию Конвертации данных выбрать: КД 2 или КД 3?

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

Архитектурные различия: Правила против Формата

Для начала проанализируем фундаментальную разницу в подходах. КД 2 реализует модель «Точка-Точка». Это означает, что для обмена между двумя конфигурациями мы создаем уникальный набор правил. Если конфигураций становится три, количество наборов правил растет в геометрической прогрессии. Рассмотрим особенности КД 2:

• Прямое сопоставление объектов: Мы жестко связываем СправочникСсылка.Номенклатура источника с аналогичным объектом приемника.
• Использование XML: Все данные выгружаются в файл по заранее определенной структуре правил.
• Гибкость кода: Мы можем писать произвольные обработчики на языке 1С практически на любом этапе выгрузки или загрузки.

КД 3 работает иначе, используя концепцию «Шины» или «Канонического формата». Здесь источником и приемником выступает не конкретная база, а формат EnterpriseData (на базе XDTO). Разберем преимущества этого подхода:

• Универсальность: Вы настраиваете правила выгрузки в формат один раз. Любая другая база, понимающая EnterpriseData, сможет принять эти данные без написания отдельных правил именно для вашей конфигурации.
• Независимость: Обновление метаданных в одной базе не ломает обмен с десятью другими, если формат сообщения остался прежним.
• Работа в сервисах: КД 3 гораздо лучше адаптирована для работы в модели SaaS (облачные сервисы), где доступ к файловой системе ограничен, а обмены идут через Web-сервисы.

Проблемы КД 3 и способы их решения

Многие разработчики отмечают, что настройка КД 3 занимает значительно больше времени. Основная претензия — необходимость постоянно корректировать XDTO-пакеты и работать с кодом правил внутри самих конфигураций, а не в отдельном удобном интерфейсе. Выясним, как упростить этот процесс.

Одной из главных «болей» является передача данных, которые не предусмотрены стандартным форматом EnterpriseData. Для этого в КД 3 предусмотрен механизм AdditionalInfo (Дополнительные сведения). Рассмотрим пример, как можно передать произвольные данные через этот узел:

// Пример заполнения дополнительных данных в обработчике КД 3
// В структуре "ДанныеДляВыгрузки" подготовим информацию, 
// которая не помещается в стандартные поля XDTO

ДополнительныеСвойства = Новый Структура;
ДополнительныеСвойства.Вставить("СпецифическийПараметрЛогистики", Источник.ПараметрЛогистики);
ДополнительныеСвойства.Вставить("ВнутреннийКодДоступа", Источник.КодДоступа);

// Помещаем структуру в специальный узел формата
КомпонентыОбмена.ДополнительныеСведения = ДополнительныеСвойства;

Использование AdditionalInfo позволяет избежать трудоемкого процесса расширения XDTO-схемы на каждом этапе, хотя и требует дисциплины при обработке этих данных на стороне приемника.

Эволюция: Что принесет Конвертация данных 3.1?

Многие критические замечания к КД 3 были услышаны разработчиками платформы. В версии 3.1 архитектура хранения данных претерпела значительные изменения. Проанализируем ключевые нововведения:

1. Ссылочные реквизиты метаданных: В отличие от КД 2 и КД 3.0, где описания метаданных хранились в виде строк, в 3.1 это полноценные ссылки. Это позволяет выполнять проверку целостности правил «на лету» и использовать стандартные механизмы поиска ссылок.
2. Интеграция с Git и EDT: Теперь описание конфигураций можно загружать напрямую из веток Git-репозитория. Это кардинально меняет процесс совместной разработки правил, делая его прозрачным и исключая потерю кода при одновременном редактировании.
3. Автоматизация загрузки описаний: Реализована возможность настройки регламентных заданий для автоматического обновления метаданных из внешних источников (файлы xml или проекты EDT).
4. Единое окно разработки: Попытка объединить разработку правил XML (как в КД 2) и правил для EnterpriseData (как в КД 3) в рамках одной информационной базы.

Сравнение производительности

Рассмотрим вопрос производительности при больших объемах данных. В КД 2 выгрузка часто идет «одним куском». Если у вас 500 000 элементов справочника, система может столкнуться с нехваткой оперативной памяти при формировании гигантского XML-файла.

В КД 3 обмен по формату EnterpriseData изначально проектировался как пообъектный. Сообщения передаются небольшими порциями (пакетами). Проанализируем ситуацию: если в процессе передачи 99-го пакета из 100 произошел сбой, в КД 3 вам не придется перегружать все данные заново — система зафиксирует успешно принятые объекты и дошлет только недостающие. Это делает обмены более отказоустойчивыми.

Выводы: Что выбрать сегодня?

Выясним итоговые рекомендации по выбору инструмента в зависимости от ваших задач:

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

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

Выбирайте КД 3.0 / 3.1, если:

• Вы строите сложную систему из множества баз (например, ERP, УТ, БП и несколько узлов РИБ).
• Ваши конфигурации — современные типовые решения 1С, где уже внедрен формат EnterpriseData.
• Требуется обеспечить стабильную работу в облачных сервисах или через 1С:Шину.
• Вы планируете использовать современные DevOps-практики и контроль версий (Git).

Рассмотрев все аспекты, можно сказать, что КД 3 — это инвестиция в будущее сопровождение системы. Несмотря на высокий порог входа и «неудобство» начальной настройки, она обеспечивает масштабируемость. В то же время КД 3.1 обещает стать тем самым «идеальным» инструментом, который заберет лучшее от обеих версий, предоставляя разработчику и мощь визуального проектирования, и строгость ссылочной целостности.