Разработка сложных обменов данными в экосистеме 1С часто ставит специалиста перед выбором между проверенной временем «Конвертацией данных 2.1» (КД 2.1) и современной «Конвертацией данных 3.1» (КД 3.1). Несмотря на то, что КД 3.1 позиционируется как универсальное и прогрессивное решение, на практике программисты сталкиваются с серьезными трудностями при реализации нетиповой бизнес-логики. Проанализируем, почему это происходит и как эффективно использовать этот инструмент в реальных проектах.
Для начала разберем главное архитектурное различие. В КД 2.1 мы привыкли описывать правила напрямую между двумя конкретными базами (источником и приемником). Это подход «Объект к объекту». КД 3.1 реализует совершенно иную концепцию — «Объект к формату». Здесь данные сначала трансформируются в промежуточный формат (обычно EnterpriseData), а затем база-приемник считывает их из этого формата.
Рассмотрим ситуацию: нам нужно передать данные, которых нет в стандартном описании EnterpriseData (ED). Например, кадровые документы из ЗУП в самописную конфигурацию. Поскольку ED изначально проектировался для товарно-денежного учета (торговли), кадровый блок там практически отсутствует. В этот момент разработчик оказывается перед выбором: «костылить» через дополнительные реквизиты или расширять сам формат.
Многие новички пытаются решить нехватку полей в формате через коллекцию AdditionalInfo (ДополнительныеСвойства). На первый взгляд, это кажется удобным: мы просто «набиваем» структуру любыми данными и передаем её. Однако проанализируем последствия такого решения:
Как отмечают эксперты, использование AdditionalInfo — это путь к деградации системы обмена. Если ваша задача выходит за рамки «купли-продажи», нам необходимо использовать механизм расширения XSD-пакетов.
Вместо того чтобы пытаться втиснуть непередаваемое в стандартный формат, мы можем создать собственное расширение XSD. Это позволяет добавить в EnterpriseData любые необходимые объекты: справочники, документы или дополнительные реквизиты существующих объектов. Рассмотрим шаги по реализации этого метода:
EnterpriseData.ДанныеОПриемеНаРаботу.ПКО (Правила конвертации объектов) и ПОД (Правила обработки данных) так же легко, как для типовых документов.Этот подход сохраняет строгость структуры и позволяет избежать «велосипедов» в коде модулей менеджера.
В отличие от КД 2.1, где логика хранится в XML-файле правил и интерпретируется «на лету», КД 3.1 генерирует чистый код на языке 1С, который размещается в модуле менеджера обработки МенеджерОбменаЧерезУниверсальныйФормат. Рассмотрим пример типичной процедуры преобразования данных:
Процедура ПКО_Документ_ПриходныйОрдер_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Здесь мы можем программно заполнить сложные поля формата
Если ДанныеИБ.Склад.ТипСклада = Перечисления.ТипыСкладов.Оптовый Тогда
ДанныеXDTO.СкладТип = "Wholesale";
КонецЕсли;
КонецПроцедуры
Проанализируем преимущества такого подхода: Производительность: Скомпилированный код 1С работает значительно быстрее, чем интерпретатор XML. Версионирование: Модули менеджера легко помещаются в системы контроля версий (Git). Возможности отладки: Мы можем ставить точки останова непосредственно в коде модуля и использовать все возможности конфигуратора для поиска ошибок.
Несмотря на технологичность третьей версии, существуют ситуации, когда старая добрая КД 2.1 будет эффективнее. Выясним причины, по которым разработчики до сих пор возвращаются к ней:
Если вы все же решили использовать КД 3.1 для сложной задачи, придерживайтесь следующих правил:
Во-первых, всегда начинайте с проектирования формата. Не бросайтесь писать код в процедурах ПриОтправкеДанных. Сначала определите, как ваши данные должны выглядеть в XML, и зафиксируйте это в XSD-пакете.
Во-вторых, используйте расширения конфигурации для внедрения модулей менеджера обмена. Это позволит сохранить типовую конфигурацию на поддержке, при этом полностью переопределив логику синхронизации.
В-третьих, если данных очень много и обмен должен быть асинхронным, рассмотрите связку КД 3.1 с 1С:Шиной. Это позволит снять нагрузку с баз данных по маршрутизации сообщений и гарантирует доставку даже при нестабильных каналах связи.
Мы выяснили, что КД 3.1 — это мощный инструмент для создания масштабируемых систем обмена, но он требует высокой квалификации и правильного архитектурного подхода. Для простых или разовых задач КД 2.1 остается более дружелюбным инструментом. Однако для долгосрочных проектов, где планируется подключать множество узлов к единому информационному пространству, КД 3.1 с грамотно спроектированным расширением формата EnterpriseData не имеет альтернатив по гибкости и производительности.