Real-time: модуль Pull
Модуль pull обеспечивает передачу событий в браузер в реальном времени через веб-сокеты и системный push-сервер. Отправка сообщений из PHP выполняется через \Bitrix\Pull\Event::add() (фоновая задача после завершения хита) или Event::send(), а групповые подписки на сущности организуются через механизм тегов CPullWatch.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
Push & Pull и очередь сообщений
-
2
Каналы и подписки на клиенте
-
3
Отправка событий из кода
-
4
Ограничения и масштабирование
Материалы
Официальная документация
Проверь себя
Event::add() вернул true, а в браузере событие не пришло. Что проверять первым?
Отправка отложена в фоновую задачу после ответа хита: смотреть, дошёл ли хит до конца и что случилось в sendInBackground(). Ошибки публикации уходят через trigger_error в лог, add() о них не знает. В консольном скрипте вызывать Event::send() явно.
Три менеджера смотрят один заказ. Как уведомить всех, не собирая список их ID?
Тегами: CPullWatch::Add($userId, 'ORDER_15') при открытии страницы и CPullWatch::AddToStack('ORDER_15', $params) при изменении. Ядро разошлёт всем, кто следит за тегом.
После переезда сайта в Docker уведомления перестали приходить. Где искать?
В секции pull файла .settings.php или в настройках модуля: path_to_publish указывает на 127.0.0.1:8895 старого сервера, path_to_listener — на домен. Push-сервер должен быть доступен по этим адресам с новой ноды.
Когда Pull не стоит брать даже для «живого» интерфейса?
Когда обновление нужно раз в минуту на одной странице и push-сервера ещё нет: setInterval с AJAX дешевле в поддержке. Pull окупается при частых событиях и готовой инфраструктуре.
Не сходится?
Спросите ассистента BXMax: он знает документацию и материалы сайта по этой теме.
Знаете материал лучше?
Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить