Как предотвратить выполнение регламентных заданий в 1С после перезапуска сервера до ручного подтверждения

← На главную

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

Особенности платформы: почему нет события старта службы

Проанализируем архитектуру серверной части платформы «1С:Предприятие». Встроенный язык 1С функционирует исключительно внутри сеансов (пользовательских, фоновых, сеансов внешних соединений или веб-сервисов). Такие события, как ПриНачалеРаботыСистемы или УстановкаПараметровСеанса, исполняются в контексте конкретного клиентского или фонового подключения.

На уровне служб кластера (процессы ragent, rmngr, rphost) программного обработчика инициализации самого сервиса не предусмотрено. Вся информация о расписаниях, признаках активности и использовании регламентных заданий хранится непосредственно в таблицах СУБД. Поэтому при перезапуске службы сервер 1С считывает существующие настройки из базы данных и автоматически запускает активные регламентные задания в соответствии с их расписанием.

Вариант 1. Контроль статуса выполнения через константу или регистр сведений

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

Для этого заведем в конфигурации константу (или ресурс регистра сведений) СтатусВыгрузкиУспешна с типом Булево. Посмотрим на алгоритм реализации в коде общего модуля:


Процедура ВыполнитьРегламентнуюОтправку() Экспорт

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

    // Фиксируем начало критической секции
    Константы.СтатусВыгрузкиУспешна.Установить(Ложь);

    Попытка
        // Основной алгоритм пакетной отправки во внешнюю систему
        ВыполнитьОтправкуПакета();

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

КонецПроцедуры

Разберем логику работы этого метода:

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

Вариант 2. Автоматическая блокировка регламентных заданий через утилиту RAC

Если требуется полностью исключить запуск любых фоновых заданий в базе данных после старта физического сервера, задействуем штатный параметр кластера «Блокировка регламентных заданий включена» (ScheduledJobsDenied). Когда флаг включен, фоновые задания по расписанию не стартуют, но интерактивный вход для пользователей и администраторов остается открытым.

Для автоматизации этой блокировки сразу после загрузки операционной системы настроим выполнение системного скрипта через планировщик ОС (триггер «При запуске системы») или службу systemd в Linux.

Рассмотрим пример команды с использованием утилиты rac:


rac infobase --ib="ИмяИнформационнойБазы" update --scheduled-jobs-deny=on --infobase-user="Администратор" --infobase-pwd="Пароль"

В результате при каждой перезагрузке сервера регламентные задания базы будут гарантированно заблокированы. Ответственный сотрудник сможет войти в базу в режиме «1С:Предприятие» и включить выполнение заданий вручную через стандартную обработку «Блокировка работы пользователей» или консоль администрирования кластера.

Вариант 3. Использование энергозависимого маркера (RAM-диск или временный каталог)

Проанализируем вариант контроля перезагрузки операционной системы без изменения настроек кластера. Он основан на проверке наличия специального lock-файла в энергозависимой памяти сервера (например, на RAM-диске или в каталоге /tmp в ОС Linux, который очищается при перезагрузке).

При запуске регламентное задание проверяет наличие файла-флага по заданному пути на сервере.
Если файл отсутствует — задание фиксирует, что сервер перезагружался, и пропускает выполнение.
После рестарта администратор заходит в специальную обработку в 1С и нажимает кнопку «Разрешить работу», которая программно создает файл на диске.

Архитектурный подход: паттерн Transactional Outbox

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

Для надежной интеграции рекомендуется использовать следующие архитектурные решения:

Очередь сообщений (Transactional Outbox): документы для отправки регистрируются в отдельном регистре сведений со статусами (КОтправке, ВПроцессе, Отправлено, Ошибка). Регламентное задание берет порцию записей, фиксирует статус ВПроцессе и отправляет их по отдельности.
Идемпотентность API: при передаче пакета во внешнюю систему передается уникальный идентификатор (GUID) документа. Если внешняя система уже получила данный документ до падения сервера, при повторной отправке она возвращает успешный статус, исключая дублирование данных.