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

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

Разберем современные возможности: платформа 8.3.23 и новее

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

1. Прямое добавление в метаданные: Теперь объект РегламентноеЗадание можно добавить прямо в дерево метаданных вашего расширения. Больше не нужно придумывать сложные схемы или использовать справочники дополнительных обработок.
2. Настройка области действия: При создании задания в расширении вы можете управлять его областями действия. Если выбрать настройку Информационная база, задание будет функционировать глобально, как если бы оно находилось в основной конфигурации. Если же указать Область данных, выполнение будет ограничено только той областью, к которой подключено расширение. Это критически важно для работы в облачных средах (например, 1С:Фреш).
3. Улучшенный конструктор запросов: Начиная с релиза 8.3.23, в конструкторе запросов для расширений появилась возможность видеть все таблицы и поля основной конфигурации. Если вы обращаетесь к объектам, которых еще нет в расширении, платформа автоматически предложит их добавить при сохранении.

Проанализируем обходные пути для старых версий платформы (до 8.3.23)

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

Вариант 1: Использование механизма дополнительных отчетов и обработок (БСП)

Вместо того чтобы пытаться добавить метаданные в расширение, логику работы выносят во внешнюю обработку. Библиотека стандартных подсистем (БСП) имеет встроенный справочник дополнительных отчетов и обработок. Посмотрим на алгоритм действий:

1. Создаем внешнюю обработку, содержащую необходимый исполняемый код.
2. Регистрируем ее в справочнике дополнительных обработок в пользовательском режиме.
3. В настройках справочника задаем расписание выполнения (по сути, настраиваем регламентное задание средствами БСП).

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

Вариант 2: Метод «Пустышки» с минимальным изменением конфигурации

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

1. В основной конфигурации создаем объект РегламентноеЗадание (пустышку).
2. В качестве метода исполнения указываем процедуру в общем модуле, который также добавляем в основную конфигурацию.
3. В процедуре оставляем пустой код или базовый вызов.
4. В расширении конфигурации перехватываем этот метод общего модуля (например, с помощью аннотации &Вместо или &После) и уже там пишем реальную бизнес-логику.

Пример перехвата вызова в модуле расширения:

&Вместо("ВыполнитьФоновуюЗадачу")
Процедура Расш_ВыполнитьФоновуюЗадачу()
    // Здесь размещаем весь полезный код нашего регламентного задания
    // Основная конфигурация при этом содержит только пустую процедуру-заглушку
    ВыполнитьОбработкуДанных();
КонецПроцедуры

Оба обходных пути активно использовались на практике, однако с переходом на версию 8.3.23 необходимость в них отпадает. Рекомендуем использовать штатный функционал расширений, что сделает архитектуру ваших решений более прозрачной и надежной.