Как программно проверить подключение расширения при запуске 1С?

← На главную

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

Выясним причину ошибки: почему не работает РасширенияКонфигурации на старте?

Многие программисты пытаются добавить проверку в стандартные обработчики модуля приложения, такие как ПриНачалеРаботыСистемы или ПередНачаломРаботыСистемы. Однако при попытке обратиться к менеджеру РасширенияКонфигурации система выдает ошибку о том, что переменная не определена. Проанализируем ситуацию.

Дело в том, что объект РасширенияКонфигурации доступен исключительно в контексте сервера. Обработчики начала работы системы выполняются на стороне клиента (в модуле обычного или управляемого приложения). Поскольку в модуле приложения по умолчанию нет серверных вызовов, клиентское приложение просто не "видит" серверный объект работы с расширениями.

Где и как лучше выполнять проверку программно?

Разберем несколько архитектурно правильных мест для размещения логики проверки:

В Модуле сеанса: Это самый ранний этап инициализации платформы, выполняющийся на сервере. В обработчике УстановкаПараметровСеанса можно разместить код проверки. Если проверка не пройдена, мы просто используем ВызватьИсключение "Текст вашей ошибки". Это немедленно прервет запуск, покажет пользователю окно с ошибкой и закроет 1С.
Через общий модуль с признаком «Вызов сервера»: Мы размещаем серверную функцию проверки в таком модуле. Затем на клиенте в обработчике ПередНачаломРаботыСистемы вызываем её. Если сервер возвращает Ложь, мы устанавливаем стандартный параметр Отказ = Истина, и система штатно прекращает запуск.
В конфигурациях на базе БСП (Библиотека стандартных подсистем): Если вы работаете с современной конфигурацией, не рекомендуется вносить изменения напрямую в модуль приложения. БСП использует архитектуру переопределяемых модулей. Для действий при старте системы лучше использовать общие модули, например ОбщегоНазначенияПереопределяемый или ПодсистемыКонфигурацииПереопределяемый.

Способ 1: Проверка через штатные методы платформы

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


// Функция возвращает Истина, если расширение существует, включено и используется.
// Иначе - Ложь
Функция ИспользуетсяРасширение(ИмяРасширения) Экспорт
    
    // Получить само расширение
    МассивРасширений = РасширенияКонфигурации.Получить(Новый Структура("Имя", ИмяРасширения));
    Если МассивРасширений.Количество() <> 1 Тогда
        Возврат Ложь;
    КонецЕсли;
    Расширение = МассивРасширений[0];
    
    // Проверить активность
    Если НЕ Расширение.Активно Тогда
        Возврат Ложь;
    КонецЕсли;
    
    // Проверить возможность применения
    ПроблемыПрименимости = Расширение.ПроверитьВозможностьПрименения();
    Если ПроблемыПрименимости.Количество() > 0 Тогда
        Возврат Ложь;
    КонецЕсли;
    
    Возврат Истина;
КонецФункции

В этом коде мы сначала ищем расширение по его имени с помощью метода Получить. Затем проверяем свойство Активно. Наконец, используем метод ПроверитьВозможностьПрименения(), который анализирует, нет ли конфликтов с основной конфигурацией.

Способ 2: Проверка через "Попытка ... Исключение" (Практичный подход)

Несмотря на то, что метод ПроверитьВозможностьПрименения() выглядит логичным, у него есть подводные камни. Он отлавливает далеко не все проблемы. Например, если в основной конфигурации после обновления удалили или переименовали метод, а расширение все еще пытается его использовать, штатная проверка может не показать проблем. Ошибка проявится только при компиляции в режиме исполнения (runtime).

Посмотрим на альтернативный и очень надежный пример. Разработчики создают в самом расширении общую экспортную процедуру-«заглушку», например МоеРасширение_ПроверкаСвязи(). Затем при запуске системы мы вызываем этот метод.


Попытка
    // Вызов экспортного метода из нашего расширения
    МоеРасширение_ПроверкаСвязи();
    РасширениеРаботает = Истина;
Исключение
    РасширениеРаботает = Ложь;
КонецПопытки;

Если НЕ РасширениеРаботает Тогда
    // Выводим сообщение и прерываем запуск
    Отказ = Истина;
КонецЕсли;

Если вызов прошел успешно — расширение не только подключено, но и его модули успешно компилируются без синтаксических и runtime-ошибок. Этот вариант на практике используется очень часто.

Важные нюансы: Совместимость и Безопасный режим

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

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

← На главную