Мониторинг неактивности: универсальная подсистема автозавершения неактивных сеансов 1С

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

     Всё началось с моего очередного утра: 10:00, кофе ещё горячий, а в трубке уже звучит знакомое: «1С не работает! Не хватает лицензий, мы не можем зайти!»

     Чтобы вы понимали масштаб проблемы, опишу контекст. Я работаю в медицинской клинике полного цикла: регистратура, колл-центр, кабинеты консультаций, диагностическое оборудование, заборные пункты анализов, собственные стационары. В пиковые часы у нас около 200 пользователей, и к 10 утра свободных лицензий, как правило, уже не остаётся.

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

     Размышляя об этом в моменты ручного поиска того, кого бы «выбить» из 1С, я осознал, что корень зла кроется в двух вещах 😈.

          1. Первый корень — это наша внутренняя «пищевая цепочка» захвата лицензий:

• Раннее утро: первыми просыпаются регистратура, кассы и посты медсестёр. На некоторых постах 1С работает круглосуточно, и компьютер там уже давно считается частью мебели.
• Середина утра: подключается младший медицинский персонал, администрация и бухгалтерия. Классический сценарий: сотрудник формирует утренний отчёт в 8:30, уходит пить чай (или домой), а его сеанс в 1С продолжает героически ждать его возвращения, занимая лицензию.
• В 10:00 часов утра: к работе приступают врачи, и к этому времени у нас зачастую уже имеется проблема с лицензиями.

          2. Второй корень  — специфика работы медицинской клиники.

     Многие врачи (например, хирурги или врачи УЗИ) могут начать заполнять документ приёма пациента, а затем уйти к оборудованию, оставив документ открытым. Для таких ситуаций в нашей организации я заранее настроил функционал автологирования несохранённых данных с возможностью их последующего восстановления. Это спасает, если произошёл разрыв сети, отключилось питание или кто-то (например, я) случайно завершил сеанс в попытке освободить лицензию. Именно из-за этой особенности использование штатного функционала 1С по выбиванию пользоваталей необходимо было настраивать очень аккуратно.

     Ввиду всех этих особенностей я понимал, что мне необходимо написать свой функционал, контролирующий эти процессы. Совершенно случайно я наткнулся на публикацию от Алексея (ссылка: //infostart.ru/1c/tools/931108/), и после его прочтения сразу понял: это именно то, что я искал. Алексею — большое спасибо за идею и отличную базу для старта!

     Писать подсистему с нуля, будучи, по сути, единственным разработчиком с плотным потоком текущих задач, не особо вдохновляло. Поэтому для разработки был использован Cursor: с его помощью функционал и был написан, хотя я тоже активно участвовал в процессе, занимаясь построением архитектуры и рефакторингом. Просьба не кидаться помидорами — моя рука там тоже во многом приложена, в том числе и к написанию этой статьи (написал её полностью сам, хотя, стоит признаться, последнюю редактуру доверил уже другому ИИ — назовём это гибким разделением труда или продуктивным таймменеджментом).

     На создание этого решения ушло 3–4 дня параллельной работы между основными задачами. Пока я занимался делами, Grok генерировал основную логику, а Claude Opus приводил её в божеский вид. Если посчитать стоимость этого удовольствия, мой личный кошелек похудел на 30 долларов, а нейросети сожгли 160 миллионов токенов.

     Буду откровенен: код, конечно, не идеален (он получился слишком раздутым). Но главное — оно работает. Работает быстро, без ошибок и реально закрывает бизнес-задачу.

Структура метаданных

      Структура метаданных расширения представлена на скриншоте ниже.

Обработчики ожидания

      Вся работа решения держится на двух клиентских обработчиках ожидания:

• Первый обработчик считывает настройки и на их основе проверяет активность пользователя. При этой проверке серверные вызовы отсутствуют — скорость работы очень быстрая и вообще незаметна для пользователя. Для тестирования есть отдельная вкладка «Тестирование производительности». По результатам тестов скорость одиночного обхода составляет около 1 мс (30 открытых форм).

• Второй обработчик делает серверный вызов для чтения и обновления настроек, которые затем помещаются в глобальную переменную.

Механизм завершения сеанса

      Когда время неактивности истекает, пользователя не выбивает сразу. Вместо этого открывается форма-предупреждение с обратным отсчётом перед закрытием клиента. У меня сейчас значение счётчика этого таймера установлено на 10 минут. Если пользователь не реагирует на предупреждение и таймер доходит до нуля, только тогда сеанс завершается автоматически. Если пользователь закрывает предупреждение, таймер начинает отсчёт заново.

Глобальные переменные

      В глобальном контексте созданы две переменные, через которые обработчики ведут свою работу:

• МН_НастройкиМониторингаСеанса — хранит текущие настройки мониторинга.
• МН_СостояниеАктивностиСеанса — хранит состояние активности текущего сеанса.

Роли и права доступа

      Для подключения обработчика проверки активности необходимо обладать либо правами администратора (спасибо БСП, которая убирает все роли, кроме полных прав, если интересна суть см. статью: //infostart.ru/1c/articles/1878677/), либо ролью МН_КонтрольНеактивностиСеанса. Доступ к настройкам и администрированию осуществляется через роль МН_АдминистрированиеМониторинга. Проверки на наличие этих ролей выполняются безусловно — прямо в коде.

Логирование

      Механизм логирования реализован по принципу двойной записи: события дублируются в собственный регистр сведений и в журнал регистрации. При этом в журнал регистрации пишется более легковесный лог — без слепка активности.

      Запись в регистр можно отключить, а для контроля его объема предусмотрено регламентное задание периодической очистки.

Настройки и исключения

      Функционал расширения позволяет гибко настроить абсолютно все тайминги:

• время неактивности;
• периодичность обновления настроек;
• частоту клиентской проверки неактивности;
• время обратного отсчёта перед завершением сеанса (у меня сейчас 10 минут).

      Слепок неактивности считывается по активным окнам, активному элементу и тексту редактирования. Более подробно об этом можно прочитать в статье Алексея. В моём варианте я отказался от хеширования, поскольку посчитал это излишней нагрузкой, а прямой слепок — более информативным и читабельным.

      Как я уже говорил ранее, самое недопустимое в условиях клиники — это прервать работу врача. Работа монотонная, и пользователь может один и тот же документ заполнять (сидеть в нём) очень долго. Ввиду этого, если у пользователя открыт определенный документ, его вообще нельзя трогать. Поэтому для была предусмотрена возможность исключить из проверки активности:

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