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

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Программная реализация оповещения пользователей

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

Разберем по шагам, как настроить периодическую проверку и информирование пользователя:

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

Посмотрим на пример реализации в модуле управляемого приложения:


// В модуле управляемого приложения

Процедура ПриНачалеРаботыСистемы()
    // Подключаем периодическую проверку каждые 120 секунд (2 минуты)
    ПодключитьОбработчикОжидания("ПроверитьДинамическоеОбновление", 120);
КонецПроцедуры

Процедура ПроверитьДинамическоеОбновление() Экспорт
    Если КонфигурацияБазыДанныхИзмененаДинамически() Тогда
        // Отключаем повторные срабатывания обработчика
        ОтключитьОбработчикОжидания("ПроверитьДинамическоеОбновление");
        
        ТекстСообщения = "Конфигурация базы данных была обновлена. "
            + "Для корректной работы рекомендуется перезапустить программу.";
            
        ПоказатьОповещениеПользователя(
            "Внимание! Обновление конфигурации",
            ,
            ТекстСообщения,
            БиблиотекаКартинок.Предупреждение
        );
    КонецЕсли;
КонецПроцедуры

Если требуется предоставить пользователю возможность перезагрузить программу в один клик, можно вызвать стандартный метод завершения работы с флагом перезапуска:


// Второй параметр "Истина" указывает платформе на необходимость перезапуска сеанса
ЗавершитьРаботуСистемы(Ложь, Истина);

Ограничения динамического обновления

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

Что можно обновлять динамически:

  1. Тексты модулей (общих модулей, модулей форм, объектов, менеджеров).
  2. Формы и их элементы (без добавления реквизитов объектов).
  3. Макеты, общие картинки, стили и интерфейсы.

Что категорически нельзя обновить динамически:

  1. Добавление, удаление или переименование объектов метаданных (справочников, документов, регистров и т. д.).
  2. Изменение состава реквизитов и табличных частей.
  3. Изменение типов данных, длины строк или точности чисел.

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

Кроме того, фоновые и регламентные задания, а также пулы соединений веб-сервисов могут продолжать выполнять старую версию программного кода вплоть до перезапуска соответствующего рабочего процесса rphost.

Риски («демоническое обновление») и способы их устранения

В сообществе разработчиков 1С динамическое обновление нередко называют «демоническим» из-за риска повреждения кэша метаданных. При частом использовании этого механизма в таблицах CONFIG и CONFIGSAVE, а также в локальном кэше серверов и клиентов могут возникать рассинхронизации.

Симптомы сбоя кэша метаданных:

  1. Ошибки вида «Нарушена структура блока» или «Сеанс отсутствует или удален».
  2. Внезапное падение клиентских приложений при открытии определенных форм.
  3. Сброс пользовательских настроек панелей и форм.

Если после динамического обновления возникли подобные ошибки, выполним следующие шаги для восстановления стабильности:

  1. Очистка локального кэша пользователей. Удаляем временные файлы из каталогов %AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8.
  2. Монопольное применение изменений. Завершаем сеансы всех пользователей, вносим незначительное изменение (например, добавляем пробел в комментарий любого общего модуля), сохраняем конфигурацию и выполняем штатное обновление базы данных.
  3. Перезапуск службы кластера серверов. При необходимости перезапускаем службу ragent для полной очистки серверного кэша.

Безопасные альтернативы динамическому обновлению

Чтобы избежать рисков повреждения метаданных и при этом минимизировать простои пользователей, применяют следующие подходы:

  1. Расширения конфигурации и патчи (исправления). Небольшие доработки логики и форм безопаснее вносить через механизм расширений. Они подключаются на лету, не модифицируют основную конфигурацию и легко отключаются в случае обнаружения ошибок.
  2. Внешние печатные формы, отчеты и обработки. Вынесение часто изменяемой функциональности во внешние подключаемые компоненты позволяет обновлять алгоритмы вообще без изменений конфигурации.
  3. Регламентные технологические окна. Изменения основной конфигурации рекомендуется тщательно тестировать на копиях базы данных и устанавливать монопольно во время заранее согласованных технологических окон с блокировкой соединений.
← На главную