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

← На главную

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

Почему в файловой базе нельзя просто «узнать» точное время

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

Метод 1: Использование «Мьютексов» для защиты операций

Вместо того чтобы пытаться угадать время запуска регламентного задания, мы можем управлять самим процессом доступа к данным. Для этого идеально подходит механизм объектных блокировок Заблокировать(), который работает как программный «мьютекс» (сигнализатор занятости). Это решение не зависит от блокировок СУБД и надежно работает в файловой базе.

Реализация:

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

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

Метод 2: Создание управляющего регистра сведений

Если нам нужно более тонкое управление, мы можем вынести логику контроля в отдельный регистр сведений ТормозаДляФоновых. Этот метод позволяет принудительно приостанавливать выполнение заданий, если кассир начал пробивать чек.

Разберем по шагам:

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

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


// Пример логики проверки возможности запуска
Если Не МенеджерРегистров.ПроверитьВозможностьЗапуска(ИмяЗадания) Тогда
    Возврат; // Завершаем выполнение, если сейчас «часы пик» для кассира
КонецЕсли;

// Продолжаем выполнение обмена
ВыполнитьОбменЕГАИС();

Метод 3: Оптимизация транзакций при работе с ЕГАИС

Часто конфликты возникают из-за того, что запись присоединенного файла ЕГАИС происходит внутри той же транзакции, в которой создается документ. Чтобы этого избежать, рассмотрим следующие рекомендации:

Разделение транзакций: Старайтесь выносить запись XML-файлов и регистрацию сообщений в отдельные транзакции или фоновые процессы, которые запускаются после фиксации основного документа.
Отложенная запись: Используйте временные хранилища (ПоместитьВоВременноеХранилище) для подготовки данных, чтобы сократить время удержания блокировок на регистрах накопления и справочниках присоединенных файлов.

Итоговые рекомендации

Вместо попыток предсказать расписание, мы рекомендуем сфокусироваться на управлении доступом через «мьютексы». Если проблема с ЕГАИС критична, перенос обменов в отдельный сеанс или выделение их в независимую очередь (регистр «ОчередьОбменов») — это лучший архитектурный выбор для файловой базы. Это позволит кассирам работать бесперебойно, а обменам — выполняться в фоновом режиме, когда база не занята активным пробитием чеков.