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

← На главную

При разработке корпоративных систем на платформе «1С:Предприятие» часто возникает задача своевременно уведомить пользователя о различных событиях. Это может быть приближение крайнего срока выполнения задачи, проведение важного документа, назначение нового бизнес-процесса или изменение статуса заказа. Основная сложность заключается в архитектурном ограничении классического клиент-серверного взаимодействия: сервер 1С не может самостоятельно вызвать метод на клиенте без предварительного запроса со стороны клиентского приложения.

Разберем основные подходы к построению системы оповещений: от типового механизма Библиотеки Стандартных Подсистем (БСП) на обработчиках ожидания до использования современных push-технологий платформы.

Вариант 1. Оптимизированный обработчик ожидания с адаптивным интервалом (механизм БСП)

Наиболее распространенным решением в типовых конфигурациях (таких как 1С:УНФ, 1С:ERP, 1С:КА, 1С:УТ) является подсистема напоминаний пользователя. Чтобы опрос сервера не создавал лишней нагрузки при работе сотен пользователей, в БСП применяется адаптивный динамический интервал опроса и отключение обработчика для нецелевых пользователей.

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


#Область СлужебныйПрограммныйИнтерфейс

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

#КонецОбласти

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


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

Такой подход обеспечивает минимальную нагрузку:

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

Вариант 2. Разделение расчета и чтения (паттерн «Очередь оповещений»)

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

Регламентное задание на сервере: выполняется в фоновом режиме с заданной периодичностью (например, раз в 5–10 минут), рассчитывает условия наступления событий и записывает готовые записи в плоский регистр сведений ОчередьОповещений с ведущим измерением Пользователь и реквизитом ДатаОповещения.
Подписка на события проведения: при оперативном проведении документов серверный код сразу фиксирует факт необходимости оповещения в регистре очереди для ответственных лиц.
Клиентский опрос: обработчик ожидания на клиенте выполняет простейший запрос по индексу: ГДЕ Пользователь = &ТекущийПользователь И ДатаОповещения <= &ТекущаяДата, считывая только готовые факты без расчетов.

Вариант 3. Использование механизма «Система взаимодействия»

Начиная с версии платформы 8.3.10, платформа предоставляет встроенную технологию push-доставки сообщений — Систему взаимодействия. Это единственный способ мгновенно отправить уведомление с сервера на клиент без постоянного циклического опроса базы данных тонким клиентом.

Особенности использования Системы взаимодействия:

Принцип работы: клиентские сеансы поддерживают постоянное соединение по протоколу WebSocket/long-polling со специализированным сервером взаимодействия (в облаке 1С или на собственном локальном сервере взаимодействия).
Отправка уведомления: серверный код в фоновом задании или подписке на событие формирует сообщение Системы взаимодействия адресно пользователю или в групповой чат.
Получение: на стороне клиента платформа автоматически отображает всплывающее оповещение либо передает управление в обработчик интеграции без серверных вызовов со стороны сеанса 1С.

Вариант 4. Внешние каналы доставки (Telegram, почта, SMS)

Если пользователям не обязательно находиться в активном сеансе 1С, целесообразно вынести доставку уведомлений во внешние сервисы. В этом случае сервер 1С в подписке на событие проведения документа или регламентном задании обращается к REST API корпоративного мессенджера (например, Telegram-бота) или почтовому серверу.

Преимущества данного подхода:

Полное отсутствие нагрузки на сеансы тонкого клиента и пул серверных вызовов пользователей.
Гарантированная доставка информации сотрудникам, у которых программа в данный момент закрыта.