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