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

Главный нюанс работы регламентных заданий в файловых базах 1С

В файловой базе 1С регламентные задания работают почти так же, как в клиент-сервере, но им жизненно нужен один специально запущенный сеанс, который не выключается и спокойно крутит задания в фоне. Основная задача разработчика — правильно написать задание, грамотно его расписать и обеспечить этому «дежурному» сеансу комфортные условия существования.

Что такое регламентные задания в 1С

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

Разработка регламентных заданий для разных режимов работы 1С

Хорошая новость: разрабатывать регламентные задания для файловой базы вы будете точно так же, как и для клиент-серверной. Те же объекты конфигурации, те же обработчики, та же логика, те же настройки расписания — никаких особых «файловых режимов» в модуле регламентного задания не появляется. Поэтому если вы уже написали пару простых регламентных заданий в учебной клиент‑серверной базе, в файловой всё это переносится без сюрпризов. Разница начинается не в момент написания кода, а в момент, когда дело доходит до запуска и сопровождения.

Главная особенность – нужен активный сеанс 1С

В файловой базе нет сервера 1С, который круглосуточно дежурит и крутит задания. Поэтому вся магия возможна только при одном условии: в базе должен быть хотя бы один активный сеанс, запущенный и не закрытый. Если база лежит на сетевом диске и все вышли с работы, фоновые и регламентные задания просто не выполняются — им банально некому работать. Отсюда первое правило: если хотите, чтобы что‑то выполнялось ночью по расписанию, организуйте специальный сеанс 1С, который будет жить сам по себе и не зависеть от пользователей. Это основа основ, без неё дальше вообще говорить не о чем.

Стратегия: выделенный клиентский сеанс 1С для регламентных заданий

Во файловом варианте нужно создать выделенный клиентский сеанс, который будет заниматься только выполнением фоновых заданий, и больше ничем. В этом сеансе в клиентском процессе должна периодически вызываться функция глобального контекста ВыполнитьОбработкуЗаданий(), именно она запускает механизм фоновых заданий. Важный момент: такой сеанс должен быть один на информационную базу — только один клиентский сеанс имеет право обрабатывать фоновые задания и вызывать эту функцию. Если вы забыли его создать, при программном доступе к механизму заданий получите знакомую ошибку: «Менеджер заданий не активен» — и задания не запустятся. Казалось бы, мелочь, а по факту половина проблем «ничего не крутится ночью» упирается именно в отсутствие этого выделенного сеанса.

В типовых конфигурациях 1С в файловом режиме работы первый запущенный сеанс в 1С автоматически будет обрабатывать регламентные задания. Дополнительно ничего программировать не требуется!

Очень соблазнительно: запустил 1С под своей учёткой, поставил ВыполнитьОбработкуЗаданий() где-нибудь, и параллельно работаешь в той же базе. Формально оно даже какое‑то время проживёт. Но так делать не стоит. В официальных рекомендациях прямо говорится: не рекомендуется использовать клиентский сеанс, выполняющий обработку фоновых заданий, для других функций. Любые модальные окна, запросы подтверждений, лишние блокировки от пользователя будут мешать фоновым задачам. В реальной жизни это проявляется так: «почему‑то ночью обмен не отработал», а утром выясняется, что накануне пользователь оставил открытое модальное окно, либо «висит» форма, ждущая ввода. Поэтому выделенный сеанс — значит действительно выделенный. Никаких «я заодно чуть‑чуть поработаю».

Как запускать этот сеанс?

Технически у вас несколько вариантов. Самый простой — запустить 1С руками на отдельной машине (или сервере) и не закрывать. Но это человеческий фактор: кто‑то обязательно выключит компьютер «чтоб не жужжал». Более надёжный вариант — использовать планировщик Windows (Task Scheduler) и запускать клиент 1С с нужными параметрами: путь к 1cv8.exe или 1cv8c.exe, ключ /F с путём к базе, /N и /P для пользователя и пароля, плюс команда, которая внутри уже организует вызов ВыполнитьОбработкуЗаданий() и завершение работы. Так вы получаете контролируемый старт и завершение сеанса в нужное время. Важно сразу договориться с админами: эта задача — священная, её не выключают ночью «для экономии электричества».

Где вызывать метод ВыполнитьОбработкуЗаданий()?

