В процессе разработки в среде 1С:Предприятие 8 часто возникает необходимость использовать один и тот же программный код (метод) для выполнения различных задач по расписанию. Вместо того чтобы плодить десятки однотипных регламентных заданий, гораздо эффективнее научиться передавать в них параметры. Это позволяет динамически менять логику работы процедуры в зависимости от переданных входных данных. Рассмотрим подробно, как это реализовать, какие существуют нюансы и какие «подводные камни» могут встретиться на пути программиста.
Прежде чем переходить к коду, проанализируем, как работает механизм заданий в 1С. Важно понимать, что РегламентноеЗадание — это объект метаданных (или элемент в информационной базе), который по сути является лишь «хранилищем» расписания и настроек. Само выполнение кода всегда происходит в рамках фонового задания, которое порождается регламентным в момент наступления времени запуска. Это разделение критически важно для понимания того, как система прокидывает параметры внутрь исполняемого кода. Для организации работы с подобными процессами напрямую можно использовать пример управления фоновыми заданиями и получения результатов без БСП.
Это стандартный и наиболее очевидный способ. У объекта РегламентноеЗадание есть свойство Параметры, которое представляет собой Массив. Количество элементов в этом массиве должно строго соответствовать количеству аргументов в процедуре, которую вызывает задание.
Рассмотрим ситуацию: у нас есть процедура в общем модуле, которая должна обрабатывать данные по конкретной организации. Проанализируем пример кода процедуры:
Процедура ВыполнитьОбработкуДанных(СсылкаНаОрганизацию) Экспорт
// Логика обработки
Если ЗначениеЗаполнено(СсылкаНаОрганизацию) Тогда
ЗаписатьВЛог("Обработка запущена для: " + Строка(СсылкаНаОрганизацию));
Иначе
ЗаписатьВЛог("Обработка запущена для всех организаций");
КонецЕсли;
КонецПроцедуры
Чтобы передать параметр в эту процедуру через пользовательский интерфейс (например, в консоли заданий), нам нужно заполнить массив параметров. Если мы работаем программно, то создание и заполнение будет выглядеть следующим образом:
// Создаем новое регламентное задание на сервере
НовоеЗадание = РегламентныеЗадания.СоздатьРегламентноеЗадание("ОбработкаДанныхОрганизаций");
НовоеЗадание.Наименование = "Обработка по организации: " + ВыбраннаяОрганизация.Наименование;
// Добавляем параметр в массив (соответствует аргументу СсылкаНаОрганизацию)
НовоеЗадание.Параметры.Очистить();
НовоеЗадание.Параметры.Добавить(ВыбраннаяОрганизация);
НовоеЗадание.Записать();
Важный нюанс: параметры должны быть сериализуемыми. Это означает, что вы можете передавать простые типы (строки, числа, даты, булево), ссылки на объекты базы данных, структуры или другие массивы. Нельзя передавать объекты, существующие только в памяти (например, открытую форму или COM-объект).
Бывают случаи, когда вы не хотите менять сигнатуру метода (количество параметров в процедуре), но вам нужно понять, «кто» запустил это задание. В этом случае мы можем использовать свойство Ключ (Key). Разберем, как это работает через получение текущего фонового задания.
Внутри программного кода, который выполняется заданием, мы можем обратиться к методу ФоновыеЗадания.ПолучитьТекущееФоновоеЗадание(). У полученного объекта будут доступны свойства Ключ и Наименование, которые он унаследовал от родительского регламентного задания.
Рассмотрим пример реализации внутри метода:
Процедура МояПроцедураЗадания() Экспорт
// Получаем объект фонового задания, запущенного платформой
ТекущееЗадание = ФоновыеЗадания.ПолучитьТекущееФоновоеЗадание();
// Считываем ключ
ИдентификаторЗадачи = ТекущееЗадание.Ключ;
Если ИдентификаторЗадачи = "ЗагрузкаИзФайла" Тогда
// Выполняем одну логику
ИначеЕсли ИдентификаторЗадачи = "ЗагрузкаИзAPI" Тогда
// Выполняем другую логику
КонецЕсли;
КонецПроцедуры
Этот способ удобен тем, что свойство Ключ также управляет параллельностью. Если в системе уже выполняется фоновое задание с определенным ключом, платформа не запустит второе задание с таким же ключом до завершения первого. Это отличный способ избежать конфликтов при блокировке данных.
Если вы создаете свою форму управления регламентными заданиями, вам потребуется логика для редактирования параметров. Посмотрим на алгоритм, который позволяет пользователю видеть и изменять эти данные:
При открытии формы задания (чтение параметров в таблицу значений на форме):
Для Каждого ТекПарам Из РегламентноеЗадание.Параметры Цикл
НовСтр = ПараметрыНаФорме.Добавить();
НовСтр.Значение = ТекПарам;
КонецЦикла;
При записи изменений (сохранение из таблицы значений обратно в объект задания):
РегламентноеЗадание.Параметры.Очистить();
Для Каждого Стр Из ПараметрыНаФорме Цикл
РегламентноеЗадание.Параметры.Добавить(Стр.Значение);
КонецЦикла;
РегламентноеЗадание.Записать();
Проанализируем ситуацию, когда параметров очень много или они представляют собой сложные фильтры (например, настройки компоновки данных). Передавать огромный массив через свойство Параметры неудобно, так как это может привести к ошибкам кэширования или проблемам при отладке.
В профессиональной разработке часто применяют схему «Параметры в базе данных»:
НастройкиРегламентныхЗаданий).УникальныйИдентификатор задания или специальный текстовый код.ХранилищаЗначения).Выясним преимущества такого подхода: вы не ограничены типами данных 1С при сериализации массива параметров, можете легко менять настройки «на лету» без перезапуска или пересоздания самого задания, а также имеете историю настроек, если добавите в регистр периодичность.
Разберем типичную ошибку начинающих разработчиков: вы добавили в процедуру новый параметр (например, было Процедура(П1), стало Процедура(П1, П2)), обновили конфигурацию, но задание падает с ошибкой несоответствия количества параметров.
Причина кроется в кэшировании: в базе данных объект регламентного задания все еще хранит старый массив из одного элемента. Чтобы это исправить, необходимо:
Процедура Имя(П1, П2 = Неопределено). Однако помните, что в некоторых версиях платформы даже при наличии значений по умолчанию массив в задании все равно должен быть заполнен полностью.Мы рассмотрели три основных пути передачи данных: через прямой массив параметров (удобно для простых случаев), через свойство Ключ (идеально для идентификации типа задачи и контроля уникальности) и через вспомогательные таблицы в БД (для сложных систем). Выбор конкретного метода зависит от архитектуры вашего решения, но использование параметров — это всегда более гибкий путь, чем создание множества дублирующих друг друга объектов метаданных.