1С: как оповестить пользователя с сервера

Задача «оповестить с сервера» возникает, когда код выполняется в серверном контексте — в фоновом задании, регламентной операции, обмене данными или веб-сервисе — и нужно сообщить пользователю о результате. Главная сложность в том, что на сервере нет прямого доступа к интерфейсу клиента: методы вроде ПоказатьОповещениеПользователя() там просто недоступны, а попытка их вызвать приведёт к ошибке.

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

Почему с сервера нельзя показать окно напрямую

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

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

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

Способ 1. СообщитьПользователю при интерактивном вызове

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

&НаСервере
Процедура ВыполнитьОбработкуНаСервере()
// ... логика обработки ...
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Обработано 150 документов, ошибок: 2";
Сообщение.Сообщить();
КонецПроцедуры

Поле КлючДанных позволяет привязать сообщение к объекту — тогда из текста сообщения пользователь сможет перейти к проблемному документу. Поле Поле подсвечивает конкретный реквизит формы. Эти возможности делают СообщитьПользователю стандартным инструментом для сообщений о проверке заполнения и ошибках проведения.

Ограничение способа принципиально: он работает только в рамках одного вызова «клиент → сервер → клиент». Если обработка запущена фоновым заданием и клиент уже вернулся к работе, сообщения из фонового сеанса до пользователя таким путём не дойдут — их некому отобразить.

Способ 2. Длительные операции и фоновые задания

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

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

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

Способ 3. Система взаимодействия

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

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

Требование одно: информационная база должна быть зарегистрирована в сервисе взаимодействия (через сервер 1С:Диалог или собственный сервер взаимодействия). В файловых базах и базах без регистрации метод не сработает, поэтому проверка ИнформационнаяБазаЗарегистрирована() обязательна.

Система взаимодействия хорошо подходит для внутрикорпоративных уведомлений: «заказ согласован», «поступила оплата по счёту», «завершился обмен». Сообщения сохраняются в истории, их можно привязывать к объектам базы.

Способ 4. Регистр уведомлений с опросом на клиенте

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

1. 1
   Создайте регистр сведений с измерением Пользователь и ресурсами Текст, Объект, Прочитано, ДатаСоздания
2. 2
   Добавьте серверную функцию записи уведомления и вызывайте её из прикладного кода
3. 3
   В модуле управляемого приложения подключите обработчик ожидания с интервалом 30–60 секунд
4. 4
   В обработчике вызывайте серверную функцию, возвращающую непрочитанные уведомления текущего пользователя
5. 5
   Покажите уведомления на клиенте и пометьте их прочитанными одним серверным вызовом

Этот подход даёт полный контроль: можно хранить историю, строить отчёт по непрочитанным сообщениям, реализовывать разные уровни важности. Цена — необходимость самостоятельно поддерживать механизм и следить за ростом таблицы регистра.

Чтобы регистр не разрастался, настройте регламентное задание, удаляющее прочитанные уведомления старше заданного срока, например 30 дней. Без очистки таблица на активной базе со временем начнёт влиять на производительность запросов опроса.

Способ 5. Внешние каналы: почта и мессенджеры

Когда пользователь может не работать в 1С в момент события (ночная загрузка, ошибка обмена, истечение срока задачи), единственный надёжный путь — внешний канал. Для почты в платформе есть объект ИнтернетПочта: сервер формирует письмо и отправляет его через SMTP. В типовых конфигурациях для этого используется справочник учётных записей электронной почты.

&НаСервере
Процедура ОтправитьПисьмо(УчетнаяЗапись, Адресат, Тема, Текст)
Профиль = Новый ИнтернетПочтовыйПрофиль;
// заполнение профиля из параметров учётной записи
Письмо = Новый ИнтернетПочтовоеСообщение;
Письмо.Тема = Тема;
Письмо.Получатели.Добавить(Адресат);
Письмо.Тексты.Добавить(Текст);
Почта = Новый ИнтернетПочта;
Почта.Подключиться(Профиль);
Почта.Послать(Письмо);
Почта.Отключиться();
КонецПроцедуры

