При разработке расширений часто возникает задача инициализации данных: заполнение регистров сведений, создание предопределенных элементов или установка значений констант сразу после того, как расширение было подключено к базе. В типовых конфигурациях на платформе 1С, использующих Библиотеку Стандартных Подсистем (БСП), существуют штатные механизмы для этих целей. Однако начинающие разработчики часто пытаются использовать «костыльные» методы, такие как подписки на запись внутренних регистров конфигурации или ручной контроль версий. В этой статье мы подробно разберем, как правильно организовать первоначальное заполнение данных, используя как возможности БСП, так и базовые механизмы платформы.
Это самый правильный и надежный путь для конфигураций, основанных на БСП. Суть метода заключается в том, что расширение регистрируется в системе как отдельная подсистема со своей версией. Рассмотрим этот процесс по шагам.
Во-первых, нам необходимо создать в расширении общий модуль, который будет отвечать за логику обновления. Назовем его, например, ОбновлениеИнформационнойБазы[ИмяВашегоРасширения]. В свойствах модуля обязательно должны быть установлены флажки «Сервер» и «Вызов сервера».
Разберем, какой код должен содержать этот модуль. Основная задача — описать процедуру добавления обработчиков обновления для создания, например, предопределенных настроек. Рассмотрим пример кода:
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
Обработчик = Обработчики.Добавить();
Обработчик.Версия = "1.0.0.1"; // Версия, при которой должен сработать код
Обработчик.Процедура = "ОбновлениеИнформационнойБазы[ИмяРасширения].ЗаполнитьНачальныеДанные";
Обработчик.НачальноеЗаполнение = Истина;
КонецПроцедуры
Процедура ЗаполнитьНачальныеДанные() Экспорт
// Здесь описываем логику заполнения Регистров Сведений
Запись = РегистрыСведений.НастройкиВашегоРасширения.СоздатьМенеджерЗаписи();
Запись.Параметр = "ПервыйЗапуск";
Запись.Значение = Истина;
Запись.Записать();
КонецПроцедуры
Чтобы БСП узнала о существовании нашего расширения и вызвала эти процедуры, необходимо «зацепиться» за основной цикл обновления конфигурации. Для этого используется переопределяемый модуль ПодсистемыКонфигурацииПереопределяемый. В нем мы находим процедуру ПриДобавленииПодсистем и добавляем наше расширение в общий список, что позволяет создавать полноценные подсистемы с собственными командами и API.
Проанализируем ситуацию: когда вы впервые подключаете расширение, БСП видит, что версия этой «виртуальной» подсистемы в базе данных равна 0.0.0.0. Сравнивая её с текущей версией расширения в метаданных, система понимает, что требуется запуск обработчиков с признаком НачальноеЗаполнение = Истина.
Если ваша конфигурация не использует БСП или вы хотите реализовать более простой механизм, можно применить паттерн «Сравнение версий». Этот метод основан на проверке актуальности данных при каждом входе пользователя в систему.
Выясним причину, почему это удобно: вам не нужно глубоко интегрироваться в логику обновления БСП, достаточно контролировать одну константу или запись в регистре. Разберем реализацию по шагам:
ВерсияДанныхРасширения (тип Строка).ПриНачалеРаботыСистемы.Пример программного кода для реализации этой логики:
Процедура ПриНачалеРаботыСистемы()
ТекущаяВерсия = Метаданные.Версия;
ВерсияВБазе = Константы.ВерсияДанныхРасширения.Получить();
Если ТекущаяВерсия <> ВерсияВБазе Тогда
ВыполнитьИнициализациюДанных();
Константы.ВерсияДанныхРасширения.Установить(ТекущаяВерсия);
КонецЕсли;
КонецПроцедуры
Важный нюанс: Чтобы не замедлять вход каждого пользователя, проверку лучше обернуть в использование Параметров сеанса. При первом запуске мы кэшируем результат проверки в параметр сеанса, и для всех последующих обращений в рамках этого сеанса проверка будет проходить мгновенно в памяти, без обращения к базе данных.
Если процедура заполнения данных предполагает обработку большого массива информации (например, пересчет итогов или заполнение огромного регистра сведений из внешнего файла), крайне не рекомендуется выполнять этот код в основном потоке при запуске. Это приведет к тому, что пользователь будет видеть «песочные часы» в течение долгого времени.
Рассмотрим подробнее использование объекта ФоновоеЗадание. Мы можем инициировать запуск фонового задания сразу после определения того, что расширение установлено впервые. Это позволит пользователю начать работу с интерфейсом, пока данные подготавливаются в фоновом режиме.
Посмотрим на пример инициализации фонового процесса:
Процедура ЗапуститьФоновоеЗаполнение() Экспорт
ПараметрыПроцедуры = Новый Структура;
ФоновыеЗадания.Выполнить("МойОбщийМодуль.ДлительнаяОперацияЗаполнения", ПараметрыПроцедуры);
КонецПроцедуры
При использовании этого метода важно предусмотреть в интерфейсе блокировку определенных действий пользователя до момента завершения фонового задания, если эти действия зависят от заполняемых данных.
Проанализируем технические ограничения платформы 1С. Важно понимать, что на уровне встроенного языка не существует события OnExtensionInstall. Платформа просто «накладывает» метаданные расширения на основную конфигурацию. Поэтому программное управление расширениями через объект МенеджерКонфигурацииИзИнформационнойБазы — это единственный способ поймать момент установки, если она происходит программно (например, через внешнюю обработку управления расширениями).
Также обратим внимание на Безопасный режим. Если при добавлении расширения установлен флаг «Безопасный режим», расширение будет ограничено в правах. Оно может не иметь доступа к файловой системе или определенным методам БСП. Для корректной работы обработчиков обновления и записи в регистры часто требуется либо снять этот флаг, либо детально настроить профиль безопасности в кластере серверов 1С.
Подводя итог, мы можем выделить следующие рекомендации для разработчика:
ВерсииРасширений — это «хрупкое» решение, которое может перестать работать при обновлении платформы или БСП.Применяя эти подходы, вы обеспечите стабильную и быструю работу вашего расширения, а также упростите процесс его дальнейшей поддержки и обновления.