Работа с регламентными заданиями в платформе 1С:Предприятие 8.3 (особенно в файловом варианте и на обычных формах) имеет ряд специфических нюансов. Часто разработчики сталкиваются с ситуацией, когда задание создано, расписание настроено, но фактического запуска не происходит или он завершается с ошибкой. Рассмотрим подробно, как диагностировать такие проблемы, разберем причины возникновения ошибок и научимся правильно передавать параметры в процедуры фоновых заданий.
Одной из самых распространенных причин сбоя является несоответствие программного интерфейса процедуры и настроек самого объекта в метаданных. Проанализируем ситуацию: в модуле определена процедура ЗаданиеОбменССайтом(КодНастройки). При запуске через консоль заданий или планировщик система выдает ошибку о нехватке параметров. Это происходит потому, что механизм регламентных заданий ожидает четкого соответствия количества переданных значений количеству аргументов в процедуре. Для автоматического обнаружения несоответствий в вызовах процедур можно использовать инструмент анализа конфигураций на ошибки вызова процедур и функций.
Выясним причину: когда мы создаем регламентное задание в конфигураторе, мы указываем метод (процедуру), который должен быть выполнен. Если в коде процедура описана с одним параметром, а в объекте РегламентноеЗадание массив параметров пуст, выполнение прервется еще на этапе инициализации фонового процесса. Посмотрим, как это устроено внутри платформы.
В объекте метаданных РегламентноеЗадание существует свойство Параметры. Важно понимать, что это не просто набор именованных настроек, а строго упорядоченный Массив значений. При вызове процедуры планировщик берет этот массив и подставляет его элементы в качестве аргументов функции.
Рассмотрим правила заполнения:
Экспортная и принимает два параметра, массив должен содержать ровно два элемента.jobsconsole), часто не позволяют редактировать этот массив интерактивно, что и приводит к ошибкам при тестировании.Поскольку интерактивно задать параметры в некоторых конфигурациях сложно, разберем способ программного управления. Это особенно актуально, когда нам нужно передать специфический код настройки или ссылку на объект. Проанализируем следующий пример кода, который можно выполнить во внешней обработке:
МетаданныеЗадания = Метаданные.РегламентныеЗадания.Найти("ОбменССайтом");
// Получаем список всех существующих заданий этого типа
Задания = РегламентныеЗадания.ПолучитьРегламентныеЗадания(МетаданныеЗадания);
Для Каждого Задание Из Задания Цикл
// Создаем массив параметров, который ожидает процедура
МассивПараметров = Новый Массив;
МассивПараметров.Добавить("ОСНОВНАЯ_НАСТРОЙКА"); // Это значение попадет в КодНастройки
// Перезаписываем параметры в объекте
Задание.Параметры = МассивПараметров;
// Обязательно записываем изменения в базу
Задание.Записать();
Сообщить("Параметры для задания успешно обновлены!");
КонецЦикла;
После выполнения этого кода планировщик при следующем запуске корректно передаст строковое значение в процедуру, и ошибка «недостаточно фактических параметров» исчезнет.
Чтобы избежать аварийного завершения задания в случаях, когда параметры по какой-то причине не были установлены (например, при запуске из сторонней консоли), рекомендуется использовать возможности языка 1С по заданию значений по умолчанию. Рассмотрим, как изменить сигнатуру процедуры:
// Вместо Процедура ЗаданиеОбменССайтом(КодНастройки) Экспорт
Процедура ЗаданиеОбменССайтом(КодНастройки = Неопределено) Экспорт
Если КодНастройки = Неопределено Тогда
// Логика определения настройки, если параметр не передан
КодНастройки = "ДЕФОЛТ";
ЗаписьЖурналаРегистрации("Обмен", УровеньЖурналаРегистрации.Предупреждение, , , "Параметр не задан, используется значение по умолчанию.");
КонецЕсли;
// Основной код обмена
// ...
КонецПроцедуры
Такой подход делает ваше задание более гибким и защищенным от ошибок человеческого фактора при настройке метаданных.
Разберем ситуацию, когда задание настроено верно, но оно просто не стартует. В файловой базе данных отсутствует сервер приложений, который выступает в роли планировщика. Поэтому выполнение регламентных заданий ложится на плечи клиентских сеансов. Проанализируем критические условия:
AllowExecuteScheduledJobs=Force.Если задание выполняется, но результат не тот, который ожидался, или вы хотите увидеть, какой именно «мусор» приходит в параметрах, воспользуемся механизмом отладки. Рассмотрим по шагам, как подключиться к фоновому процессу:
1. Откройте конфигуратор и перейдите в меню Отладка — Подключение...
2. В открывшемся окне нажмите кнопку Автоматическое подключение.
3. Установите флажок напротив пункта Фоновые задания и нажмите ОК.
4. Установите точку останова в самом начале процедуры ЗаданиеОбменССайтом.
Теперь, как только планировщик запустит задание (согласно расписанию или принудительно через консоль), конфигуратор автоматически «перехватит» этот поток, и вы сможете в табло (через Shift+F9) проанализировать значения всех переменных в контексте выполнения фонового задания.
Проанализируем ситуацию, если ваша конфигурация (даже на обычных формах) построена с использованием БСП. В этом случае работа напрямую через РегламентныеЗадания может игнорироваться системой. БСП часто хранит настройки заданий в собственных регистрах сведений или справочниках (например, «Дополнительные отчеты и обработки»).
В таких системах при запуске регламентного задания БСП может программно перезаписывать параметры объекта метаданных значениями из своих внутренних таблиц. Если вы изменили параметры кодом, приведенным выше, а при следующем запуске они «слетели», значит, нужно искать форму настройки самого обмена внутри пользовательского интерфейса программы («Администрирование» — «Обслуживание» — «Регламентные и фоновые задания»).
Для успешного запуска регламентного задания мы должны убедиться в выполнении трех условий: процедура должна быть Экспортной в модуле с установленным флагом «Сервер», количество параметров в коде должно строго соответствовать количеству элементов в массиве параметров метаданных, а для файлового режима — обеспечено наличие активного «сеанса-планировщика». Использование необязательных аргументов (= Неопределено) является лучшей практикой, позволяющей избежать внезапных остановок бизнес-процессов.