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

← На главную

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

Разберем, почему классические платформенные инструменты вызывают сложности в данном сценарии, выясним причины сбоев при длительных операциях и рассмотрим практические способы решения задачи.

Платформенные особенности монопольного режима и блокировки сеансов

Проанализируем базовое поведение платформы «1С:Предприятие» при попытке ограничить доступ к информационной базе:

Классический монопольный режим. Вызов метода УстановитьМонопольныйРежим(Истина) полностью блокирует не только подключение новых пользователей, но и запуск любых регламентных и фоновых заданий. Если процедура расчета себестоимости использует параллельные потоки для записи проводок по счетам учета, монопольный режим приведет к ошибке выполнения алгоритма.
Блокировка начала сеансов в кластере. Параметр «Блокировка начала сеансов включена» запрещает интерактивный вход пользователей, но позволяет работать сеансам, запустившимся с ключом разрешения /UC. При этом дочерние фоновые задания, порождаемые разрешенным сеансом, успешно стартуют (если в кластере не взведен флаг «Блокировка регламентных заданий включена»).

Однако на практике длительный сеанс администратора, запущенный с параметром /UC, может внезапно прерваться через несколько часов с ошибкой «Начало сеансов с базой запрещено». Выясним, почему это происходит.

Почему сеанс завершается во время длительного расчета

Рассмотрим скрытые факторы, приводящие к аварийному завершению сеанса при длительных операциях:

Разрыв сетевого соединения и сбой reconnect. При непрерывном выполнении серверного вызова на сетевом оборудовании (маршрутизаторах, VPN-шлюзах, межсетевых экранах) может сработать таймаут неактивности TCP-сессии. Клиентское приложение пытается восстановить потерянную связь с сервером 1С. В момент переподключения сервер может расценить запрос как попытку создания нового подключения без передачи кода разрешения и принудительно завершить сессию.
Перезапуск рабочего процесса сервера (rphost). Расчет себестоимости потребляет значительный объем оперативной памяти. Если в настройках кластера серверов 1С заданы ограничения («Допустимый объем памяти на один процесс» или «Интервал перезапуска рабочих процессов»), сервер штатно перезапускает перегруженный рабочий процесс. Клиентский контекст сбрасывается, а повторная авторизация блокируется кластером.
Таймауты спящих и пассивных сеансов. Если в свойствах кластера установлены значения для параметров «Время засыпания пассивных сеансов» и «Время завершения спящих сеансов», сеанс, длительное время ожидающий ответа от сервера без действий в интерфейсе, может быть признан неактивным и удален кластером.
Механизмы завершения в БСП. Если блокировка соединений включалась через стандартный интерфейс конфигурации (раздел администрирования), подсистема «Библиотека стандартных подсистем» активирует обработчик ожидания, который по истечении заданного интервала завершает работу клиентских сеансов.

Способ 1. Программное ограничение входа через проверку при запуске

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

Разберем по шагам логику реализации:

Создадим в конфигурации константу РСВ_МонопольныйРежим с типом данных Булево.
Перед запуском тяжелого расчета программно устанавливаем значение константы в Истина.
В модуле управляемого приложения в процедуре ПередНачаломРаботыСистемы размещаем проверку прав и состояния константы.

Посмотрим на пример кода в модуле приложения:


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

После завершения расчета (а также в блоке обработки исключений Попытка ... Исключение) обязательно возвращаем значение константы в Ложь.

Важные ограничения данного метода:

Не вытесняет уже работающих пользователей. Проверка срабатывает только в момент открытия программы. Если бухгалтер уже запустил сеанс до взведения константы, он продолжит ввод данных.
Не блокирует сторонние каналы интеграции. Процедура ПередНачаломРаботыСистемы не перехватывает сеансы внешних подключений (COM-соединения), а также запросы через Web- и HTTP-сервисы.
Риск зависания блокировки. При аварийном падении сервера или сбое СУБД сброс константы не выполнится, и база останется недоступной для пользователей до вмешательства администратора.

Способ 2. Установка даты запрета изменения данных

Проанализируем истинную причину конфликтов при расчете себестоимости. В большинстве случаев РСВ завершается ошибкой не из-за самого факта присутствия пользователей в базе, а из-за того, что параллельно проводятся документы задним числом в закрываемом учетном периоде.

Оптимальным решением является использование штатного механизма дат запрета:

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

Способ 3. Автономия выполнения расчета на сервере

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

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

Способ 4. Корректная настройка административной блокировки

Если для регламентных работ действительно требуется полная изоляция базы, настроим блокировку сеансов с соблюдением требований стабильности:

В консоли администрирования кластера серверов 1С откроем свойства информационной базы и установим флаг «Блокировка начала сеансов включена», задав надежный «Код разрешения» (например, SecretCode123).
Убедимся, что флаг «Блокировка регламентных заданий включена» снят, чтобы системные фоновые потоки могли стартовать.
Запускаем сеанс администратора непосредственно на сервере приложений 1С (например, через RDP-сессию администратора), указав ключ командной строки:
```
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /IBName "MyBase" /UC "SecretCode123"
```
Локальный запуск полностью исключает влияние сетевых разрывов оборудования на клиентскую сессию.
В свойствах кластера проверяем параметры перезапуска рабочих процессов, чтобы лимиты по оперативной памяти не привели к принудительному завершению rphost во время пиковых нагрузок РСВ.