При разработке и сопровождении конфигураций на платформе 1С:Предприятие 8.3 разработчики часто сталкиваются с ситуацией, когда регламентные задания в файловом режиме информационной базы не запускаются параллельно. Если одно из заданий уже выполняется или разработчик запускает длительный процесс (например, непрерывный опрос подключенного оборудования), все остальные регламентные операции встают в очередь и ожидают его завершения. Разберем архитектурные особенности файлового режима и выясним, как правильно решить эту задачу.
Проанализируем, как устроен механизм выполнения фоновых и регламентных заданий в платформе 1С:Предприятие. В клиент-серверном варианте кластер серверов 1С автоматически распределяет задачи по рабочим процессам, запуская фоновые потоки параллельно в соответствии с доступными ресурсами.
В файловой же информационной базе механизм работает совершенно иначе:
Пока Истина Цикл для непрерывного опроса сканера, весов или внешнего сервиса, единственный фоновый поток оказывается занят навсегда. Планировщик никогда не перейдет к выполнению других регламентных процедур (загрузка курсов валют, обмен данными, закрытие счетов и т.д.).Рассмотрим подробнее способы обхода этого ограничения и правильные варианты архитектуры.
Частая ошибка разработчика — реализация ожидания внутри самого кода задания с помощью циклов или пауз. Регламентное задание не должно постоянно висеть в оперативной памяти. Пересмотрим подход к расписанию:
В таком случае регламентное задание выполняется за долю секунды, освобождает рабочий поток сеанса и дает возможность платформе 1С выполнить другие регламентные задачи из очереди.
Если задача заключается в опросе оборудования, подключенного непосредственно к локальному рабочему месту, использовать регламентные задания на сервере не рекомендуется. Оборудование доступно в контексте клиентского приложения, поэтому логичнее использовать метод платформы ПодключитьОбработчикОжидания().
Посмотрим на пример организации периодического опроса в модуле управляемого приложения или в открытой форме рабочего места:
&НаКлиенте
Процедура ПриНачалеРаботыСистемы()
// Подключаем опрос оборудования каждые 5 секунд
ПодключитьОбработчикОжидания("ОпроситьЛокальноеОборудование", 5, Ложь);
КонецПроцедуры
&НаКлиенте
Процедура ОпроситьЛокальноеОборудование() Экспорт
// Читаем данные с устройства и передаем на сервер для записи
ДанныеОпроса = ПолучитьСостояниеУстройства();
Если ДанныеОпроса <> Неопределено Тогда
ЗаписатьДанныеОборудованияНаСервере(ДанныеОпроса);
КонецЕсли;
КонецПроцедуры
При таком подходе опрос происходит в основном интерфейсном потоке конкретного пользователя по таймеру, совершенно не затрагивая механизм фоновых заданий и не блокируя общесистемные регламентные операции.
Если специфика бизнес-процесса все же требует работы отдельного длительного скрипта или выделенной обработки, необходимо гарантировать, что данный сеанс не перехватит на себя исполнение системных регламентных заданий. Для этого используем штатный ключ командной строки платформы 1С /AllowExecuteScheduledJobs.
Разберем по шагам распределение ролей между сеансами:
/AllowExecuteScheduledJobs -Off. Этот ключ жестко запрещает данному сеансу выступать в роли планировщика регламентных задач. Даже если внутри него выполняется длительный процесс или фоновое задание, общая очередь базы не пострадает./AllowExecuteScheduledJobs -Force. Этот параметр принудительно назначает сеанс ответственным за запуск и исполнение всех стандартных регламентных заданий.Пример строки запуска для выделенного обработчика с отключенными регламентными заданиями:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F "C:\Bases\Trade" /N "РоботОборудования" /P "Пароль" /AllowExecuteScheduledJobs -Off
Посмотрим на задачу шире: постоянный опрос физических портов компьютера (COM-порты, USB, драйверы весов и сканеров) силами файловой 1С создает избыточную нагрузку на файл базы данных 1Cv8.1CD из-за регулярных блокировок таблиц при записи. В архитектурном плане оптимальным решением является написание легковесной внешней службы или утилиты (на C#, Go, Python), которая взаимодействует с оборудованием и передает уже готовые агрегированные данные в 1С через HTTP-сервис базы либо сохраняет их в промежуточный файл обмена.
Если параллельное исполнение нескольких фоновых потоков критично для бизнес-логики компании, но бюджет ограничен, полноценный переход на тяжелый сервер предприятия не обязателен. Решением может стать лицензия «1С:Сервер МИНИ» (поддерживает до 5 пользовательских сеансов) в связке с бесплатной СУБД PostgreSQL. Это полностью устраняет проблему однопоточности файловой базы и переводит регламентные задания в полноценный многопоточный серверный режим.