До вызова функции глобального контекста ВыполнитьОбработкуЗаданий() нужно добраться кодом: это может быть отдельная обработка, внешний файл, общий модуль с экспортной процедурой. Запускаете 1С через планировщик, указываете выполнение нужной обработки — она, в свою очередь, вызывает ВыполнитьОбработкуЗаданий() на определённое время. В файловом варианте именно этот вызов и делает ваш сеанс «сеансом обработчика фоновых заданий». Остальные клиентские процессы после запуска такого сеанса получают возможность программного доступа к механизму фоновых заданий: запускать, останавливать и управлять ими. Если «дежурный» сеанс не поднят — никакой программный доступ к менеджеру заданий работать не будет, сколько ни пробуйте.

Как работает ВремяОбработки и модальное окно

В тонком клиенте и веб‑клиенте при выполнении ВыполнитьОбработкуЗаданий() платформа может показывать модальный диалог с кнопкой «Прервать». Нажмёте кнопку — цикл обработки заданий будет прерван, то есть ваш фоновой процесс завершит обработку раньше времени. Отображение этого окна зависит от параметра ВремяОбработки: если он не указан или равен 0, модальный диалог не отображается, и обработка идёт без лишних окон. В автоматическом режиме (через планировщик) это, как правило, самый удобный вариант: задали разумное время обработки, убрали модальные окна, дали сеансу спокойно отработать и завершиться. Главное — не забывайте тестировать это не только из конфигуратора, но и «как живой пользователь» в тонком клиенте, чтобы увидеть, не всплывает ли что‑то лишнее.

Как красиво завершать работу сеанса

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

Дополнительная информация по работе с регламентными заданиями в 1С

Чисто человеческий момент. В какой‑то момент вы поймаете себя на том, что больше времени тратите не на написание кода регламентных заданий, а на организацию инфраструктуры вокруг них: какой пользователь запускает, на какой машине, какие права, кто дежурит, если что‑то «упало». И тут внезапно становится понятно, что хороший программист 1С — это не только «умеет писать запросы», но и думает, как люди будут жить с его решениями годами. Очень отрезвляет, когда ночью падает обмен, а утром вас встречают не лог‑файлы, а живая бухгалтерия.

Самая частая ошибка — забыли про выделенный сеанс и удивляются сообщению «Менеджер заданий не активен» при попытке управлять заданиями из кода. Вторая — используют тот же сеанс и для фоновых задач, и для обычной работы: кто‑то зашёл, открыл пару форм, повис в модальном диалоге, и ночью задания не отработали. Третья — неправильно настроенное расписание: задания запускаются не в то время, пересекаются друг с другом, держат блокировки дольше, чем надо. Четвёртая — отсутствие логирования: «задание не сработало», но журнал регистрации молчит, а разработчик не предусмотрел никакой записи о начале и завершении. Все эти вещи лечатся дисциплиной и привычкой всё проверять по шагам.

Прежде чем полагаться на регламентное задание в боевой файловой базе, отладьте его в тестовой: запустите вручную, посмотрите, как оно ведёт себя при разных исходных данных. Затем проверьте запуск через планировщик Windows: корректно ли передаются параметры, под каким пользователем идёт запуск, есть ли права к каталогу базы. Отдельно проверьте сценарий, когда задание отрабатывает дольше обычного: не мешает ли это пользователям, не создаёт ли длинных эксклюзивных блокировок. И, конечно, убедитесь, что при падении задания вы всё равно получаете какую‑то информацию — хотя бы запись в свой служебный регистр логов или файл.

Когда базовая схема с регламентными заданиями в файловой базе освоена, можно потихоньку наращивать сложность: распределять задачи по ночным «окнам», выносить особенно тяжёлые обработки в отдельные базы, продумывать механизм уведомлений о сбоях. В какой‑то момент вы придёте к мысли, что без нормального сервера 1С жить уже тяжело — и это абсолютно нормальный путь развития. Но пока база файловая, грамотная настройка регламентных заданий и фоновых обработчиков делает из простой «файлики на сетевой шаре» вполне работоспособную боевую систему. Вопрос только в том, насколько аккуратно вы всё это соберете.

Вот честно, без «наверное, всё ок», без веры в чудо и «никто не жаловался». Вы видели живые логи, проверяли результат, моделировали отказ? Или до сих пор надеетесь на одинокий файловый сеанс, который где‑то там крутится и никогда не падает?