В современных конфигурациях 1С, таких как Управление торговлей 11, работа с регламентными заданиями реализована значительно сложнее, чем в старых версиях платформы. Особенно это касается внешних (дополнительных) обработок. Распространенная ситуация: вы изменили время старта с 9:00 на 10:00, но система продолжает упорно запускать обработку и в 9, и в 10 утра. Давайте подробно разберем, почему планировщик «запоминает» старые значения и как полностью очистить систему от фантомных запусков.
Первое, что мы должны понять: в УТ 11 регламентные задания для дополнительных обработок часто работают не через стандартный объект метаданных РегламентныеЗадания, а через специальный механизм Библиотеки Стандартных Подсистем (БСП) — Очередь заданий. Когда вы настраиваете расписание для внешней обработки, система создает запись в регистре сведений.
Разберем, как это функционирует. Вместо прямого вызова, планировщик платформы запускает одно общее задание «Мониторинг задач очереди», которое проверяет регистр РегистрСведений.ОчередьЗаданий. Если при редактировании или переустановке обработки произошел сбой, в этом регистре может остаться старая запись, привязанная к тому же объекту, но с прежним расписанием.
Проанализируем ситуацию программно. Чтобы найти «лишнее» задание, нам потребуется консоль запросов или обработка для просмотра регистров. Нам нужно проверить содержимое регистра РегистрСведений.ОчередьЗаданий. Если мы обнаружим там две строки для нашей обработки, одну из них (со старым временем) необходимо удалить.
// Пример логики поиска дублей в очереди заданий (условно)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОчередьЗаданий.ИмяМетода,
| ОчередьЗаданий.Использование,
| ОчередьЗаданий.Расписание
|ИЗ
| РегистрСведений.ОчередьЗаданий КАК ОчередьЗаданий
|ГДЕ
| ОчередьЗаданий.ИмяМетода ПОДОБНО ""%ИмяВашейОбработки%""";
Второй важный аспект — работа планировщика в клиент-серверном варианте. За запуск фоновых заданий отвечает процесс rmngr (менеджер кластера). Он хранит таблицу расписаний в оперативной памяти и в специальных файлах сеансовых данных. Иногда стандартное удаление регламентного задания через интерфейс 1С не приводит к моментальному обновлению данных в памяти менеджера кластера.
Разберем по шагам процесс глубокой очистки планировщика:
C:\Program Files\1cv8\srvinfo).reg_1541) и внутри нее папку snccntx. В этой директории хранятся данные сеансов и кэш планировщика.snccntx. Внимание: это приведет к завершению всех активных сеансов, поэтому процедуру нужно проводить в техническое окно.rmngr перечитать актуальную структуру заданий из базы данных SQL, игнорируя старые «фантомные» записи.Часто программисты забывают, что при обновлении внешней обработки через файл система может создать новый внутренний идентификатор (GUID). Рассмотрим ситуацию: у вас в справочнике ДополнительныеОтчетыИОбработки зарегистрирована одна запись. Вы загрузили новую версию, и из-за ошибки в базе появилось две записи с одинаковым наименованием, но разными UUID. Одна из них помечена на удаление, но регламентное задание от нее все еще «живет» в системных таблицах.
Выясним причину через консоль заданий. Используйте стандартную обработку Консоль заданий (ее можно найти на ИТС). В ней нужно смотреть не только на вкладку «Регламентные задания», но и на вкладку «Фоновые задания». Если в 9:00 запускается фоновое задание, посмотрите его колонку «Родительское задание». Так вы узнаете уникальный идентификатор (ID) того регламентного задания, которое инициирует запуск. Сравните этот ID с тем, что вы видите в списке активных заданий. Если они разные — в системе существует скрытое задание.
Если визуальные средства не помогают, проанализируем ситуацию с помощью Технологического журнала (ТЖ). Это самый надежный способ узнать, кто именно инициирует запуск процесса. Нам нужно настроить сбор события JOB. Создайте файл logcfg.xml в папке conf сервера 1С со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\JOB_LOGS" history="24">
<event>
<eq property="Name" value="JOB"/>
</event>
<property name="all"/>
</log>
</config>
Дождитесь 9:00 и изучите лог. В нем будет зафиксировано событие старта фонового задания с указанием имени регламентного задания и его ScheduledJobID. Получив этот ScheduledJobID, вы сможете найти его в SQL-таблице _ScheduledJobs или программно через объект РегламентныеЗадания, используя метод НайтиПоУникальномуИдентификатору().
В самых тяжелых случаях, когда в интерфейсе 1С задания не видно, а оно продолжает выполняться, придется заглянуть «под капот» базы данных. Регламентные задания хранятся в системной таблице _ScheduledJobs.
Важно: Любые прямые изменения в SQL-таблицах крайне не рекомендуются и могут привести к потере поддержки или повреждению данных. Однако, для диагностики мы можем выполнить SELECT запрос, чтобы убедиться в наличии «фантомных» строк, которые не отображаются в дереве метаданных или через МенеджерРегламентныхЗаданий.
Если вы нашли ID фантомного задания, удалите его программно. Рассмотрим пример кода, который поможет очистить систему от ненужного задания, если вы знаете его часть имени или метаданные:
// Программный поиск и удаление всех заданий с определенным именем
Задания = РегламентныеЗадания.ПолучитьРегламентныеЗадания();
Для Каждого Задание Из Задания Цикл
Если Найти(Задание.Метаданные.Имя, "ИмяВашегоЗадания") > 0 Тогда
// Проверяем расписание или другие признаки
Сообщить("Найдено задание: " + Задание.УникальныйИдентификатор);
// Если это лишнее задание - удаляем
// Задание.Удалить();
КонецЕсли;
КонецЦикла;
Посмотрите внимательно на использование метода Удалить(). Перед его вызовом обязательно убедитесь, что вы нашли именно то задание, которое создает проблему. Мы рекомендуем сначала выводить информацию о расписании каждого найденного задания в консоль сообщений, чтобы не удалить рабочую настройку.
Подведем итоги. Если регламентное задание внешней обработки в УТ 11 запускается по старому расписанию, действуйте по следующему алгоритму:
snccntx) с перезапуском службы 1С.Помните, что в распределенных базах или при использовании механизма «Разделение данных» (фреш), задание может быть зарегистрировано в конкретной области данных. Убедитесь, что вы проверяете настройки именно в той области (или под тем пользователем), где происходит двойной запуск.