При переходе с файлового варианта базы на серверный многие разработчики и администраторы сталкиваются с ситуацией: регламентные задания перестают выполняться автоматически. В файловой базе все работало корректно, в серверной — задания запускаются вручную через консоль, но игнорируют установленное расписание. Рассмотрим подробно, почему это происходит, и разберем по шагам все возможные причины, от самых простых настроек до глубоких технических нюансов платформы 1С:Предприятие.
Первым делом проанализируем настройки информационной базы в консоли администрирования кластера серверов 1С. Это самая распространенная причина: при создании базы или переносе данных часто устанавливается защитный механизм, блокирующий автоматическую активность.
Выясним причину, проверив параметры базы:
Если эта галка установлена, платформа игнорирует любые расписания. Ее необходимо снять и нажать «ОК». Часто это сразу решает проблему, как и произошло в рассматриваемом нами случае.
Если блокировка снята, но задания все равно не стартуют, нам нужно убедиться, что само задание настроено верно. Разберем ситуацию, когда задание выполняется только один раз. Проанализируем строку расписания.
Иногда в конфигураторе или консоли заданий устанавливается ограничение «один раз в день». Например, если указано с 4:30:25 один раз в день, то после успешного выполнения в 4:30 система будет ждать следующего дня. Чтобы задание выполнялось периодически, проверим вкладку «Дневное» и убедимся, что установлен интервал (например, повторять каждые 3600 секунд для ежечасного запуска).
Также важно понимать статус задания в метаданных. В «самописных» конфигурациях убедимся, что у объекта РегламентноеЗадание установлены свойства:
Иногда полезно выполнить программную инициализацию, если задание не «подхватилось» платформой автоматически:
Менеджер = РегламентныеЗадания.НайтиПредопределенное("МоеРегламентноеЗадание");
Если Менеджер <> Неопределено Тогда
Менеджер.Использование = Истина;
Менеджер.Записать();
КонецЕсли;
Часто в коде, который отлично работал в файловом варианте, содержатся ошибки, недопустимые для серверного контекста. Выясним, нет ли в модуле задания обращения к элементам интерфейса. В серверном режиме 1С:Предприятие не существует понятия «экран», «диалог» или «клиент». Любая попытка вызвать интерактивное действие приведет к немедленному аборту фонового процесса.
Проанализируем код на наличие следующих функций:
Предупреждение();Вопрос();Сообщить() (в некоторых старых версиях платформы или специфических контекстах);&НаКлиенте.Рассмотрим пример правильного серверного метода в общем модуле. Убедимся, что у модуля стоят галочки «Сервер» и «Вызов сервера» (если нужно), а сам код не пытается открыть форму:
Процедура ВыполнитьОбменДанными() Экспорт
// Только логика работы с данными
ЗаписьЖурналаРегистрации("РегламентноеЗадание", УровеньЖурналаРегистрации.Информация, , , "Начало обмена");
// ... тело процедуры ...
ЗаписьЖурналаРегистрации("РегламентноеЗадание", УровеньЖурналаРегистрации.Информация, , , "Конец обмена");
КонецПроцедуры
Посмотрим на ситуацию со стороны системного администрирования. В кластере 1С существуют параметры, ограничивающие количество фоновых заданий. Если сервер перегружен или настройки слишком жесткие, новые задания встают в очередь и не запускаются.
Проверим в консоли администрирования параметры рабочего сервера:
Если лимит достигнут, rphost просто не создаст новый поток для вашего задания. Также стоит проверить лицензирование. Несмотря на то, что фоновые задания не занимают клиентскую лицензию в привычном смысле, отсутствие свободных лицензий на сервере или проблемы с ключом защиты сервера могут блокировать запуск менеджера заданий.
Разберем важный технический момент: под кем запускается задание? В серверном варианте это всегда учетная запись, от которой работает служба 1C:Enterprise 8.3 Server Agent (обычно это USR1CV8). У этой записи часто не хватает прав на внешние ресурсы.
Проанализируем следующие права для пользователя ОС USR1CV8:
Temp на сервере.AppData в профиле пользователя службы.Рекомендуется добавить процессы ragent.exe, rmngr.exe и rphost.exe в исключения антивируса, чтобы исключить блокировку сетевой активности и работы с временными файлами.
Если визуально всё настроено верно, но результат отсутствует, обратимся к средствам диагностики. Посмотрим, фиксирует ли система попытки запуска.
Откроем Журнал регистрации и установим отбор по событию «Фоновое задание». Если задание запускалось и упало с ошибкой, здесь будет подробное описание (например, «Метод не найден» или «Ошибка компиляции модуля»).
Также крайне полезно использовать обработку «Консоль заданий». В ней можно увидеть:
Попробуем пересоздать расписание именно через Консоль заданий, а не в конфигураторе. Практика показывает, что иногда запись настроек напрямую в базу через менеджер регламентных заданий помогает «оживить» застрявшее задание:
Задание = РегламентныеЗадания.НайтиПредопределенное("МоеЗадание");
Задание.Использование = Ложь;
Задание.Записать();
// Пауза и повторное включение
Задание.Использование = Истина;
Задание.Расписание = НовоеРасписание; // если нужно обновить
Задание.Записать();
В завершение проанализируем состояние серверов. Регламентные задания критично зависят от системного времени. Если время на сервере приложений 1С расходится с временем на сервере СУБД (например, MS SQL Server) более чем на несколько минут, менеджер заданий может работать непредсказуемо.
Если ничего не помогает, разберем радикальный, но действенный метод: перезапуск службы сервера 1С. В процессе работы менеджер заданий в памяти процесса rmngr может «подвиснуть». Перезапуск службы очищает очередь и заново инициирует все расписания. В рабочих условиях это лучше делать в технологическое окно, предварительно завершив сеансы пользователей.
Таким образом, решение проблемы всегда кроется в последовательной проверке: от галочки блокировки в консоли до прав доступа в операционной системе и чистоты кода в общем модуле.