Как оповестить клиента 1С о событии на сервере без лишних затрат?

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

Использование регистра сведений для хранения очереди событий

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

1. Создадим непериодический независимый регистр сведений, где измерением будет пользователь или идентификатор рабочего места, а ресурсом — статус события или ссылка на измененный объект.
2. На клиенте настроим ПодключитьОбработчикОжидания, который с заданным интервалом (например, 10–15 секунд) выполняет проверку регистра.
3. Чтобы минимизировать нагрузку, используем инкрементальное обновление: сохраняем в параметрах сеанса или в переменной модуля формы идентификатор последнего прочитанного события (например, GUID или ДатаСобытия).

Разберем пример запроса, который клиент отправляет к серверу:

// Запрос к регистру на наличие новых записей
Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ Первые 1
|	События.Ссылка КАК Событие
|ИЗ РегистрСведений.ОчередьСобытий КАК События
|ГДЕ События.Дата > &ПоследняяПроверка
|УПОРЯДОЧИТЬ ПО События.Дата УБЫВ";
Запрос.УстановитьПараметр("ПоследняяПроверка", ПоследняяДата);

Механизм блокировок объектов

Если задача состоит в отслеживании изменения конкретного справочника или документа, можно использовать метод БлокировкаДанных. Блокировка выступает как «маячок»: если один сеанс захватил блокировку объекта, остальные могут получить информацию об этом. Преимущество в том, что при аварийном завершении сеанса блокировка автоматически снимается платформой, что избавляет нас от проблем с «фантомными» записями в регистрах.

Работа через внешние компоненты и TCP/UDP

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

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

• Отсутствие необходимости «дергать» базу данных ежесекундно.
• Реальная событийная модель (push-уведомление): сервер сам отправляет пакет данных клиенту, как только событие произошло.
• Снижение нагрузки на СУБД, так как отсутствуют частые запросы на чтение.

Использование Сервера взаимодействия

Если инфраструктура компании позволяет, стоит рассмотреть СистемаВзаимодействия. Это встроенный в платформу механизм, который предназначен именно для обмена сообщениями между пользователями и сеансами. Хотя он требует настройки или покупки лицензии, он является «родным» решением от фирмы 1С для задач обмена оповещениями, чатов и уведомлений.

Рекомендации по реализации

Проанализировав ситуацию, выделим несколько советов для выбора метода:

1. Не стремитесь к мгновенной реакции, если бизнес-процесс этого не требует. Задержка в 10–20 секунд для уведомления пользователя обычно является допустимой и практически незаметной, при этом она существенно снижает нагрузку на кластер серверов 1С.
2. Адаптивный опрос: если данных нет, увеличивайте интервал опроса (например, до 1 минуты). Как только зафиксировано первое событие, уменьшайте интервал до 3 секунд, чтобы пользователь оперативно увидел обновление.
3. Чистка данных: при использовании регистра сведений не забывайте про регламентное задание, которое очищает старые записи (например, старше суток), чтобы регистр не разрастался до гигантских размеров.

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