Регламентные задания — ошибки в ЖР, защита от параллельного запуска

Правило

Обработчик регламентного (и фонового) задания:

• Перехватывает ошибки и пишет их в ЖР с контекстом. Упавшее без перехвата задание никого не уведомляет — о проблеме узнают через неделю по последствиям.
• Защищён от параллельного запуска: если предыдущий запуск ещё работает, новый завершается сразу (управляемая блокировка/проверка активных фоновых заданий). Иначе два экземпляра обрабатывают одни данные наперегонки.
• Безопасен при повторе: запуск после сбоя продолжает с места остановки, а не задваивает эффекты (см. идемпотентность).
• Экспортный, в серверном общем модуле (не в модуле формы/клиентском) — это же проверяет диагностика ScheduledJobHandler.
• Длительная работа — порциями с фиксацией прогресса, чтобы обрыв не терял часы работы.

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

Задание добавлено расширением (CFE)

Задание из расширения живёт вместе с расширением — это проверяется отдельно:

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

Зачем

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

Неправильно

Процедура ОбменССайтом() Экспорт
    // Без перехвата: первая же сетевая ошибка — задание молча падает,
    // в ЖР только системная запись, контекста нет.
    // Без защиты от параллельности: при зависании прошлого запуска
    // следующий начнёт обрабатывать те же данные.
    ВыгрузитьЗаказы();
    ЗагрузитьСтатусы();
КонецПроцедуры

Правильно

Процедура ОбменССайтом() Экспорт
    // Защита от параллельного запуска.
    Блокировка = Новый БлокировкаДанных;
    // ... установить блокировку по ключу задания; занято — выйти.

    Попытка
        ВыгрузитьЗаказы();   // внутри — порциями, с фиксацией прогресса
        ЗагрузитьСтатусы();
    Исключение
        ЗаписьЖурналаРегистрации(НСтр("ru='Обмен с сайтом'"),
            УровеньЖурналаРегистрации.Ошибка, , ,
            ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
        ВызватьИсключение; // задание должно быть видно как упавшее
    КонецПопытки;
КонецПроцедуры

Когда не применять

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

См. также

• Реестр регламентных заданий

• Обработка ошибок и логирование
• Идемпотентность обработчиков обмена
• Долгие и большие операции интеграций — асинхронно
• Реестр регламентных заданий
• Контуры баз — прод, тест, копии
• Грабли расширений (CFE)