В практике администрирования и разработки на платформе 1С:Предприятие 8.3 часто встречается ситуация, когда регламентное или фоновое задание внезапно прекращает свою работу. При этом в журнале регистрации фиксируется комментарий: "Задание отменено пользователем". Это сообщение может вводить в заблуждение, так как зачастую ни один пользователь или администратор не инициировал отмену вручную. Давайте подробно разберем, почему система выдает такой статус и как найти истинную причину остановки процесса.
Рассмотрим наиболее вероятную причину, которая часто встречается при развертывании копий баз данных. В платформе 1С существует механизм защиты, который предотвращает нежелательное взаимодействие тестовых баз с внешними сервисами (рассылка почты, синхронизация с сайтами, обмен данными). Если база была перемещена на другой сервер или восстановлена из бэкапа, платформа предлагает пользователю выбрать: "Информационная база перемещена" или "Это копия информационной базы".
Если была выбрана опция "Это копия...", система автоматически включает блокировку регламентных заданий и работы с внешними ресурсами. Проанализируем, как это влияет на выполнение: фоновое задание может запуститься, но при попытке обращения к заблокированным механизмам платформа принудительно завершает сеанс с пометкой об отмене. Чтобы исправить это, выполним следующие действия:
Выясним причину, связанную с настройками самого регламентного задания. В консоли управления заданиями или непосредственно в метаданных конфигурации можно задать временные ограничения на выполнение процесса. Посмотрим на важные параметры:
Разберем пример: если задание по расчету себестоимости настроено на завершение в 08:00 утра, а данных оказалось слишком много, и расчет затянулся до 08:01, платформа выдаст ошибку отмены. Рекомендуется проанализировать длительность выполнения и увеличить эти интервалы с запасом.
Проанализируем ситуацию, связанную с программным свойством Ключ объекта ФоновоеЗадание. В 1С нельзя запустить одновременно два фоновых задания с одинаковым строковым ключом. Если второе задание инициируется в тот момент, когда первое с таким же ключом еще работает, платформа может повести себя по-разному в зависимости от контекста вызова, включая отмену текущего процесса или отказ в запуске нового.
Если в коде используется пустой ключ или статическая строка для разных экземпляров задания, это может привести к конфликтам. Проверьте программный код инициализации задания:
ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(ПараметрыОбмена);
// Если Ключ всегда одинаковый, возникнет конфликт
ФоновыеЗадания.Выполнить("МойМодуль.ВыполнитьОбмен", ПараметрыЗадания, "УникальныйКлючОбмена");
Для предотвращения подобных ситуаций старайтесь формировать уникальные ключи, например, добавляя к ним идентификатор узла обмена или время запуска.
Рассмотрим технические факторы на стороне кластера серверов 1С. В консоли администрирования (mmc) для рабочего процесса rphost могут быть установлены жесткие ограничения. Если фоновое задание начинает потреблять память сверх лимита "Безопасный расход памяти за один вызов", менеджер кластера убивает поток выполнения. На старых версиях платформы (например, 8.3.8) такое аварийное завершение процесса часто фиксировалось именно как отмена пользователем.
Чтобы исключить этот фактор, необходимо выполнить диагностику:
Разберем так называемое "демоническое" обновление. Когда администратор обновляет конфигурацию базы данных в режиме "Динамически", платформа пытается сохранить целостность данных. Если изменения затрагивают программные модули, которые используются в данный момент работающим фоновым заданием, система может принудительно остановить сеанс задания. После завершения обновления сессии сбрасываются, и в журнале появляется запись об отмене. Мы рекомендуем избегать динамических обновлений в моменты интенсивной работы регламентных заданий.
Иногда причина кроется внутри самой конфигурации. Разработчики могут использовать метод ФоновыеЗадания.Отменить() по определенному условию. Посмотрим на пример логики, которая может привести к внезапной остановке:
Задания = ФоновыеЗадания.ПолучитьФоновыеЗадания(Новый Структура("Наименование", "ЗагрузкаДанных"));
Для Каждого Задание Из Задания Цикл
Если Задание.Состояние = СостояниеФоновогоЗадания.Активно Тогда
// Проверка условия актуальности
Если НужноПрерватьСтаруюЗагрузку() Тогда
Задание.Отменить();
КонецЕсли;
КонецЕсли;
КонецЦикла;
В этом случае система честно пишет, что задание отменено, так как инициатором выступил программный код, работающий от имени пользователя, под которым запущен основной процесс.
Если вышеперечисленные способы не помогли, воспользуемся самым мощным инструментом — Технологическим журналом (ТЖ). Нам необходимо настроить сбор событий EXCP и CANCEL, а также рассмотреть внешние системы сбора и анализа ошибок.
Пример файла настроек logcfg.xml для поиска причины отмены (для удобства чтения можно убрать лишние переносы строк в событиях ТЖ):
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\CANCEL_JOBS" history="24">
<event>
<eq property="Name" value="CANCEL"/>
</event>
<event>
<eq property="Name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
Проанализировав логи ТЖ, мы сможем увидеть, какой именно процесс или поток инициировал событие CANCEL. Часто там можно обнаружить реальную причину: например, разрыв соединения с SQL Server или ошибку Access Violation в рабочем процессе rphost.
Подведем итог: ошибка "Задание отменено пользователем" является универсальным статусом платформы 1С для любого случая, когда выполнение было прервано не из-за внутренней ошибки кода (Runtime Error), а по внешней команде или из-за нарушения регламента. Проверяйте в первую очередь блокировку внешних ресурсов и настройки лимитов времени в расписании — в 90% случаев причина кроется именно там.