Как передать параметры в регламентное задание 1С

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

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

Ниже разобраны оба подхода, ограничения на типы параметров, способы отладки обработчика с параметрами и типичные ошибки, из-за которых задание «молча» не выполняется или падает с ошибкой.

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

Каждое регламентное задание связано с методом — экспортной процедурой или функцией общего модуля. Имя метода хранится в свойстве ИмяМетода в формате «ИмяОбщегоМодуля.ИмяПроцедуры». Когда планировщик запускает задание, платформа вызывает этот метод и передаёт в него элементы массива Параметры как аргументы — первый элемент становится первым параметром процедуры, второй — вторым и так далее.

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

Массив параметров сериализуется и хранится в базе, поэтому в него можно помещать только сериализуемые значения: примитивные типы (строка, число, дата, булево), ссылки на объекты базы данных, структуры, массивы, хранилище значения. Несериализуемые объекты — например, открытые соединения, COM-объекты, объекты типа «Запрос» с установленными параметрами — передать нельзя.

Настройка метода-обработчика под приём параметров

Обработчик регламентного задания размещается в общем модуле. Модуль должен быть серверным, а если задание работает в файловой базе или требует привилегированного доступа — обычно включают флажки «Сервер» и «Привилегированный режим». Нельзя размещать обработчик в модуле с флажком «Клиент», потому что фоновое задание выполняется на сервере без клиентского контекста.

Процедура объявляется с ключевым словом «Экспорт» и с параметрами в том порядке, в котором они будут лежать в массиве. Типовой шаблон выглядит так:

Процедура ВыполнитьОбменДанными(УзелОбмена, ВыводитьСообщения = Ложь) Экспорт
Если Не ЗначениеЗаполнено(УзелОбмена) Тогда
ВызватьИсключение "Не указан узел обмена для регламентного задания";
КонецЕсли;
// логика обмена
КонецПроцедуры

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

Передача параметров при программном создании задания

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

НовоеЗадание = РегламентныеЗадания.СоздатьРегламентноеЗадание("ВыполнениеОбменаДанными");
НовоеЗадание.Наименование = "Обмен с филиалом ""Север""";
НовоеЗадание.Использование = Истина;
НовоеЗадание.Расписание = ПостроенноеРасписание;

ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(УзелОбменаСсылка);
ПараметрыЗадания.Добавить(Истина);
НовоеЗадание.Параметры = ПараметрыЗадания;

НовоеЗадание.Записать();

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

После вызова Записать() параметры физически сохраняются в базе. До записи задание существует только в памяти, и планировщик о нём не знает. Это частая причина ситуации «код отработал без ошибок, но задание не запускается».

Задание = РегламентныеЗадания.НайтиПредопределенное(Метаданные.РегламентныеЗадания.ВыполнениеОбменаДанными);
ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(Справочники.Настройки.ОсновнаяНастройка);
Задание.Параметры = ПараметрыЗадания;
Задание.Записать();

Изменение параметров предопределённого задания

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

Задание = РегламентныеЗадания.НайтиПредопределенное(
Метаданные.РегламентныеЗадания.МоеРегламентноеЗадание);

Если Задание = Неопределено Тогда
ВызватьИсключение "Предопределённое задание не найдено";
КонецЕсли;

ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(ДатаНачалаВыгрузки);
ПараметрыЗадания.Добавить(КоличествоДней);
Задание.Параметры = ПараметрыЗадания;
Задание.Записать();

Альтернатива — поиск по уникальному идентификатору через РегламентныеЗадания.НайтиПоУникальномуИдентификатору(), если идентификатор известен и сохранён где-то в настройках. Для предопределённых заданий предпочтителен поиск через метаданные: он устойчив к переименованию задания администратором.

В типовых конфигурациях на БСП (Библиотека стандартных подсистем) изменение параметров часто выполняется через процедуру РегламентныеЗаданияСервер.УстановитьПараметрыРегламентногоЗадания() или через форму настройки заданий в разделе администрирования. Если конфигурация построена на БСП, используйте её механизмы, а не прямую запись — это сохранит совместимость с обновлениями.

1. 1
   Создайте общий серверный модуль и экспортную процедуру с нужным числом параметров
2. 2
   Добавьте в конфигураторе регламентное задание и укажите имя метода в формате Модуль.Процедура
3. 3
   Программно найдите или создайте задание и заполните массив Параметры
4. 4
   Вызовите Записать() и убедитесь, что задание включено (Использование = Истина)
5. 5
   Запустите задание вручную через ВыполнитьСейчас или консоль заданий и проверьте журнал регистрации

Какие типы данных можно передавать, а какие нельзя

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

Если набор настроек велик или часто меняется, правильнее передавать не сами значения, а ссылку на элемент справочника настроек или запись регистра сведений. Тогда администратор меняет настройки в привычном интерфейсе, а задание при каждом запуске читает актуальные данные. Это устраняет необходимость переписывать параметры задания кодом при каждом изменении.

Отладка и проверка передачи параметров

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

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

Полезный приём — в начале обработчика записывать в журнал регистрации полученные параметры через ЗаписьЖурналаРегистрации(). Тогда по журналу видно, что именно задание получило при запуске, и рассинхронизация между массивом параметров и сигнатурой процедуры обнаруживается сразу.

Типичные ошибки и ограничения

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

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

Третья группа — забытый Записать() после изменения параметров и попытка передать несериализуемые объекты. Оба случая не всегда дают явную ошибку в момент настройки, но приводят к тому, что задание работает со старыми параметрами или не работает вовсе.

Альтернативы: когда параметры задания не нужны

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

Для разовых задач с динамическими параметрами уместнее фоновые задания через ФоновыеЗадания.Выполнить() или длительные операции БСП — там массив параметров передаётся непосредственно при вызове и не хранится в базе. Регламентное задание стоит использовать именно для периодических процессов.

Частые вопросы