Как правильно организовать версионирование и запуск обработчиков обновлений для собственных доработок в типовых конфигурациях 1С?

При активной доработке типовых конфигураций 1С (таких как «Управление торговлей», «ERP Управление предприятием» или «Комплексная автоматизация») разработчики часто сталкиваются с необходимостью автоматизировать переход базы данных на новые форматы хранения. В платформе 1С и Библиотеке стандартных подсистем (БСП) для этого предусмотрен механизм обработчиков обновления информационных баз. Однако «из коробки» этот механизм настроен на отслеживание изменений основной версии всей конфигурации поставщика.

Что делать, если мы хотим внедрить собственную систему релизов для наших доработок внутри типового решения, независимо запускать свои обработчики и при этом не нарушать штатную логику обновлений вендора? В этой статье мы подробно разберем, как устроен механизм обновления БСП, проанализируем официальные рекомендации фирмы «1С» и рассмотрим практические сценарии автоматизации этого процесса.

Постановка проблемы: почему БСП не видит изменения «наших» версий?

Подсистема БСП ОбновлениеВерсииИБ запускает процесс обновления метаданных и данных в режиме предприятия только тогда, когда обнаруживает изменение версии конфигурации в метаданных (свойство Метаданные.Версия) по сравнению со значением, сохраненным в информационной базе в регистре сведений ВерсииПодсистем.

Если мы просто добавим свои объекты, напишем для них обработчики обновления в своем общем модуле и попытаемся запустить систему, ничего не произойдет. БСП не узнает, что у нашей подсистемы изменился релиз, так как общая версия конфигурации осталась прежней. Использовать параметр запуска /С ЗапуститьОбновлениеИнформационнойБазы при каждом мелком изменении неудобно и ресурсоемко. Рассмотрим правильные архитектурные подходы к решению этой задачи.

Способ 1. Официальная методика ИТС: разделение конфигурации на основную и библиотеку

Согласно стандартам разработки фирмы «1С», при кастомизации типового решения исходная конфигурация поставщика должна рассматриваться как библиотека со своими собственными номерами версий и обработчиками, а доработанная конфигурация выступает в качестве основной (собственной) конфигурации со своим именем и независимой нумерацией версий.

Разберем этот процесс по шагам на примере интеграции собственного функционала в типовое решение:

1. Создание собственного модуля обновления. Создадим общий модуль, например, ОбновлениеИнформационнойБазыCRM (с установленными свойствами Сервер, Внешнее соединение). В нем мы будем описывать параметры нашей подсистемы и размещать обработчики.
2. Регистрация нашей подсистемы в БСП. Нам необходимо сообщить системе о новой подсистеме. Для этого найдем предопределенный общий модуль ПодсистемыКонфигурацииПереопределяемый и в процедуре ПриДобавленииПодсистем зарегистрируем наш модуль:
   Скопировать код

   
   Процедура ПриДобавленииПодсистем(МодулиПодсистем)
       // Регистрируем типовые модули обновления
       МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыБП");
       // Добавляем ссылку на наш собственный модуль обновления
       МодулиПодсистем.Добавить("ОбновлениеИнформационнойБазыCRM");
   КонецПроцедуры
   

3. Описание свойств нашей подсистемы. В созданном нами модуле ОбновлениеИнформационнойБазыCRM опишем свойства нашей подсистемы, ее версию и укажем явную зависимость от типовой конфигурации. Это делается в процедуре ПриДобавленииПодсистемы:
   Скопировать код

   
   Процедура ПриДобавленииПодсистемы(Описание) Экспорт
       Описание.Имя = "БухгалтерияПредприятия_CRM";
       Описание.Версия = "1.0.1.5"; // Наша собственная сквозная нумерация
       // Указываем зависимость от основной конфигурации поставщика
       Описание.ТребуемыеПодсистемы.Добавить("БухгалтерияПредприятия");
   КонецПроцедуры
   

4. Реализация обработчиков обновления. В этом же модуле мы можем описывать обработчики для перехода с одной версии нашей доработки на другую. БСП автоматически выстроит дерево зависимостей и выполнит нужные процедуры при изменении нашей версии.

При таком подходе при каждом изменении наших доработок, требующем реструктуризации данных, мы просто инкрементируем версию в свойствах метаданных конфигурации и в процедуре ПриДобавленииПодсистемы нашего модуля. БСП сама поймет, что основная конфигурация обновилась, проверит версии зависимых подсистем и запустит только те обработчики, которые соответствуют изменившимся релизам.

Способ 2. Использование механизма Расширений конфигурации (современный стандарт)