Для мессенджеров (Telegram, корпоративные чаты) применяются HTTP-запросы к API бота через HTTPСоединение. Это требует хранения токена бота — размещайте его в защищённом хранилище или константах с ограниченным доступом, а не в открытом коде модулей.

Сравнение способов оповещения

СообщитьПользователю

Простейший вариант, но работает только в рамках одного вызова клиент–сервер; не подходит для фоновых процессов

Длительные операции (БСП)

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

Система взаимодействия

Доставка вне зависимости от инициатора, история сообщений; требует регистрации базы в сервисе взаимодействия

Регистр уведомлений

Полный контроль и независимость от подсистем; нужна собственная разработка и обслуживание

Почта и мессенджеры

Достигают пользователя вне 1С; зависят от внешних сервисов и требуют защиты учётных данных

Выбор способа под сценарий

Единого «правильного» способа нет — решение определяется тем, кто инициирует событие и где находится пользователь. Ошибка проведения документа, нажатого пользователем, — территория СообщитьПользователю. Завершение длительной свёртки базы — длительные операции. Согласование заявки, инициированное другим сотрудником, — система взаимодействия или регистр уведомлений. Сбой ночного обмена — письмо или сообщение в мессенджер администратору.

Маршрут решения

Как выбрать способ

Серверный код вызван напрямую из формы пользователяИспользуйте СообщитьПользователю — сообщение покажется при возврате на клиент

Пользователь запустил длительную операцию и ждёт результатаПримените ДлительныеОперации БСП или фоновое задание с опросом состояния

Событие произошло без участия пользователя (регламентное задание, обмен)Пишите в систему взаимодействия, регистр уведомлений или отправляйте письмо

Пользователь может быть вне 1С (ночь, выходной)Отправляйте email или сообщение через API мессенджера

Проверка результата и типичные ошибки

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

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

Контрольные точки

Как проверить результат

Сообщение при интерактивном вызове

Норма

Появляется в панели сообщений формы после выполнения серверной процедуры

Тревожный признак

Сообщения нет — проверьте, не подавляется ли вывод и не теряется ли контекст вызова

Уведомление из регламентного задания

Норма

Запись появляется в регистре/обсуждении или письмо приходит адресату

Тревожный признак

В журнале регистрации ошибка задания — смотрите текст исключения и права служебного пользователя

Опрос уведомлений на клиенте

Норма

Новые уведомления появляются в течение заданного интервала

Тревожный признак

Обработчик ожидания не подключён или интервал слишком велик

Ограничения и безопасная работа

Любой механизм оповещений создаёт нагрузку. Массовая отправка писем из цикла по сотням получателей может привести к блокировке SMTP-учётки почтовым провайдером — используйте пакетную отправку и разумные паузы. Частые серверные вызовы из обработчиков ожидания у множества одновременно работающих пользователей суммируются в заметную нагрузку на кластер.

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

Частые вопросы

Можно ли из регламентного задания показать сообщение конкретному пользователю?

Напрямую — нет, у регламентного задания нет доступа к чужому клиентскому сеансу. Рабочие варианты: записать уведомление в регистр сведений, отправить сообщение через систему взаимодействия или выслать письмо. Пользователь увидит сообщение при следующем опросе или в панели обсуждений.

Почему СообщитьПользователю в фоновом задании не выводит текст?

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

Работает ли система взаимодействия в файловой базе?

Система взаимодействия требует регистрации информационной базы в сервисе взаимодействия. Для файловых баз возможности ограничены, поэтому перед отправкой всегда проверяйте СистемаВзаимодействия.ИнформационнаяБазаЗарегистрирована() и предусматривайте запасной канал, например регистр уведомлений.

Как оповестить пользователя, который сейчас не работает в 1С?

Только внешними каналами: электронной почтой через ИнтернетПочта или сообщением в мессенджер через HTTP-запрос к API бота. Уведомления внутри базы (регистр, обсуждения) пользователь увидит лишь при следующем входе.

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

Для большинства сценариев достаточно интервала 30–60 секунд. Более частый опрос заметно увеличивает число серверных вызовов при большом количестве пользователей и редко оправдан: срочные события лучше дублировать внешним каналом.

Где смотреть ошибки, если оповещение не пришло?

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