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

← На главную

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

Анализ проблемы: почему регламентные задания «вылетают»?

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

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

Решение №1: Использование параметров командной строки (наиболее эффективный способ)

Начиная с версии платформы 8.3.11, разработчики 1С добавили мощный инструмент управления планировщиком через ключи запуска. Рассмотрим подробнее параметр AllowExecuteScheduledJobs. Этот ключ позволяет нам явно указать платформе, должен ли конкретный экземпляр программы исполнять регламентные задания.

Для решения задачи нам потребуется изменить ярлыки запуска 1С для разных групп пользователей:

Для обычных пользователей (которым запрещен доступ к ресурсам): Добавим в строку запуска параметр /AllowExecuteScheduledJobs -Off. Это гарантирует, что сеанс данного пользователя никогда не станет исполнителем фоновых задач.
Для выделенного сеанса (робота) или администратора: Добавим параметр /AllowExecuteScheduledJobs -Force. Этот ключ заставляет сеанс брать на себя выполнение заданий в приоритетном порядке.

Разберем пример настройки ярлыка. В поле «Объект» свойств ярлыка 1С это будет выглядеть следующим образом:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "C:\Bases\Management" /AllowExecuteScheduledJobs -Off

Таким образом, мы исключаем «Васю Пупкина» из процесса обмена данными, и платформа будет искать другого подходящего кандидата или ждать запуска «правильного» сеанса.

Решение №2: Публикация базы на веб-сервере (IIS или Apache)

Посмотрим на ситуацию с точки зрения архитектуры. Если мы опубликуем файловую базу на веб-сервере (например, Internet Information Services (IIS)), механизм выполнения заданий кардинально изменится. В этом случае за регламентные задания будет отвечать процесс веб-сервера (например, w3wp.exe).

Выясним преимущества этого метода:

Независимость от пользователей: Задания выполняются в контексте службы веб-сервера, а не в сеансах RDP-пользователей. Даже если в базе никого нет, задания могут продолжать выполняться.
Управление правами: Нам достаточно дать необходимые права доступа к папкам (например, к базе БУХ) только одной учетной записи, от имени которой запущен веб-сервер (обычно это системная учетная запись или специально созданный пользователь).
Стабильность: Исключается человеческий фактор — случайное закрытие программы пользователем не прервет важный процесс синхронизации.

При использовании этого метода пользователи подключаются через «Тонкий клиент» по протоколу HTTP/HTTPS, и их локальные права в операционной системе больше не влияют на работу фоновых процессов базы данных.

Решение №3: Создание выделенного сеанса «Робота»

Если переход на веб-сервер затруднен, разберем классический метод с выделенным техническим пользователем. Мы создаем в операционной системе и в самой 1С пользователя «Робот».

Проанализируем алгоритм настройки:

Настраиваем автоматический вход (autologon) в систему под техническим пользователем на сервере.
В автозагрузку этого пользователя добавляем запуск 1С с ключом /AllowExecuteScheduledJobs -Force.
Даем этому пользователю в ОС все необходимые права на папки БУХ и УПР.

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

Решение №4: Программный контроль через расширение или код конфигурации

Рассмотрим вариант, когда мы хотим управлять процессом на уровне встроенного языка 1С. Мы можем внедрить проверку непосредственно в код регламентного задания. Это позволит нам «пропускать» выполнение, если задание запустилось «не там».

Пример логики внутри процедуры регламентного задания:


Процедура ВыполнитьОбменДанными() Экспорт
    
    ТекущийПользовательСистемы = ИмяПользователя();
    
    // Список разрешенных пользователей для выполнения задания
    РазрешенныеПользователи = "Администратор, РоботОбмена, БухгалтерГлавный";
    
    Если Найти(РазрешенныеПользователи, ТекущийПользовательСистемы) = 0 Тогда
        // Если задание запустилось под обычным менеджером, просто выходим
        Возврат;
    КонецЕсли;
    
    // Основная логика обмена
    ПровестиСинхронизациюСБухгалтерией();
    
КонецПроцедуры

Такой подход не запрещает платформе «цеплять» задание к сеансу, но само задание мгновенно завершается без выполнения полезных действий, если условия не соблюдены. В следующем цикле (через интервал, указанный в расписании) платформа попытается запустить задание снова, возможно, уже в другом сеансе.