В современной разработке на платформе 1С:Предприятие часто возникает задача мгновенного оповещения пользователей о событиях, происходящих на стороне сервера или во внешних системах. Классический подход с использованием ПодключитьОбработчикОжидания (так называемый "поллинг" или "дерганье" сервера) создает избыточную нагрузку на базу данных и сетевой трафик, так как клиентские приложения вынуждены постоянно спрашивать сервер: "Не появилось ли чего-то нового?".
Проанализируем ситуацию: нам нужно, чтобы при вызове внешнего HTTP-сервиса данные автоматически и без задержек "всплывали" в открытых управляемых формах у определенных пользователей. Рассмотрим подробнее наиболее эффективные способы реализации этой задачи, которые позволяют минимизировать нагрузку на систему.
Начиная с версии платформы 8.3.11, разработчикам доступен мощный инструмент — Система взаимодействия. Многие ошибочно воспринимают её только как встроенный мессенджер, однако это полноценная шина данных для обмена сообщениями между сеансами в реальном времени.
Разберем по шагам, как это работает программно:
Посмотрим на пример кода, который можно использовать для программной отправки сообщения из кода HTTP-сервиса или серверного модуля:
// Находим или создаем обсуждение (например, по ключу или контексту)
ВыборкаОбсуждений = СистемаВзаимодействия.СоздатьВыборкуОбсуждений();
// Здесь логика поиска нужного обсуждения...
НовоеСообщение = СистемаВзаимодействия.СоздатьСообщение(НужноеОбсуждение);
НовоеСообщение.Текст = "Данные получены через HTTP";
// Можно добавить структуру в свойство Данные для передачи параметров
НовоеСообщение.Данные = Новый Структура("ID, Статус", "12345", "Выполнено");
НовоеСообщение.Записать();
На стороне клиента (в модуле управляемой формы) мы проанализируем событие получения. Для этого используется метод ПодключитьОбработчикОжидания только один раз при открытии или специальные события системы взаимодействия:
&НаКлиенте
Процедура ПриОткрытии(Отказ)
СистемаВзаимодействия.ПодключитьОбработчикПолученияСообщения(Новый ОписаниеОповещения("ОбработкаСообщения", ЭтотОбъект));
КонецПроцедуры
&НаКлиенте
Процедура ОбработкаСообщения(Сообщение, ДополнительныеПараметры) Экспорт
Если Сообщение.Данные.Свойство("ID") Тогда
// Обновляем данные на форме без перезагрузки всей страницы
ЭтаФорма.ОбновитьОтображениеДанных();
КонецЕсли;
КонецПроцедуры
Преимущества: Это штатный механизм 1С, он поддерживает масштабирование и не требует написания низкоуровневого кода для работы с сокетами.
Если по каким-то причинам использование сервера системы взаимодействия невозможно (например, строгие политики безопасности или отсутствие доступа в интернет для базовой версии сервера), стоит рассмотреть вариант с внешними компонентами (ВК). Этот метод обеспечивает максимальную производительность и независимость.
Суть метода заключается в реализации протокола WebSocket. В отличие от HTTP, где клиент всегда инициализирует запрос, WebSocket позволяет серверу отправлять данные клиенту в любой момент по уже открытому каналу.
Выясним причину, почему это эффективно для 1С:
Внешняя компонента, загруженная на клиенте, может работать в отдельном потоке. При получении данных из сети она генерирует событие ВнешнееСобытие, которое платформа 1С перехватывает штатным образом.
Рассмотрим примерную схему взаимодействия:
ВнешнееСобытие.Пример обработки на стороне 1С:
&НаКлиенте
Процедура ВнешнееСобытие(Источник, Событие, Данные)
Если Источник = "WebSocketComponent" И Событие = "MessageReceived" Тогда
// "Данные" содержат JSON или строку от сервера
СтруктураДанных = ДесериализоватьJSON(Данные);
// Выполняем действия в форме
Сообщить("Получены новые данные: " + СтруктураДанных.Значение);
КонецЕсли;
КонецПроцедуры
Важный нюанс: Использование MQTT-протокола через ВК часто оказывается даже удобнее для чатов и систем мониторинга, так как он изначально спроектирован для работы в условиях нестабильной связи и поддерживает систему "подписок" на темы (topics).
Хотя автор вопроса просил избежать "дерганья", мы обязаны упомянуть Long Polling как промежуточный вариант. Это метод, при котором клиент отправляет запрос, а сервер "засыпает" и не отвечает до тех пор, пока не появятся данные.
Проанализируем ситуацию: в 1С этот метод реализовать крайне сложно и не рекомендуется. Каждое такое "удержание" соединения занимает активный сеанс и рабочий процесс rphost. Если у вас 100 пользователей, вам потребуется 100 свободных лицензий и огромный объем оперативной памяти сервера только на то, чтобы "ждать".
Выберем оптимальный путь развития проекта в зависимости от условий:
1. Если проект современный и есть возможность администрирования сервера:
Однозначно выбираем Систему взаимодействия. Это наиболее "чистый" код, отсутствие необходимости регистрировать сторонние библиотеки (DLL) на рабочих местах пользователей и полная поддержка со стороны вендора 1С.
2. Если требуется интеграция с очень специфическим оборудованием или сторонними real-time сервисами:
Используем Внешние компоненты. Это дает свободу выбора протокола (WebSockets, MQTT, gRPC) и позволяет обмениваться данными минуя основной кластер 1С, что полезно при экстремально высоких нагрузках.
3. Если разработка ведется для мобильной платформы:
Здесь лучше всего использовать интеграцию с Push-уведомлениями (Firebase для Android или APNs для iOS). Платформа 1С имеет встроенные функции ДоставитьПушУведомление, которые позволяют активировать приложение даже если оно свернуто.
Таким образом, реализация "живого" интерфейса в 1С без постоянных опросов базы — задача вполне решаемая. Главное — перенести логику ожидания данных с плеч основного сервера 1С на специализированные механизмы оповещений.