Обработчик ожидания в 1С: принципы работы и настройка

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

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

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

Как устроен механизм ожидания на клиенте

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

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

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

Синтаксис и параметры ПодключитьОбработчикОжидания

Метод имеет три параметра: ПодключитьОбработчикОжидания(ИмяПроцедуры, Интервал, Однократно). Первый параметр — строка с именем процедуры, без скобок и параметров. Второй — интервал в секундах, допускаются дробные значения (например, 0.1 для десяти вызовов в секунду, хотя на практике такие малые интервалы не рекомендуются). Третий параметр — булево: если Истина, процедура выполнится один раз и обработчик автоматически отключится.

Для отключения используется ОтключитьОбработчикОжидания(ИмяПроцедуры) — метод снимает регистрацию таймера по имени процедуры. Если подключено несколько обработчиков на одну и ту же процедуру, отключаются все. Поэтому на одну процедуру в рамках одного контекста лучше иметь один активный обработчик.

&НаКлиенте
Процедура ПриОткрытии(Отказ)
	// Однократный вызов через 0,1 секунды — отложенная инициализация
	ПодключитьОбработчикОжидания("ПослеОткрытияФормы", 0.1, Истина);
	// Периодический опрос каждые 30 секунд
	ПодключитьОбработчикОжидания("ОбновитьДанныеФормы", 30);
КонецПроцедуры

&НаКлиенте
Процедура ОбновитьДанныеФормы() Экспорт
	ОбновитьДанныеНаСервере();
КонецПроцедуры

&НаКлиенте
Процедура ПриЗакрытии(ЗавершениеРаботы)
	ОтключитьОбработчикОжидания("ОбновитьДанныеФормы");
КонецПроцедуры

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

Однократный вызов: отложенные действия

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

Типовой приём — интервал 0.1 секунды: форма успевает отрисоваться, и пользователь видит интерфейс, а не «зависшее» окно. Это заметно улучшает воспринимаемую скорость работы, даже если фактическое время выполнения не изменилось.

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

Периодический опрос: интервалы и нагрузка

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

Практические ориентиры: проверка состояния фонового задания — 1–3 секунды, но только пока задание реально выполняется; автообновление списков — от 30 секунд и выше; напоминания и мониторинг — минуты. Чем больше пользователей работает с системой, тем консервативнее должен быть интервал.

Хороший шаблон — адаптивный интервал: пока данных нет или задание активно, опрашивать чаще; после получения результата — отключать обработчик или увеличивать интервал. Для этого обработчик отключается и подключается заново с новым интервалом, так как изменить интервал «на лету» нельзя.

1. 1
   Создайте экспортную клиентскую процедуру без параметров с понятным именем
2. 2
   Подключите обработчик в ПриОткрытии или по действию пользователя с обоснованным интервалом
3. 3
   Внутри процедуры проверяйте условие: есть ли смысл выполнять работу в этой итерации
4. 4
   При достижении результата отключите обработчик через ОтключитьОбработчикОжидания
5. 5
   Добавьте отключение в ПриЗакрытии формы
6. 6
   Протестируйте под нагрузкой: откройте форму и оставьте на 10–15 минут, наблюдая за числом серверных вызовов

Проверка фоновых заданий через обработчик ожидания

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

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

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

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

Типичные ошибки и ограничения механизма

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

Вторая ошибка — попытка использовать обработчик ожидания как фоновое выполнение. Код обработчика выполняется в основном потоке, поэтому тяжёлый цикл внутри процедуры «заморозит» интерфейс. Для длительной работы нужны фоновые задания на сервере, а обработчик ожидания — только для опроса их состояния.

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

Диагностика и проверка результата

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

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

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

Альтернативы обработчику ожидания

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

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

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