В современных реалиях разработки (особенно на крупных внедрениях ERP и КА) изменение имени и версии основной конфигурации в корне метаданных несет определенные риски. Поэтому все чаще доработки вместе с их обработчиками выносятся в расширения конфигурации.

По умолчанию БСП также не умеет автоматически отслеживать изменение версий внутри расширений для запуска процедур обновления данных. Чтобы решить эту проблему программно, разработчики применяют следующий паттерн:

1. Внутри расширения создается собственный общий модуль обновления (например, _ДемоОбновлениеВызовСервера), где регистрируется подсистема расширения.
2. С помощью механизма расширений (используя аннотацию &После или &Вместо) переопределяются служебные функции БСП, отвечающие за проверку необходимости запуска обновления (например, в общем модуле ОбновлениеИнформационнойБазыСлужебный).
3. В переопределяемый код внедряется сравнение текущей версии расширения из метаданных с версией этого расширения, записанной в информационной базе. Если обнаружено расхождение (версия увеличилась), программно инициируется стандартный цикл обновления БСП.

Развенчание мифов: Действительно ли ключ запуска перелопачивает всю базу заново?

Среди разработчиков 1С существует опасение, что принудительный запуск обновления через ключ ЗапуститьОбновлениеИнформационнойБазы или изменение номера версии в метаданных приводит к повторному выполнению всех когда-либо написанных обработчиков обновления (как типовых, так и собственных). Это миф.

Проанализируем, как БСП оптимизирует этот процесс:

• Фиксация выполненных обработчиков. БСП ведет строгий учет всех успешно выполненных процедур обновления в служебных таблицах информационной базы (в регистре сведений ВерсииПодсистем). Если обработчик обновления жестко привязан к конкретной версии (например, переход на версию 1.0.1.2), и эта версия уже была успешно зафиксирована в базе, этот обработчик никогда не запустится повторно.
• Обработчики со звездочкой ("*"). Повторно при старте обновления запускаются только те процедуры, которые в качестве версии имеют маску "*" (так называемые вневерсионные обработчики). По стандартам разработки БСП эти процедуры предназначены исключительно для актуализации оперативного кэша, обновления параметров работы или заполнения новых предопределенных элементов. Они обязаны выполняться быстро и проектироваться так, чтобы многократный запуск не приводил к перезаписи или повреждению пользовательских данных.

Почему же процесс обновления иногда длится долго? Ощутимое время при запуске обновления уходит не на выполнение старых обработчиков, а на актуализацию служебных данных БСП:

1. Обновление справочника Идентификаторы объектов метаданных (особенно в тяжелых конфигурациях типа ERP).
2. Заполнение параметров работы программы и обновление прав доступа (пересчет поставляемых профилей).
3. Обновление структуры метаданных расширений.

Практические советы по оптимизации процесса обновления

Если вы хотите, чтобы ваши обновления проходили максимально быстро и незаметно для пользователей, рекомендуем использовать следующие возможности БСП:

1. Использование отложенных обработчиков обновления. Все тяжелые процедуры, связанные с пересчетом больших массивов данных, заполнением новых реквизитов в существующих документах или регистрах, обязательно делайте отложенными. В этом случае монопольная фаза обновления при запуске системы займет считанные секунды, база сразу станет доступна пользователям, а сами данные будут постепенно обрабатываться регламентными заданиями в фоновом режиме.

2. Включение многопоточного обновления. Начиная с версии БСП 3.1, вы можете существенно ускорить регистрацию данных для отложенных обработчиков. Для этого в общем модуле ОбновлениеИнформационнойБазыПереопределяемый в процедуре ПриОпределенииНастроек включите соответствующий параметр:

Процедура ПриОпределенииНастроек(Настройки) Экспорт
    Настройки.МногопоточноеОбновление = Истина;
КонецПроцедуры

3. Использование инструментов разработчика. При локальной отладке и тестировании обработчиков нет необходимости каждый раз полностью перезапускать конфигурацию с ключом обновления. Используйте внешнюю обработку ОбновлениеВспомогательныхДанных.epf, которая поставляется вместе с дистрибутивом БСП. Она позволяет вручную запустить только нужные вам обработчики обновления или точечно пересчитать идентификаторы измененных объектов метаданных.

Выводы

Организация собственной версионности при доработке типовых конфигураций — признак зрелого и качественного подхода к разработке на платформе 1С. Архитектура БСП предоставляет все необходимые инструменты для бесшовной интеграции ваших релизов с обновлениями вендора.

Выбрав официальную методику разделения конфигурации на основную и библиотеку или используя современные паттерны в расширениях, вы сможете гарантировать стабильность данных ваших клиентов, контролировать процесс обновления и навсегда забудете о ручном запуске тяжелых процедур пересчета информации.