← На главную

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

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

Почему не подойдет глобальный метод Оповестить?

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

Решение 1: Регистр сведений и обработчик ожидания (Классический подход)

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

Разберем по шагам реализацию данного метода:

1. Создаем непериодический независимый регистр сведений, например, ОчередьОповещений.
2. В измерениях регистра указываем пользователя или уникальный идентификатор сеанса получателя. В ресурсах — ссылку на измененный документ и новые данные (например, количество).
3. В модуле объекта документа в процедуре ПриЗаписи добавляем код, который при изменении важных реквизитов делает запись в наш регистр сведений.
4. В форме обработки (АРМ операциониста) при открытии подключаем обработчик ожидания с помощью метода ПодключитьОбработчикОжидания, который будет срабатывать, например, каждые 5-10 секунд.
5. В процедуре обработчика ожидания читаем данные из регистра только по текущему пользователю.
6. Если записи найдены, выводим оповещение на экран, обновляем данные формы и сразу же удаляем прочитанные записи из регистра, чтобы не обрабатывать их повторно.

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

Решение 2: Программное использование Системы Взаимодействия (СВ)

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

Проанализируем реализацию:

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

Этот способ работает по принципу push-уведомлений и избавляет систему от постоянных опросов базы данных.

Решение 3: Менеджер уведомлений клиента (Платформа 8.3.26 и выше)

С выходом версии платформы 8.3.26 появился долгожданный штатный функционал, созданный специально для решения подобных бизнес-сценариев. Разберем этот новый и самый оптимальный архитектурный подход.

В системе реализован объект МенеджерУведомленийКлиента, который позволяет отправлять push-уведомления со стороны сервера напрямую в конкретные клиентские приложения.

Как это работает:

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

Это самый "чистый", производительный и правильный подход для современных конфигураций 1С, так как он не требует настройки Системы взаимодействия и не нагружает СУБД лишними запросами.

Решение 4: Интеграция с внешними брокерами сообщений

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

В данном случае архитектура строится следующим образом:

1. При проведении документа 1С формирует короткий HTTP-запрос (сигнал) и отправляет его в очередь сообщений внешнего брокера.
2. Рабочее место операциониста (АРМ) поддерживает постоянное активное соединение (например, через внешнюю компоненту WebSocket).
3. Брокер мгновенно доставляет push-сигнал об изменении данных в обработку.

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

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