При администрировании серверных баз 1С:Предприятие 8.3 администраторы и разработчики часто сталкиваются с ситуацией, когда в консоли кластера или в журнале регистрации отображаются фоновые задания, происхождение которых неочевидно. Особенно странно это выглядит, когда в настройках базы установлена галочка Блокировка регламентных заданий, а в колонках "Пользователь" и "Компьютер" для этих заданий стоят пустые значения. В этой статье мы подробно разберем, почему это происходит, как платформа 1С обрабатывает вызовы веб-сервисов и почему стандартные механизмы блокировки в данном случае не срабатывают. В рамках общего сопровождения систем задачи обслуживания можно делегировать программе для автоматического обновления и тестирования баз 1С по расписанию.
Для начала проанализируем фундаментальное различие в терминологии платформы 1С. Часто эти понятия путают, но с технической точки зрения это разные сущности:
ScheduledJobs) — это объекты метаданных, для которых задано расписание. Платформа сама инициирует их запуск в определенное время. Именно их запуск предотвращает флаг "Блокировка регламентных заданий" в консоли кластера.BackgroundJobs) — это процессы, выполняемые на сервере вне основного потока клиентского сеанса. Они могут быть порождены регламентными заданиями, но также могут запускаться программно через метод ФоновыеЗадания.Выполнить() или порождаться самой платформой для обслуживания системных нужд.Рассмотрим ситуацию: если флаг блокировки установлен, регламентное задание по расписанию не запустится. Однако, если в коде конфигурации или при внешнем обращении (например, через Web-сервис) происходит программный вызов функции, требующей фонового выполнения, платформа создаст фоновое задание в обход всяких блокировок расписания. Для комплексной проверки и анализа таких процессов можно использовать инструмент для аудита регламентных и фоновых заданий.
Проанализируем сценарий, описанный в теме: наличие веб-сервиса, который активно опрашивается из внешней базы в цикле. Когда внешняя система обращается к WSDL-описанию или вызывает метод веб-сервиса 1С, сервер приложений выполняет следующие действия:
Во-первых, платформа создает сеанс для обслуживания этого вызова. В зависимости от настроек публикации (файл .1cws), это может быть сеанс под конкретным пользователем или анонимный вход. Если используется анонимный доступ, поля "Пользователь" в консоли мониторинга могут оставаться пустыми.
Во-вторых, выполнение кода внутри веб-сервиса всегда происходит на стороне сервера. В современных версиях платформы (начиная с 8.3) многие серверные вызовы, инициированные внешними протоколами (HTTP, SOAP), регистрируются в системе именно как фоновые процессы. Это необходимо для изоляции выполнения и управления ресурсами сервера.
Выясним причину появления множества таких заданий. Если мы вызываем веб-сервис в цикле (нагрузочное тестирование), сервер создает очередь запросов. На каждый запрос выделяется поток. В консоли управления эти потоки отображаются как активные фоновые задания. При необходимости организовать регулярный цикл передачи данных по расписанию можно использовать автоматизацию обмена между базами 1С через веб-сервис или COM-соединение.
Разберем, как платформа 1С оптимизирует работу с внешними подключениями. Для веб-сервисов используется механизм пула соединений. Это означает, что после того, как ваш код отдал результат запроса и завершил выполнение метода веб-сервиса, сеанс не закрывается мгновенно.
Платформа удерживает соединение активным в течение некоторого времени (по умолчанию это может быть 20–30 секунд или до нескольких минут в зависимости от настроек vrs-расширений и веб-сервера IIS/Apache). Это делается для того, чтобы при следующем быстром вызове не тратить ресурсы на авторизацию и создание нового сеанса. В списке фоновых заданий эти "спящие" в пуле процессы могут отображаться как активные, но без признаков активности пользователя, что и вызывает недоумение у администратора.
Обратим внимание на версию платформы 8.3.9.1850. В старых релизах ветки 8.3 существовали особенности отображения сеансов веб-сервисов. Зачастую они не идентифицировались как полноценные клиентские сеансы (как, например, тонкий или толстый клиент), а попадали в категорию служебных фоновых заданий. Поскольку в веб-сервисе не передаются данные о компьютере клиента (в привычном для 1С понимании имени сетевого узла), поле "Компьютер" остается пустым.
Также стоит учитывать проверку лицензий. Каждый новый вызов, если он не попал в существующий пул, требует обращения к менеджеру лицензий. В высоконагруженных циклах этот процесс сам по себе может порождать кратковременные системные фоновые задания для проверки доступности программных ключей защиты.
Разберем по шагам, как проверить гипотезу о связи "странных" заданий с веб-сервисами:
Посмотрим на пример того, как технически может выглядеть регистрация вызова в журнале. Даже если пользователь не указан в консоли, в журнале регистрации в колонке "Приложение" будет значиться Web-сервис или WS-соединение. Это главный идентификатор того, что задание не является регламентным "призраком", а является следствием внешней активности.
Подводя итог, можно утверждать, что наблюдаемые "странные" фоновые задания — это сеансовые процессы обслуживания веб-сервисов. Их появление при включенной блокировке регламентных заданий абсолютно нормально, так как они:
HTTP/SOAP.Для оптимизации работы в таких случаях рекомендуем проанализировать код веб-сервиса на предмет длительных операций и убедиться, что внешняя система корректно завершает соединения, если это предусмотрено протоколом взаимодействия.