При работе с веб-клиентом 1С:Предприятия многие пользователи сталкиваются с проблемой неконтролируемого накопления активных сеансов. Даже если пользователь закрыл вкладку или свернул браузер, сеанс на сервере 1С продолжает оставаться активным, потребляя клиентскую лицензию. Это происходит из-за механизма "keep-alive" запросов, которые веб-клиент периодически отправляет на сервер. Стандартные настройки платформы по засыпанию и закрытию неактивных сеансов в таких случаях оказываются неэффективными. В результате, несмотря на малое количество реально работающих пользователей, система может быстро исчерпать доступные лицензии, что приводит к невозможности подключения новых пользователей и необходимости приобретения дополнительных лицензий.
Давайте разберем эту проблему подробнее и рассмотрим различные подходы к ее решению.
Прежде чем перейти к методам решения, нам необходимо глубоко понять, почему веб-клиент 1С ведет себя таким образом, и почему стандартные механизмы управления сеансами не работают.
Механизм "keep-alive": Веб-приложения, включая веб-клиент 1С, используют периодические запросы, известные как "keep-alive" или "heartbeat", для поддержания активного HTTP-соединения с сервером. Эти запросы предотвращают автоматическое закрытие соединения по таймауту на уровне веб-сервера (например, IIS, Apache) или прокси-серверов. Для 1С веб-клиент отправляет такие запросы примерно раз в минуту или раз в 10 минут (в зависимости от версии платформы и конкретной реализации), даже если пользователь не выполняет никаких действий. Сервер воспринимает эти запросы как "активность", что сбрасывает внутренний таймер неактивности сеанса.
Неэффективность стандартных настроек таймаутов 1С: В настройках информационной базы на кластере серверов 1С существуют параметры "Засыпать через" и "Закрывать через". Эти параметры предназначены для перевода сеансов в спящий режим и их последующего закрытия при отсутствии активности. Однако, поскольку "keep-alive" запросы веб-клиента постоянно имитируют активность, таймеры неактивности никогда не достигают заданных значений. Таким образом, сеанс веб-клиента не переходит в состояние сна и не закрывается автоматически, оставаясь "активным" с точки зрения кластера.
Идентификация сеансов в консоли сервера: В консоли администрирования сервера 1С:Предприятия мы можем увидеть список всех активных сеансов. Для сеансов веб-клиента, даже при свернутой вкладке браузера или бездействии пользователя, колонка "Последняя активность" будет регулярно обновляться, а статус "Спящий" будет отображаться как "Нет". Это подтверждает, что с точки зрения сервера 1С, такой сеанс считается полностью активным и, следовательно, потребляет лицензию.
Другие причины зависания сеансов: Помимо "keep-alive" запросов, сеансы могут "зависать" по другим причинам. Например, при нештатном завершении работы клиентского приложения (вкладка браузера была закрыта без корректного выхода из системы), обрыве сетевого соединения, длительном выполнении тяжелых операций или ошибках в коде. В таких случаях сеанс также может оставаться активным на сервере, но уже без реальной связи с клиентом.
Для эффективного управления сеансами веб-клиента и предотвращения исчерпания лицензий нам потребуются более активные и целенаправленные методы, выходящие за рамки стандартных настроек. Рассмотрим подробнее доступные подходы.
Наиболее простой и очевидный, хотя и ручной, способ управления сеансами — это использование встроенной Консоли администрирования сервера 1С:Предприятия. Это основной инструмент для системных администраторов, позволяющий отслеживать и управлять рабочими процессами кластера, информационными базами и, конечно же, активными сеансами.
Как использовать:
Ограничения: Этот метод подходит для нечастых инцидентов или небольшого числа сеансов. При большом количестве пользователей и частых зависаниях ручное завершение становится трудоемким и неэффективным.
Для автоматизации процесса завершения неактивных сеансов мы можем использовать утилиты администрирования сервера 1С:Предприятия — RAS (Remote Administration Server) или RAC (Remote Administration Console). Эти инструменты предоставляют программный интерфейс для взаимодействия с кластером серверов 1С и управления им.
Принцип работы:
Мы создаем внешнюю обработку или регламентное задание в одной из баз 1С (или даже отдельное приложение на любом языке программирования, способное взаимодействовать с RAS/RAC), которая будет периодически:
ЗавершитьРаботуПользователей() или аналогичные функции, доступные через RAS/RAC.Пример логики программного завершения (псевдокод на встроенном языке 1С):
// Предполагаем, что у нас есть подключение к кластеру и инфобазе
// и административные права.
// Этот код демонстрирует логику и может требовать адаптации
// для реального использования с RAS/RAC.
Функция ПолучитьАктивныеСеансы()
// ... Код для получения списка сеансов через RAS/RAC ...
// Результат: ТаблицаЗначений с колонками (Идентификатор, Пользователь,
// ВидКлиента, ВремяСоединения, ПоследняяАктивность, Занят)
Возврат СписокСеансов;
КонецФункции
Процедура ЗавершитьНеактивныеСеансы()
МаксимальноеВремяБездействия = 3600; // 1 час в секундах
СписокСеансов = ПолучитьАктивныеСеансы();
Если СписокСеансов.Количество() = 0 Тогда
Возврат;
КонецЕсли;
СписокСеансовДляЗавершения = Новый СписокЗначений;
Для Каждого Сеанс Из СписокСеансов Цикл
// Фильтруем по веб-клиенту и проверяем,
// что сеанс не занят выполнением операции.
// Основная сложность: "ПоследняяАктивность" постоянно обновляется.
// Поэтому придется использовать "ВремяСоединения"
// или дополнительную логику для отслеживания реальной активности.
// Предположим, что мы умеем определять "реальное" время
// отсутствия пользовательских действий.
// Например, через анализ журнала регистрации или специальный механизм.
// В данном примере будем ориентироваться на "ВремяСоединения"
// и флаг "Занят", предполагая, что долгие сеансы,
// не занятые операцией, могут быть неактивными.
Если Сеанс.ВидКлиента = "WebClient"
И НЕ Сеанс.Занят
И Сеанс.ВремяСоединения > МаксимальноеВремяБездействия Тогда
// Дополнительная проверка:
// Можно запросить журнал регистрации за последние X минут
// для данного сеанса на предмет интерактивных действий пользователя.
// Если таких действий нет, то добавляем сеанс к завершению.
// (Эта логика очень сложна для реализации без внешних инструментов
// или значительной доработки конфигурации)
// Для простоты примера, если сеанс веб-клиента долго висит
// и не занят, мы его завершаем.
СписокСеансовДляЗавершения.Добавить(Сеанс.Идентификатор);
КонецЕсли;
КонецЦикла;
Если СписокСеансовДляЗавершения.Количество() > 0 Тогда
// Вызываем метод для завершения работы пользователей
// Это может быть ЗавершитьРаботуПользователей()
// или методы RAS/RAC
// (Конкретная реализация зависит от способа взаимодействия с RAS/RAC)
// Пример: Кластер.ИнформационнаяБаза.ЗавершитьРаботуПользователей(СписокСеансовДляЗавершения, ТекстСообщения);
Сообщить("Завершено " + СписокСеансовДляЗавершения.Количество()
+ " неактивных сеансов веб-клиента.");
Иначе
Сообщить("Неактивных сеансов веб-клиента для завершения не найдено.");
КонецЕсли;
КонецПроцедуры
Важный аспект: Самая большая сложность здесь — это надежно определить реальную неактивность пользователя. Поскольку "Последняя активность" постоянно обновляется "keep-alive" запросами, нам придется либо использовать "Время соединения" как грубый индикатор, либо внедрять более сложную логику, например, анализируя журнал регистрации на предмет реальных интерактивных действий пользователя или реализуя собственный механизм отслеживания активности на стороне клиента.
Для высоконагруженных систем или систем с особыми требованиями к контролю сеансов, мы можем разработать полностью внешнее решение, используя Service API. Этот подход предполагает создание собственного сервиса, который будет взаимодействовать с кластером 1С и предоставлять более гибкие возможности для учета и контроля сеансов.
Возможности внешнего сервиса:
IBSession. При создании нового сеанса клиент может отправлять заголовок IBSession: start, а при завершении работы — IBSession: finish. Внешний сервис может перехватывать эти запросы и управлять жизненным циклом сеанса, позволяя, например, явно завершать сеанс на сервере 1С при получении finish, даже если клиент не произвел штатный выход.Этот подход требует значительных ресурсов на разработку и поддержку, но предоставляет максимальный контроль.
Поскольку типовые механизмы 1С плохо определяют реальную активность пользователя в браузере, мы можем перенести часть логики на клиентскую сторону. Этот метод позволяет нам отслеживать фактические действия пользователя (движения мыши, нажатия клавиш) и использовать эту информацию для управления сеансом.
Принцип реализации:
window.onmousemove, window.onkeydown, window.onclick и т.д.).RAS/RAC), либо отправляем команду клиенту на принудительное завершение работы.Это достаточно сложный в реализации подход, но он позволяет наиболее точно определить, действительно ли пользователь работает с приложением.
В некоторых случаях, когда веб-клиент 1С используется как "личный кабинет" для множества пользователей, которые лишь изредка обращаются к системе и часто забывают закрыть вкладки, стоит пересмотреть архитектуру решения.
Идея: Перенести функционал "личного кабинета", требующий минимального взаимодействия с основной системой 1С и не требующий постоянной лицензии, на отдельный веб-сервер или использовать сторонние веб-технологии.
Примеры:
HTTP-сервисы, Web-сервисы или напрямую с базой данных (в случае клиент-серверной архитектуры).Этот подход требует значительных инвестиций в разработку, но может быть оправдан при большом количестве "потенциально неактивных" пользователей и высоких требованиях к экономии лицензий.
Если ваша база 1С работает в файловом режиме и опубликована на веб-сервере IIS, управление зависшими сеансами может быть еще более проблематичным. В клиент-серверном варианте 1С кластер серверов имеет более развитые механизмы управления. Для файловых баз часто единственной рекомендацией для завершения зависших сеансов является перезапуск веб-сервера.
Улучшение для файловых баз на IIS:
Чтобы избежать перезапуска всего веб-сервера при необходимости завершения сеансов одной базы, мы можем настроить IIS таким образом, чтобы каждая опубликованная база 1С выполнялась в отдельном пуле приложений. Это позволяет нам:
Такая настройка не решит проблему "keep-alive" сеансов напрямую, но упростит административное управление в случае их зависания.
Разработчики 1С осознают проблему управления сеансами. В новых версиях платформы (начиная с 8.3.14) были внесены некоторые улучшения и новые методы для более тонкой настройки и управления параметрами информационной базы.
Новые возможности:
Мы должны следить за обновлениями платформы и использовать новые возможности, которые могут упростить управление сеансами.
Таким образом, проблема неактивных сеансов веб-клиента 1С, вызванная "keep-alive" запросами, требует активного вмешательства. Стандартные настройки неэффективны, и нам необходимо применять административные, программные или даже архитектурные решения. Выбор конкретного метода или комбинации методов будет зависеть от специфики вашей системы, количества пользователей, требований к доступности и ресурсов на разработку. Главное — активно управлять жизненным циклом сеансов, чтобы обеспечить оптимальное использование лицензий и стабильную работу системы.