Администрирование корпоративной информационной системы часто требует вмешательства в работу активных подключений. Ситуации, когда необходимо принудительно разорвать соединение с конкретным сотрудником или группой лиц, возникают регулярно: от проведения регламентных работ и обновления конфигурации до блокировки доступа уволенным сотрудникам или при обнаружении подозрительной активности.
Ручное управление через консоль администрирования серверов 1С:Предприятие удобно для разовых операций, но не подходит для автоматизации процессов. В таких случаях на помощь приходит программный интерфейс. Платформа предоставляет мощные инструменты для управления сеансами, позволяя внешним скриптам или внутренним обработкам взаимодействовать с кластером серверов.
В данной статье мы подробно разберем механизмы программного завершения сеансов, рассмотрим особенности работы с объектом COMСоединение и альтернативные методы через HTTP-сервисы. Вы узнаете, как корректно идентифицировать сессию, избежать ошибок блокировки и обеспечить стабильность работы системы в процессе администрирования.
Архитектура управления сеансами в кластере 1С
Прежде чем приступать к написанию кода, важно понимать, как устроена система управления сессиями внутри кластера. Сеанс — это активное соединение пользователя с информационной базой, которое регистрируется в диспетчере кластера. Каждый сеанс имеет уникальный идентификатор (GUID), набор параметров безопасности и привязку к рабочему процессу (рпхост).
Для программного доступа к этим данным используется объект АдминистрированиеКластера. Он выступает в роли посредника между вашим кодом и службами кластера. Получение экземпляра этого объекта требует наличия прав администратора кластера и корректно настроенной сетевой доступности портов менеджера кластера.
Важно отметить, что завершение сеанса — это деструктивная операция. Она приводит к откату незавершенных транзакций на стороне базы данных и принудительному закрытию окна клиента. Пользователь получает сообщение о разрыве соединения, а все несохраненные данные в его буфере могут быть утеряны.
⚠️ Внимание: Перед массовым завершением сеансов убедитесь, что в системе не выполняется критически важный регламентный обмен или загрузка данных, так как прерывание этих процессов может привести к рассинхронизации данных между узлами.
Взаимодействие происходит либо через COM-интерфейс (традиционный метод для толстого клиента и внешних скриптов), либо через REST-подобные интерфейсы в новых версиях платформы. Выбор метода зависит от архитектуры вашей системы и требований к безопасности.
Подготовка COM-соединения для администрирования
Самый распространенный способ программного управления — использование технологии COM. Этот метод позволяет подключиться к кластеру серверов из любой среды, поддерживающей COM-автоматизацию, включая сами обработки 1С, написанные на встроенном языке.
Первым шагом является создание объекта соединения. Для этого используется конструктор Новый COMСоединение. В качестве ProgID необходимо указать V83.COMConnector или V82.COMConnector в зависимости от версии платформы, хотя в современных релизах обычно используется универсальный идентификатор.
Критически важным параметром является строка подключения. Она должна содержать имя сервера, порт менеджера кластера (по умолчанию 1541), имя пользователя и пароль администратора кластера. Ошибка в любом из этих параметров приведет к исключению "Неверный пароль" или "Сервер не найден".
Попытка
АдресСервера = "srv-1c-cluster";
ПортКластера = 1541;
Пользователь = "Admin";
Пароль = "StrongPassword123";
СтрокаПодключения = АдресСервера + ":" + ПортКластера;
КомКоннектор = Новый COMСоединение("V83.COMConnector", СтрокаПодключения, Пользователь, Пароль);
Администратор = КомКоннектор.GetClusterAgent();
Исключение
Сообщить("Ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;
Обратите внимание, что объект COMСоединение создает тяжелую сущность в памяти. После завершения работы с кластером настоятельно рекомендуется очищать ссылки на объекты, чтобы освободить ресурсы и избежать утечек памяти в процессе работы агента сервера.
Идентификация и фильтрация активных сеансов
После успешного подключения к агенту кластера необходимо получить список активных сеансов. Метод Sessions возвращает коллекцию объектов, каждый из которых описывает текущее подключение пользователя. Простой перебор коллекции без фильтрации может привести к завершению служебных сеансов или сеанса самого администратора.
Для точечного воздействия необходимо использовать фильтры. Чаще всего отбор производится по имени пользователя, имени информационной базы или компьютеру, с которого установлено соединение. Свойство Host объекта сеанса содержит имя клиентской машины, что удобно для блокировки доступа с конкретных рабочих мест.
Ниже приведен пример алгоритма сбора идентификаторов сеансов, подлежащих завершению. Мы используем безопасный подход, исключая текущий сеанс администратора из списка на удаление.
- 🔍 Получаем коллекцию всех сеансов через метод
Sessionsагента кластера. - 🛡️ Фильтруем список, исключая сеансы с ролью "Администратор кластера" или системные процессы.
- 🎯 Сравниваем свойство
UserиAppIDдля поиска целевой конфигурации. - 📝 Сохраняем уникальные идентификаторы (GUID) в массив для последующей обработки.
Особое внимание стоит уделить свойству Blocked. Если сеанс уже находится в состоянии блокировки (например, из-за превышения лимита времени бездействия), попытка его завершения может быть избыточной, но обычно проходит без ошибок. Однако, если ваша цель — разблокировать пользователя, метод завершения сеанса является единственным надежным способом сбросить его состояние.
При фильтрации сеансов всегда проверяйте свойство "BeginTime". Завершение сеансов, которые длятся менее 1-2 минут, может быть признаком нестабильности сети или ошибок в коде клиента, а не целевым действием пользователя.
Алгоритм принудительного разрыва соединения
Непосредственное завершение сеанса выполняется методом Kill или Terminate (в зависимости от версии интерфейса) объекта сеанса. В классической модели COM это метод Kill, принимающий идентификатор сеанса или вызываемый непосредственно у объекта сессии.
Процесс разрыва не всегда происходит мгновенно. Сервер 1С отправляет сигнал клиенту, ожидая подтверждения закрытия соединений с базой данных. Если клиент завис или сеть недоступна, сервер может принудительно убить процесс через определенный таймаут. Это важно учитывать при написании циклов обработки большого количества пользователей.
Рекомендуется реализовывать механизм повторных попыток. В высоконагруженных системах первая попытка завершения может не пройти из-за блокировок на уровне СУБД или занятости рабочего процесса. Пауза в 1-2 секунды перед повторным вызовом часто решает проблему.
| Параметр | Тип данных | Описание | Обязательность |
|---|---|---|---|
| SessionID | Строка (GUID) | Уникальный идентификатор сессии | Да |
| Reason | Строка | Причина завершения (для логов) | Нет |
| WaitTimeout | Число | Время ожидания подтверждения (мс) | Нет |
| Force | Булево | Флаг принудительного завершения | Нет |
При использовании метода Kill важно обработать исключения. Если сеанс уже был завершен другим администратором или пользователем, вызов метода выбросит ошибку. Обработка этих ошибок позволит скрипту продолжить работу и завершить остальные сеансы из списка.
⚠️ Внимание: Никогда не запускайте цикл завершения сеансов в бесконечном цикле без задержек. Агрессивный опрос и завершение могут привести к отказу в обслуживании (DoS) для легитимных пользователей, пытающихся подключиться в этот момент.
☑️ Чек-лист перед завершением сеансов
Альтернативные методы: HTTP-сервисы и встроенные средства
В современных версиях платформы 1С:Предприятие 8.3 и выше рекомендуется использовать HTTP-сервисы для администрирования. Этот подход более безопасен, так как не требует открытия портов COM-соединения во внешнюю сеть и позволяет использовать стандартные протоколы авторизации.
Для реализации необходимо создать обработку, опубликованную как HTTP-сервис, которая будет иметь права на выполнение административных функций. Внутри такой обработки используется тот же объект АдминистрированиеКластера, но вызов происходит в контексте веб-запроса.
Преимуществом метода является возможность интеграции с внешними системами мониторинга (Zabbix, Prometheus) и порталами самообслуживания. Пользователь может сам нажать кнопку "Завершить мои сеансы" в личном кабинете, если забыл выйти с чужого компьютера.
Особенности работы через тонкий клиент
При вызове методов администрирования из тонкого клиента в файловом варианте базы данных объекты кластера могут быть недоступны. В этом случае необходимо использовать прямое обращение к файлам блокировок или переходить в режим предприятия с правами администратора ОС.
Также существует возможность использования командной строки утилиты rmngr или rac (Remote Administration Console). Это отличный вариант для скриптов на PowerShell или Bash, которые запускаются по расписанию на сервере. Синтаксис команды выглядит лаконично и не требует написания кода на встроенном языке.
rac session kill --cluster=uuid_cluster --session=uuid_session
Использование утилит rac предпочтительно для сценариев DevOps, где требуется быстрое развертывание и очистка окружения без запуска тяжелой графической оболочки 1С.
Обработка ошибок и логирование результатов
Надежная система администрирования невозможна без качественного логирования. Каждое действие по завершению сеанса должно записываться в журнал регистрации с указанием времени, имени администратора, идентификатора жертвы и результата операции.
Типичные ошибки, с которыми вы столкнетесь: "Сеанс не найден" (кто-то опередил вас), "Отказано в доступе" (недостаточно прав), "Сетевая ошибка" (проблемы с connectivity). Для каждой из них должна быть предусмотрена своя ветка обработки.
Хорошим тоном считается отправка уведомления пользователю перед разрывом, если это технически возможно. Например, через механизм сообщений системы или push-уведомление в мобильном приложении. Это снижает уровень стресса и количество звонков в службу поддержки.
- 📝 Записывайте событие в журнал регистрации с уровнем важности "Предупреждение" или "Ошибка".
- 🔔 Отправляйте email-уведомление руководителю отдела при массовом завершении сеансов.
- 📊 Обновляйте дашборд мониторинга, фиксируя количество активных сессий до и после.
Анализ логов помогает выявить паттерны: если определенного пользователя приходится "убивать" каждый день в одно и то же время, возможно, у него есть проблема с оборудованием или он забывает закрывать программу, уходя домой.
⚠️ Внимание: Интерфейсы администрирования и команды утилит могут изменяться в новых релизах платформы 1С. Всегда сверяйте синтаксис методов в официальной документации к той версии, которая установлена на вашем сервере.
Автоматизация завершения сеансов через HTTP-сервисы является наиболее современным и безопасным подходом, позволяющим легко интегрировать управление доступом в корпоративные порталы.
Часто задаваемые вопросы (FAQ)
Можно ли завершить сеанс пользователя, который находится в режиме 1С в толстом клиенте?
Да, метод программного завершения сеанса работает независимо от типа клиента (тонкий, толстый, веб). Сервер принудительно разрывает TCP-соединение, и клиентское приложение получает сигнал об ошибке сети, после чего закрывается или выдает сообщение о разрыве.
Что произойдет с данными, если завершить сеанс во время проведения документа?
Транзакция, в которой находился пользователь, будет откатана сервером базы данных (SQL Server, PostgreSQL и др.). Документ не проведется, движения не сформируются. Данные вернутся в состояние до начала транзакции, что гарантирует целостность базы, но работа пользователя будет потеряна.
Требуется ли перезапуск службы 1С:Предприятие после завершения сеансов?
Нет, перезапуск службы не требуется. Механизм завершения сеансов штатно освобождает ресурсы рабочего процесса (рпхост). Перезапуск может понадобиться только в случае, если процесс рпхост "завис" и не освобождает память даже после разрыва соединения.
Как завершить все сеансы конкретной информационной базы?
Необходимо получить список всех сеансов, отфильтровать их по свойству Infobase (имя или UUID базы) и в цикле вызвать метод завершения для каждого найденного идентификатора. Будьте осторожны, чтобы не завершить сеанс администратора, если он работает в этой же базе.
Безопасно ли использовать COM-соединение через интернет?
Категорически не рекомендуется открывать порты COM (обычно диапазон 4000-4010 и порт менеджера кластера) напрямую в интернет без VPN или туннелирования. Протокол COM не шифрует трафик по умолчанию. Используйте SSH-туннели или выделенные каналы связи для удаленного администрирования.