В практике разработки на платформе 1С:Предприятие 8.3 часто возникает парадоксальная ситуация: самописное регламентное задание, запущенное в автоматическом режиме по расписанию, завершается с ошибкой, однако стоит разработчику нажать кнопку «Выполнить сейчас» в консоли заданий — и всё проходит идеально. Давайте подробно разберем, почему так происходит, и проанализируем внутренние механизмы платформы, которые определяют эту разницу.
Одной из самых частых причин отказа задания по расписанию является ограничение прав на уровне RLS (Record Level Security) или отсутствие необходимых прав у пользователя, под которым стартует задание. Разберем этот момент подробнее.
При выполнении по расписанию задание запускается от имени пользователя, указанного в настройках регламентного задания. Если пользователь не указан, оно выполняется под системным сеансом (часто с полными правами, но без привязки к конкретным настройкам физического пользователя). При ручном запуске через стандартные обработки БСП (Библиотеки стандартных подсистем) система часто принудительно устанавливает привилегированный режим или использует контекст текущего администратора.
Рассмотрим пример кода, который часто помогает решить проблему прав. Мы можем программно включить привилегированный режим в начале процедуры-обработчика:
Процедура ВыполнитьМоеЗадание() Экспорт
// Устанавливаем привилегированный режим, чтобы игнорировать RLS
УстановитьПривилегированныйРежим(Истина);
// Код выполнения задания
ВыполнитьОбработкуДанных();
КонецПроцедуры
Использование УстановитьПривилегированныйРежим(Истина) позволяет коду обращаться к любым данным в базе, даже если у текущего пользователя сеанса недостаточно прав на чтение конкретных записей справочников или регистров.
Давайте проанализируем ситуацию с точки зрения жизненного цикла сеанса. Когда мы нажимаем кнопку в интерфейсе, мы уже находимся внутри активного сеанса, где отработал модуль сеанса и заполнились ПараметрыСеанса. При автоматическом старте по расписанию сервер 1С создает новый фоновый сеанс.
Если в коде задания есть обращение к параметрам сеанса (например, ПараметрыСеанса.ТекущийПользователь), а процедура УстановкаПараметровСеанса в модуле сеанса не предусматривает инициализацию этих данных для фоновых заданий, код упадет с ошибкой «Параметр сеанса не инициализирован».
Посмотрим на пример правильной инициализации в модуле сеанса:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
Если ТребуемыеПараметры = Неопределено Тогда
// Полная инициализация
Иначе
// Инициализация конкретных параметров
КонецЕсли;
КонецПроцедуры
Выясним причину: если ваше задание опирается на значения, которые заполняются только при интерактивном входе пользователя, оно никогда не выполнится успешно в автоматическом режиме без доработки этого модуля.
Важно помнить, что регламентное задание исполняется сервером 1С. Это значит, что оно работает от имени учетной записи операционной системы, под которой запущена служба 1C:Enterprise 8 Server Agent (например, USR1CV8).
Рассмотрим сценарии, где это критично:
Z:\, а у службы сервера — нет.Новый COMОбъект("Excel.Application") часто проваливается в фоновом задании, так как у системной службы нет прав на запуск DCOM-компонентов или отсутствует профиль рабочего стола (Desktop).C:\Users\Admin\Desktop\file.txt будет недоступен для сервера, даже если для вас он открыт.Проанализируем программный код на наличие клиентских методов. Регламентное задание всегда выполняется исключительно на сервере. Если внутри цепочки вызовов затесалась команда Предупреждение(), Вопрос() или обращение к ФайловаяСистемаКлиент, то:
Интересный нюанс кроется в проверке даты запрета изменения данных. В конфигурациях на базе БСП (как УТ 11.2) проверка даты запрета может работать по-разному для конкретного пользователя и для «пустого» пользователя регламентного задания. Если задание пытается провести документ в закрытом периоде, ручной запуск под администратором (у которого есть право обхода даты запрета) пройдет успешно, а автоматический запуск — нет, так как для него применится общая дата запрета для всех пользователей.
Разберем влияние окружения. Сеанс регламентного задания наследует региональные настройки (формат чисел, дат) от системной учетной записи сервера. Если ваш код парсит строку даты или числа, полагаясь на запятую как разделитель, а на сервере в системной локали установлена точка, задание по расписанию выдаст ошибку преобразования типа, в то время как у пользователя с русской локалью всё будет работать корректно.
Чтобы локализовать и устранить проблему, выполним следующие шаги:
ЗаписьЖурналаРегистрации("МоеЗадание.Этап1", УровеньЖурналаРегистрации.Информация, , , "Начало обработки...");
Таким образом, основная разница заключается в контексте безопасности и полноте инициализации серверного окружения. Внимательный анализ прав доступа и параметров сеанса позволяет решить 90% проблем с регламентными заданиями.