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

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

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

Архитектурные ограничения платформы

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

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

Вариант 1: Использование Системы взаимодействия (рекомендуемый механизм)

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

Разберем ключевые особенности Системы взаимодействия:

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

Вариант 2: Механизм периодического опроса (Polling)

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

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

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

1. Создается объект для хранения очереди (обычно непериодический регистр сведений, содержащий реквизиты: Получатель, ДатаСообщения, ТекстСообщения, Прочитано).
2. Пользователь-инициатор записывает в этот регистр запись для конкретного адресата или группы пользователей.
3. На стороне клиента при начале работы системы подключается фоновый обработчик с помощью метода ПодключитьОбработчикОжидания.

Посмотрим на пример подключения обработчика на клиенте:

&НаКлиенте
Процедура ПриНачалеРаботыСистемы()
    // Подключаем опрос каждые 30 секунд
    ПодключитьОбработчикОжидания("ПроверитьВходящиеОповещения", 30, Ложь);
КонецПроцедуры

&НаКлиенте
Процедура ПроверитьВходящиеОповещения() Экспорт
    НовыеСообщения = ПолучитьНовыеСообщенияНаСервере();
    Для Каждого ТекстСообщения Из НовыеСообщения Цикл
        ПоказатьОповещениеПользователя("Новое событие", , ТекстСообщения);
    КонецЦикла;
КонецПроцедуры

Ограничения метода поллинга:

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

Вариант 3: Использование внешних компонент (Native API / WebSockets)

Для создания высоконагруженных систем обмена сообщениями без использования Системы взаимодействия применяются внешние компоненты (ВК), работающие по протоколам WebSockets, TCP или через брокеры сообщений (RabbitMQ, Redis, MQTT).

Схема работы выглядит следующим образом:

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

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

Готовые механизмы в Библиотеке стандартных подсистем (БСП)

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

Резюме

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