В типовой практике разработки на платформе 1С:Предприятие расширения конфигурации (файлы *.cfe) часто используются для быстрой адаптации решений. Однако при использовании тиражных расширений от сторонних разработчиков или вендоров возникает серьезная сложность: механизм поддержки с правилами поставщика и трехсторонним объединением («конфигурация поставщика — старая конфигурация с доработками — новая конфигурация поставщика») в платформе реализован исключительно для основных конфигураций (файлы *.cf и *.cfu).
Если в расширение поставщика были внесены кастомные доработки, а затем вендор выпустил новую версию, просто накатить обновление поверх файла нельзя: затираются изменения, а при полной перезагрузке можно безвозвратно потерять данные собственных добавленных объектов. Выясним причину этой проблемы и подробно разберем несколько проверенных способов выполнения обновления.
Прежде чем приступать к слиянию версий, проанализируем внутреннее устройство расширений. Если в доработанном расширении созданы собственные хранимые объекты (справочники, документы, регистры сведений) или добавлены реквизиты к заимствованным объектам, платформа создает для них физические таблицы в СУБД. Сопоставление этих структур происходит строго по внутренним идентификаторам (UUID).
Если выполнить команду Загрузить конфигурацию из файла вместо операции объединения или пересоздать расширение с нуля, платформа воспримет это как удаление старых объектов метаданных и создание абсолютно новых. В результате физические таблицы с данными в базе будут безвозвратно очищены. Поэтому любые манипуляции следует выполнять либо через штатное объединение, либо через контролируемое текстовое слияние исходников с сохранением исходных UUID.
Рассмотрим наиболее популярный и быстрый способ, основанный на выгрузке расширений в файлы и выполнении трехстороннего слияния во внешней утилите. Для этого нам понадобятся три исходных состояния конфигурации:
Выгрузим каждое из трех расширений в файлы XML через конфигуратор (команда Конфигурация — Выгрузить конфигурацию в файлы... в контексте нужного расширения) в соответствующие каталоги. Далее воспользуемся утилитой KDiff3, которая умеет выполнять слияние каталогов в пакетном режиме.
Посмотрим на пример командного файла (bat-скрипта), автоматизирующего вызов утилиты для выполнения слияния:
@echo off
echo Starting three-way merge of extensions...
set BASE=C:\TEMP\Merge\Base
set CHANGES=C:\TEMP\Merge\Changes
set BASE2=C:\TEMP\Merge\Base2
set RESULT=C:\TEMP\Merge\Result
if not exist "%BASE%" (
echo Error: Base folder not found: %BASE%
pause
exit /b 1
)
if not exist "%CHANGES%" (
echo Error: Changes folder not found: %CHANGES%
pause
exit /b 1
)
if not exist "%BASE2%" (
echo Error: Base2 folder not found: %BASE2%
pause
exit /b 1
)
if not exist "%RESULT%" mkdir "%RESULT%"
echo Merging folders:
echo Base : %BASE%
echo Changes: %CHANGES%
echo Base2 : %BASE2%
echo Result : %RESULT%
"C:\Program Files\KDiff3\kdiff3.exe" --merge --auto "%BASE%" "%CHANGES%" "%BASE2%" -o "%RESULT%"
echo.
echo Merge completed. Check the Result folder.
pause
Разберем важные нюансы этого подхода:
KDiff3 рекомендуется отключить избыточные подтверждения автоматического слияния, а также настроить игнорирование пробельных символов и переводов строк.Result.Result загружаем обратно в расширение базы через команду Конфигурация — Загрузить конфигурацию из файлов... на копии информационной базы для тестирования.Если проект требует строгого использования платформенного окна сравнения и объединения 1С, применим обходной путь через временную конвертацию расширения в полноценную конфигурацию. Это позволит поставить расширение на стандартную поддержку поставщика.
Разберем по шагам последовательность действий:
cfe поставщика версии 1.20 и конвертируем его структуру в формат cf. Выполнить это можно с помощью специализированных конвертеров или путем выгрузки в исходные XML-файлы с корректировкой корневого файла Configuration.xml.cf в чистую базу. Создаем файл поставки (Конфигурация — Поставка конфигурации — Создать файлы поставки...). На выходе получаем файл поставщика.cf старого поставщика (версия 1.20). Конфигурация встает на полную поддержку с замком.Configuration.xml к виду расширения и загружаем обратно в целевую базу в качестве обновленного cfe.Если команда использует версионирование исходных кодов в Git или среду разработки 1C:Enterprise Development Tools (1C:EDT), задача обновления решается архитектурно с помощью так называемой «ветки поставщика» (Vendor Branch):
vendor, в которую последовательно коммитятся только чистые версии расширения от разработчика (сначала 1.20, затем 1.21) в виде выгруженных XML-исходников.vendor фиксируется новый коммит с чистыми исходниками 1.21.git merge vendor.Если объем доработок невелик, а внешние утилиты использовать нельзя, воспользуемся штатным сравнением конфигураций в одном конфигураторе без создания лишних баз:
cfe 1.20 и чистый cfe 1.21, чтобы четко видеть, какие именно методы переписал поставщик, и перенести только собственные изменения.Проанализируем опыт разработчиков: постоянное ручное или полуавтоматическое обновление измененного вендорского расширения требует существенных трудозатрат, особенно если вендор выпускает релизы часто. Чтобы упростить сопровождение, рекомендуется применить следующие архитектурные подходы:
cfe, но и в виде подсистемы (файла cf), интеграция в основную конфигурацию второй конфигурацией поставщика обеспечит штатную трехстороннюю поддержку средствами платформы «из коробки».