Как работают регламентные задания в 1С

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

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

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

Как устроен механизм: регламентное и фоновое задание

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

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

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

Отличия файлового и клиент-серверного режимов

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

В файловом варианте планировщика нет. Регламентные задания выполняются только если запущен отдельный сеанс, который их обслуживает. Классический способ — запуск тонкого клиента с параметром /ExecuteScheduledJobs или периодический вызов ВыполнитьОбработкуЗаданий() из любого клиентского сеанса. Если ни один сеанс не запущен — задания просто не выполняются, и это не ошибка, а особенность архитектуры.

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

Как создать регламентное задание в конфигураторе

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

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

1. 1
   Создайте общий модуль с флагом «Сервер» и напишите в нём экспортную процедуру без параметров или с параметрами через запятую
2. 2
   Добавьте объект «Регламентное задание», укажите метод в формате Модуль.Процедура
3. 3
   Настройте расписание: периодичность, время начала, дни недели
4. 4
   Установите «Использование» и при необходимости «Предопределенное»
5. 5
   Обновите конфигурацию базы данных и проверьте задание в консоли
6. 6
   Запустите задание вручную и проверьте результат в журнале регистрации

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

Настройка расписания и параметров выполнения

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

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

Параметр «Ключ» позволяет отличать экземпляры заданий, использующих один метод. «Количество повторов при аварийном завершении» и «Интервал повтора» определяют, сколько раз платформа попытается перезапустить упавшее задание. Для обменов с внешними системами разумно задать 2–3 повтора с паузой — временная недоступность сервиса не должна приводить к остановке обмена до вмешательства администратора.

Как выполняются задания: права, сеансы, блокировки

Фоновое задание выполняется от имени пользователя, указанного в свойстве «Имя пользователя» регламентного задания. Если пользователь не задан, используется пользователь по умолчанию с ограниченным контекстом. Права этого пользователя определяют, к каким данным задание получит доступ — типовая ошибка, когда обмен работает у разработчика под полными правами и падает в рабочей базе под служебным пользователем.

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

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

Мониторинг, отладка и типичные ошибки

Основной инструмент диагностики — журнал регистрации с отбором по событию «Фоновое задание» или по имени регламентного задания. Там видны запуск, завершение и текст ошибки при аварийном завершении. В типовых конфигурациях есть обработка «Регламентные и фоновые задания» (раздел «Администрирование»), показывающая состояние, расписание и последние ошибки в удобном виде.

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

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

Когда регламентное задание — не лучший выбор

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

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

Чем запускать фоновую логику

Регламентное задание

Периодические операции по расписанию: обмены, расчёты, рассылки. Не подходит для разовых и событийных задач

Программный запуск фонового задания

Разовые длительные операции по кнопке пользователя, с индикацией прогресса. Без расписания

Подписка на событие

Реакция на запись объекта. Синхронная — выполняется в транзакции пользователя, тяжёлую логику лучше выносить в очередь

Внешний планировщик (cron, планировщик Windows)

Запуск пакетного режима 1С или скриптов по расписанию вне платформы. Требует отдельного сопровождения

Часто задаваемые вопросы

Почему регламентное задание не выполняется в файловой базе?

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

Как посмотреть, почему задание завершилось с ошибкой?

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

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

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

Почему задание работает у разработчика, но падает в рабочей базе?

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

Что произойдёт, если сервер был выключен в момент запуска?

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

Как временно отключить все регламентные задания в базе?

В клиент-серверном режиме — установить свойство «Блокировка регламентных заданий» в свойствах информационной базы в консоли кластера. В файловом режиме достаточно не запускать сеанс-обработчик заданий. Для точечного отключения снимите флаг «Использование» у конкретного задания в консоли заданий или программно.