Переход на технологию Конвертации данных 3.0 (КД 3.0) и использование универсального формата обмена EnterpriseData значительно упростили синхронизацию между конфигурациями 1С. Однако разработчики столкнулись с серьезной практической проблемой при обновлении измененных правил обмена. Дело в том, что в КД 3.0 программный код модуля менеджера является генерируемым результатом, а не первичным исходным кодом. Когда мы выгружаем модуль из КД 3.0, все наши ручные комментарии стираются, что делает стандартное сравнение и объединение конфигураций при выходе новых релизов крайне трудоемким процессом.
В этой статье мы подробно разберем, как устроен этот механизм, почему пропадают комментарии и какие практические подходы существуют для безболезненного обновления кастомизированных правил обмена.
Выясним причину этой сложности. В отличие от Конвертации данных 2.1, где правила обмена выгружались в виде XML-файла и интерпретировались в режиме предприятия, в КД 3.0 вся логика компилируется в один большой общий модуль конфигурации — обычно это МенеджерОбменаЧерезУниверсальныйФормат.
Когда мы загружаем правила из КД 3.0 в конфигурацию, генератор полностью перезаписывает текст модуля. При этом любые комментарии, которые разработчики 1С оставили в типовом модуле (или которые вы добавили вручную в конфигураторе), безвозвратно удаляются. В результате при обновлении релиза стандартное сравнение трех модулей (старый типовой, ваш измененный и новый типовой) превращается в рутину из-за колоссального количества ложных различий в структуре кода и отсутствия текстовых ориентиров.
Рассмотрим несколько эффективных методик, которые позволяют обойти это ограничение и выстроить удобный процесс поддержки нетиповых правил обмена.
Проанализируем самый популярный и практичный подход, который активно используется разработчиками крупных систем (например, 1С:ERP или 1С:Комплексная автоматизация). Мы можем полностью изолировать наши доработки от типового модуля, используя механизм расширений.
Идея заключается в том, чтобы создать собственный модуль менеджера обмена в расширении и перенаправить систему на работу с ним, минуя стандартный модуль. Разберем этот процесс по шагам:
Расширение1_МенеджерОбменаЧерезУниверсальныйФормат.ОбменДаннымиУТ (или аналогичном для вашей конфигурации) находим процедуру ДоступныеВерсииУниверсальногоФормата и заимствуем ее в расширение с аннотацией &Вместо.Посмотрим на пример реализации переопределения версий в коде расширения:
&Вместо("ДоступныеВерсииУниверсальногоФормата")
Процедура Расширение1_ДоступныеВерсииУниверсальногоФормата(ВерсииФормата)
// Для старой версии формата оставляем типовой модуль
ВерсииФормата.Вставить("1.2", МенеджерОбменаЧерезУниверсальныйФормат);
// Для актуальных версий перенаправляем логику на наш модуль в расширении
ВерсииФормата.Вставить("1.3", Расширение1_МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.4", Расширение1_МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.5", Расширение1_МенеджерОбменаЧерезУниверсальныйФормат);
ВерсииФормата.Вставить("1.6", Расширение1_МенеджерОбменаЧерезУниверсальныйФормат);
КонецПроцедуры
Как обновлять правила при таком подходе? После выхода очередного обновления от фирмы 1С мы сохраняем новый типовой модуль МенеджерОбменаЧерезУниверсальныйФормат во внешний файл и сравниваем его со старым типовым модулем прошлой версии. Так как оба модуля оригинальные (содержат комментарии и структуру от поставщика), сравнение пройдет быстро и корректно. Все найденные новые типовые механизмы мы просто аккуратно переносим в наш модуль расширения.
Если мы хотим использовать весь потенциал Конвертации данных 3.0 как визуального проектировщика правил, нам необходимо изменить саму парадигму разработки. Главное правило: база КД 3.0 является единственным источником правды. Любые изменения кода в конфигураторе напрямую — это табу.
Рассмотрим правильный цикл обновления правил внутри КД 3.0:
ВыгрузкаМетаданных.epf и загружаем их в КД 3.0.Для сохранения собственных комментариев и кастомного кода внутри КД 3.0 крайне важно использовать справочник "Алгоритмы". Любой текст, написанный в алгоритмах КД 3.0, переносится в результирующий модуль "как есть" вместе с вашими комментариями. При генерации модуля вызовы этих алгоритмов будут встроены в нужные обработчики событий.
Для разработчиков, которые не хотят постоянно работать в КД 3.0, но стремятся минимизировать конфликты обновлений, идеальным решением является точечное переопределение обработчиков событий в расширении с помощью директивы &ИзменениеИКонтроль.
Допустим, нам необходимо кастомизировать заполнение реквизитов при отправке справочника "Номенклатура". Вместо изменения всего модуля или полной замены процедур, мы заимствуем только одну конкретную процедуру обработчика:
&ИзменениеИКонтроль("ПКО_Справочник_Номенклатура_ПриОтправкеДанных")
Процедура Расширение1_ПКО_Справочник_Номенклатура_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Наш кастомный код вставляется в специальный блок
#Вставка
Если ДанныеИБ.ЭтоУслуга Тогда
ДанныеXDTO.Вставить("ТипНоменклатуры", "Услуга");
КонецЕсли;
#КонецВставки
// Типовой код остается под контролем платформы
// ... типовой код ...
КонецПроцедуры
При таком подходе платформа 1С автоматически контролирует целостность кода во время обновления конфигурации. Если 1С изменит логику процедуры ПКО_Справочник_Номенклатура_ПриОтправкеДанных в новом релизе, расширение выдаст ошибку применимости. Это будет четким сигналом для разработчика, что нужно зайти в процедуру и адаптировать доработку под новые типовые алгоритмы. Это в разы надежнее ручной сверки сотен тысяч строк кода модуля обмена.
Зачастую доработка правил обмена требуется лишь для того, чтобы передать несколько специфических реквизитов, которых по умолчанию нет в XDTO-пакете EnterpriseData. Чтобы не модифицировать структуру XSD-схем и не перегенерировать правила в КД 3.0, мы можем использовать встроенное свойство AdditionalInfo (Дополнительные сведения).
Практически каждый объект формата EnterpriseData имеет узел AdditionalInfo, представляющий собой структуру. Мы можем заполнить его произвольными данными в обработчике отправки прямо из расширения, а на стороне приемника прочитать эти данные в обработчике получения:
// На стороне источника в расширении
СтруктураДопСведений = Новый Структура;
СтруктураДопСведений.Вставить("РегионПродаж", ДанныеИБ.Регион);
// Сериализуем и помещаем в AdditionalInfo
ДанныеXDTO.AdditionalInfo = ВыгрузитьВXDTOДопСведения(СтруктураДопСведений);
Этот изящный способ позволяет передавать любые кастомные реквизиты без изменения структуры правил обмена и редактирования модуля менеджера в КД 3.0, что сводит сложность будущих обновлений к нулю.
Мы проанализировали различные варианты работы с измененными правилами обмена в Конвертации данных 3.0. Выбор конкретного метода зависит от масштаба ваших доработок:
&ИзменениеИКонтроль или переопределяйте модуль обмена целиком через подмену версий формата, сравнивая оригинальные файлы поставщика напрямую.