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

При активном развитии информационной системы часто возникает потребность одновременно выполнять множество сервисных задач: отправку SMS, получение почты, синхронизацию с сайтом, обмен данными с внешними сервисами и другими базами. Когда таких задач накапливается около десятка и запускаться они должны каждую минуту, разработчики создают регламентные и фоновые задания. Однако в файловом режиме базы данных разработчик сталкивается с неприятной проблемой: если одно из заданий выполняется долго (например, ожидает ответа от веб-сервиса), все остальные задания выстраиваются в очередь и простаивают.

Разберем детально, почему это происходит, и рассмотрим проверенные архитектурные способы реализации параллельной обработки задач.

Причины ограничений фоновых заданий в файловой базе

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

1. Эмуляция менеджера заданий: В файловом режиме платформа не имеет полноценного серверного кластера процессов. Фоновые задания эмулируются: они запускаются последовательно и помещаются в общую очередь. Пока один процесс не завершит транзакцию или процедуру, следующее задание ждет освобождения ресурсов.
2. Файловые и табличные блокировки: База данных хранится в едином файле 1Cv8.1CD. Любая операция записи в базу блокирует страницы данных файла. При одновременной попытке нескольких потоков выполнить запись возникают конфликты блокировок и тайм-ауты ожидания.
3. Риск повреждения базы данных: Высокая интенсивность одновременных попыток записи в один файл из разных сеансов способна привести к повреждению структуры таблиц 1Cv8.1CD.

Вариант 1. Переход на клиент-серверный режим

Самый надежный и штатный способ обеспечить истинную параллельность — использовать сервер 1С:Предприятие и реляционную СУБД (например, PostgreSQL или MS SQL Server). В клиент-серверном режиме менеджер кластера серверов 1С распределяет фоновые задания по рабочим процессам, позволяя запускать десятки потоков одновременно без блокировки очереди.

Если бюджет проекта ограничен и покупка полной серверной лицензии нецелесообразна, рассмотрим доступный вариант — официальную лицензию «1С:Сервер МИНИ на 5 подключений». В связке с бесплатной СУБД PostgreSQL это решение снимает системные ограничения файловой базы и обеспечивает параллельную работу фоновых заданий на уровне сервера приложений.

Вариант 2. Запуск отдельных сеансов через планировщик задач ОС

Если переход на клиент-серверный вариант невозможен, организуем параллельность на уровне операционной системы. Вместо запуска фоновых заданий платформы внутри одного сеанса настроим запуск независимых процессов 1С через системный планировщик задач (Планировщик Windows или Cron в Linux).

Посмотрим на пример командной строки для запуска независимого процесса 1С под конкретную регламентную обработку:

"C:\Program Files\1cv8\current\bin\1cv8c.exe" ENTERPRISE /F "C:\Bases\Trade" /N "Robot_SMS" /P "Pass123" /Execute "C:\Scripts\SendSMS.epf"

Каждое задание (отправка SMS, обмен, загрузка почты) оформляется в виде внешней обработки, которая автоматически завершает работу сеанса после выполнения через метод ЗавершитьРаботуСистемы(). Запуская такие задачи отдельными процессами по расписанию ОС, мы получаем независимое выполнение задач по времени.

Важно: При таком подходе операции записи в базу данных должны быть максимально короткими, чтобы минимизировать вероятность одновременной блокировки таблиц файловой базы.

Вариант 3. Вынос сервисных задач во внешние утилиты или OneScript

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

Разберем схему разделения обязанностей:

1. Внешний скрипт (написанный на OneScript, Python или PowerShell) выполняет тяжелую сетевую работу: опрашивает почтовый сервер, отправляет пачки SMS, взаимодействует с веб-сервисами.
2. После получения и подготовки данных скрипт подключается к файловой базе 1С через COM-соединение или HTTP-сервис и передает готовый результат за одну короткую операцию.

Посмотрим на пример скрипта OneScript, выполняющего подключение через COM-соединение:

// Создаем объект подключения к файловой базе
V8 = Новый COMОбъект("V83.COMConnector");
СтрокаПодключения = "File=""C:\Bases\Trade""; Usr=""Robot""; Pwd=""Pass123"";";

Попытка
    База = V8.Connect(СтрокаПодключения);
    // Вызываем экспортную функцию общего модуля для быстрой записи данных
    Результат = База.ИнтеграцияСервер.ЗаписатьВходящиеСообщения(ПакетДанных);
Исключение
    Сообщить("Ошибка подключения к 1С: " + ОписаниеОшибки());
КонецПопытки;

Вариант 4. Использование отдельной сервисной конфигурации 1С

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

Основная рабочая база не нагружается длительными сетевыми ожиданиями. Сервисная база обменивается с основной базой быстрыми порциями данных через HTTP-сервисы или COM-соединение, гарантируя, что зависание внешнего API не заблокирует фоновые процессы учета.

Контроль зависания процессов и асинхронные вызовы

При построении параллельной архитектуры важно предусмотреть защиту от блокировки потоков:

1. Сторожевой таймер (Watchdog): Если задачи запускаются отдельными процессами операционной системы, настроим скрипт мониторинга, принудительно завершающий зависшие процессы 1cv8c.exe или 1cv8.exe, если время их работы превышает допустимый порог (например, 3 минуты).
2. Асинхронные методы платформы: При обращении к сетевым ресурсам внутри конфигурации используем асинхронные методы и директивы (Асинх, Ждать), чтобы ожидание ответа от медленного внешнего сервера не замораживало клиентский поток.