Как перенести и настроить регламентные задания при переходе между файловой и клиент-серверной базой 1С?

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

Разница между предопределенными и непредопределенными заданиями

Для понимания логики переноса разберем, как платформа 1С разделяет регламентные задания по способу их создания:

1. Предопределенные регламентные задания. Создаются разработчиком непосредственно в дереве метаданных конфигуратора. Для них задаются имя метода, расписание по умолчанию и признак использования. При обновлении конфигурации через файл .cf такие задания создаются платформой автоматически и сразу готовы к исполнению.
2. Непредопределенные регламентные задания. Создаются динамически в пользовательском режиме (программно через менеджер регламентных заданий либо интерактивно через типовые панели администрирования и специализированную «Консоль заданий»). Экземпляры таких заданий хранятся в таблицах базы данных. При обычном объединении или обновлении структуры конфигурации через файл .cf они автоматически в целевую базу не переносятся.

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

Перенос метаданных (.cf) против полного переноса базы (.dt)

Проанализируем два сценария миграции заданий между файловой и серверной базами:

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

Сценарий 2: Перенос только конфигурации (файл .cf).
Если базы объединяются или обновляются через .cf, в целевую базу переносится только программный код и состав предопределенных заданий. Настройки расписания непредопределенных заданий потребуется перенести через код. Посмотрим на пример программного чтения и создания регламентного задания:

// Создание нового регламентного задания в пользовательском режиме
НовоеЗадание = РегламентныеЗадания.СоздатьРегламентноеЗадание("ИмяМетаданныхЗадания");
НовоеЗадание.Наименование = "Регулярная обработка данных";
НовоеЗадание.Использование = Истина;

// Настройка расписания
Расписание = Новый РасписаниеКлиентСервер;
Расписание.Периодичность = 86400; // Каждый день
НовоеЗадание.Расписание = Расписание;

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

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

Особенности выполнения заданий в файловом режиме платформы 8.3

В платформе 1С:Предприятие 8.2 для файловых баз требовалось использовать периодический вызов ПодключитьОбработчикОжидания и метод ВыполнитьОбработкуЗаданий в коде главного модуля. Начиная с версии 8.3, исполнение регламентных процедур встроено в саму платформу, однако имеет важные ограничения:

1. Наличие активных сеансов. Файловая информационная база представляет собой файл на диске. Если в базу никто не вошел, исполняемый код платформы не работает, и регламентные задания выполняться не будут.
2. Распределение нагрузки. По умолчанию один из запущенных пользовательских клиентов берет на себя роль диспетчера и исполняет задания в фоновых потоках. Это может приводить к снижению отзывчивости интерфейса у данного пользователя и дополнительному сетевому трафику.
3. Выделенный клиент и параметры запуска. Чтобы обеспечить гарантированное выполнение заданий и снять нагрузку с пользователей, на сервере (или компьютере, где лежит файл базы) запускают постоянный сеанс «1С:Предприятия». Для явного управления поведением сеанса используется ключ командной строки /AllowExecuteScheduledJobs:
   — /AllowExecuteScheduledJobs -Force — принудительно назначает текущий клиентский сеанс ответственным за запуск регламентных заданий;
   — /AllowExecuteScheduledJobs -Off — запрещает данному сеансу (например, обычному пользователю) выполнять регламентные процедуры;
   — /AllowExecuteScheduledJobs -On — стандартный режим автоматического участия сеанса в распределении задач.
4. Исполнение через веб-сервер. Если файловая база опубликована на веб-сервере (Apache или IIS), регламентные задания могут выполняться процессами веб-сервера при наличии входящих веб-запросов и активного пула соединений без необходимости держать открытым толстый или тонкий клиент.

Особенности выполнения заданий в клиент-серверном режиме

В клиент-серверном варианте регламентные задания исполняются службой кластера серверов 1С (процессом ragent / rphost). Это обеспечивает их независимость от присутствия пользователей в системе, но добавляет специфические серверные требования:

1. Блокировка регламентных заданий в свойствах базы. В консоли администрирования кластера серверов 1С для каждой базы существует флаг «Блокировка регламентных заданий включена». Если база была развернута из резервной копии или создана заново, этот флаг может быть активен, блокируя запуск любых заданий по расписанию. Выясним его состояние перед началом работы.
2. Контекст файловой системы и учетная запись службы. Код регламентного задания исполняется на стороне сервера от имени системного пользователя, под которым работает служба 1С (например, usr1cv8). Все локальные пути (вида C:\Exchange\) будут указывать на диски сервера, а не клиентского ПК. Для работы с сетевыми ресурсами (UNC-пути) службе сервера 1С должны быть предоставлены соответствующие права доступа.
3. Разрядность и внешние библиотеки. Если сервер 1С является 64-разрядным, регламентные задания не смогут работать с 32-разрядными COM-объектами, внешними компонентами и DLL напрямую. Потребуется обновление библиотек до 64 бит либо их настройка через службу компонентов операционной системы.
4. Контекст пользователя и RLS. Если в свойствах регламентного задания не указан конкретный пользователь 1С, задание на сервере выполняется в привилегированном режиме с игнорированием ограничений на уровне записей (RLS). Если алгоритм фонового задания опирается на индивидуальные права, пользователя необходимо явно указать в свойствах задания.

Пошаговый чеклист переноса

Разберем последовательность действий при переносе заданий из файлового режима в клиент-серверный:

1. Проверяем код процедур на отсутствие клиентских методов, модальных вызовов и некорректных локальных путей к файлам.
2. Переносим конфигурацию (через файл .cf) либо всю базу целиком (через файл .dt).
3. Если переносилась только конфигурация — открываем «Консоль регламентных заданий» или форму администрирования и восстанавливаем непредопределенные задания и их расписания.
4. В консоли кластера серверов 1С проверяем свойства информационной базы и убеждаемся, что снят флаг «Блокировка регламентных заданий включена».
5. Проверяем доступность сетевых ресурсов для учетной записи службы сервера 1С.