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