Предыстория
Думаю, ситуация знакома многим разработчикам и консультантам 1С.
Необходимо обновить базу клиента, подключить или удалить расширение, изменить структуру данных либо выполнить другую операцию, требующую монопольного режима.
Открываем Конфигуратор, пытаемся обновить конфигурацию базы данных и получаем сообщение о том, что информационная база занята активными пользователями.
Дальше начинается стандартный квест.
Если база клиент-серверная, нужен доступ к кластеру серверов 1С.
В идеальном мире у разработчика есть:
- доступ к консоли администрирования серверов 1С;
- права администратора кластера;
- логин и пароль администратора;
- установленная подходящая версия утилит администрирования;
- доступ к серверу по сети;
- либо настроенный RAS и возможность использовать
rac.
В реальной эксплуатации все часто выглядит немного иначе.
Сервер обслуживается отдельной IT-службой. Администратор кластера неизвестен. Пароль разработчику не дают. Подключаться по RDP нельзя. Сервер находится у другого подрядчика. Порт RAS закрыт. А обновить базу нужно сейчас.
В результате приходится искать администратора и просить:
«Закройте, пожалуйста, всех пользователей в такой-то базе».
Через некоторое время один пользователь снова заходит, и процедура начинается заново.
Для файловых баз отдельного кластера вообще нет, но монопольный доступ от этого получать легче не всегда. Кто-нибудь оставил открытый тонкий клиент на другом компьютере, кто-то отошел на обед, а Конфигуратор продолжает ждать освобождения базы.
При этом в самой платформе уже существует удобный механизм принудительного завершения сеансов.
Нужно только создать ситуацию, при которой Конфигуратор его покажет.
Что получилось
Идея оказалась довольно простой.
Создается техническое расширение конфигурации, содержащее собственный объект метаданных, который требует изменения структуры базы данных.
В моем варианте это обычный независимый непериодический регистр сведений.
Никакой прикладной логики в расширении нет.
Нет общего модуля.
Нет формы.
Нет команды.
Нет обработки.
Нет фонового задания.
Нет обращения к кластеру.
Нет COM-соединения.
Нет rac.
Нет RAS.
Нет вызова методов администрирования.
Расширение нужно только для одного: создать реальное изменение структуры базы данных.
После подключения такого расширения выполняем обычное:
Конфигурация → Обновить конфигурацию базы данных.
Для изменения структуры СУБД платформе требуется исключительный доступ.
Если в этот момент имеются активные пользовательские сеансы, Конфигуратор сообщает:
Ошибка исключительной блокировки информационной базы.
База данных заблокирована...
И ниже появляется нужная кнопка:
«Завершить сеансы и повторить».
Именно ее и используем.
На скриншоте будет хорошо видно штатное окно Конфигуратора:
Ошибка исключительной блокировки информационной базы
и кнопки:
- Отмена;
- Повторить;
- Завершить сеансы и повторить.
Это важный момент: окно и завершение сеансов реализованы самой платформой 1С, а не кодом расширения.
Расширение только создает условие, при котором платформе действительно требуется изменение структуры базы.
Зачем это нужно в клиент-серверной базе
Для меня этот сценарий особенно полезен именно на серверных базах.
Очень распространена ситуация, когда специалисту дали:
- доступ к информационной базе;
- права администратора внутри конфигурации;
- доступ в Конфигуратор;
но при этом не дали никаких административных прав на кластер серверов 1С.
С точки зрения IT-службы это вполне понятно.
Администратор кластера может управлять сразу десятками или сотнями информационных баз. Давать эти права каждому внешнему специалисту действительно не всегда разумно.
Но в итоге разработчик оказывается в интересном положении: конфигурацию менять можно, а завершить мешающие обновлению сеансы нельзя.
Описанный прием позволяет во многих таких случаях вообще не обращаться к кластеру.
Мы не подключаемся к агенту сервера 1С и не пытаемся самостоятельно удалить сеанс.
Мы запускаем штатное изменение структуры базы, а дальше проблему блокирующих сеансов решает механизм Конфигуратора.
То есть административная цепочка становится значительно короче:
Конфигуратор → изменение структуры → исключительная блокировка → завершить сеансы и повторить.
Разумеется, у пользователя, запускающего Конфигуратор, должны быть необходимые права для работы с самой информационной базой и обновления ее конфигурации.
А что с файловой базой
Прием применим и для файлового варианта работы.
Отдельного кластера серверов 1С там нет, поэтому использовать консоль администрирования кластера все равно невозможно.
Но если информационная база открыта другими клиентами, изменение структуры также требует освобождения базы.
Поэтому само расширение никак не привязано к SQL Server, PostgreSQL или клиент-серверному варианту.
Оно не работает непосредственно с сервером.
Его задача значительно ниже уровнем прикладной логики: заставить платформу изменить физическую структуру данных при применении расширения.
Поэтому один и тот же принцип можно использовать и в файловых информационных базах.
Почему именно расширение
Можно задать логичный вопрос: почему не добавить какой-нибудь реквизит непосредственно в основную конфигурацию?
Технически эффект был бы похож.
Но это крайне неудобно.
Во-первых, основная конфигурация после этого становится измененной.
Во-вторых, в типовой конфигурации придется снимать объект с поддержки либо создавать совершенно ненужное изменение.
В-третьих, потом его придется удалять.
В-четвертых, задача вообще не связана с прикладной конфигурацией.
Расширение в этом плане почти идеально.
Оно живет отдельно от основной конфигурации, его можно подключить, использовать и удалить.
При этом подход одинаков для разных решений:
- Бухгалтерия предприятия;
- Управление торговлей;
- Зарплата и управление персоналом;
- Комплексная автоматизация;
- ERP;
- Управление нашей фирмой;
- Розница;
- отраслевые конфигурации;
- собственные конфигурации.
Конкретная прикладная конфигурация здесь практически не важна.
Мы не обращаемся ни к одному ее справочнику, документу, регистру или общему модулю.
Создаем расширение самостоятельно
Теперь непосредственно к реализации.
Создадим расширение с нуля.
Открываем информационную базу в режиме Конфигуратор.
Далее:
Конфигурация → Расширения конфигурации.
Создаем новое расширение.
Я использовал имя:
РПП_АварийноеЗавершениеСеансов
Название может быть любым.
Например:
ТехническоеЗавершениеСеансов
или:
СлужебноеИзменениеСтруктуры
Главное, чтобы потом было понятно, для чего оно создавалось.
Назначение расширения устанавливаем:
Дополнение.
Это важный момент с точки зрения смысла расширения. Мы ничего не исправляем в существующем функционале и ничего не адаптируем. Мы просто добавляем собственный технический объект.
Префикс я использовал:
РПП_
Вы можете использовать собственный префикс.
Например:
ТЕХ_
или префикс вашей компании.
Режим совместимости расширения
Отдельно обращу внимание на свойство:
Режим совместимости расширения конфигурации.
Изначально при создании такого расширения можно случайно получить слишком новый режим совместимости.
Например, если расширение было создано или выгружено на более новой платформе, при попытке открыть его на рабочей машине можно получить сообщение вроде:
Для работы с этим расширением конфигурации необходима версия платформы не меньше, чем 8.5.1.
Текущая версия 8.3.27....
Для рассматриваемого расширения настолько новый режим совершенно не нужен.
В своем варианте я установил:
8.3.12
То есть в свойствах расширения:
Режим совместимости расширения конфигурации = Версия 8.3.12.
Это делает расширение значительно универсальнее по используемым платформам.
Если вы собираете расширение самостоятельно, просто откройте свойства корневого объекта расширения и проверьте этот параметр.
Никакой функциональности платформ последних версий здесь не используется.
Добавляем технический регистр сведений
Теперь главное.
В расширении создаем:
Регистры сведений → Добавить.
Я назвал объект:
РПП_АварийнаяБлокировкаСеансов
Синоним:
РПП аварийная блокировка сеансов
Сразу уточню: название регистра роли не играет.
Более того, сам регистр вообще не занимается блокировкой пользовательских сеансов.
Название просто отражает его техническое назначение.
Можно назвать его:
ТЕХ_ИзменениеСтруктуры
Что даже точнее описывает происходящее.
Настройки регистра
Регистр делаем максимально простым.
Периодичность
Непериодический
Режим записи
Независимый
Использование стандартных команд
Можно отключить.
Пользователю этот регистр вообще не нужен в интерфейсе.
Полнотекстовый поиск
Не используется.
Итоги среза первых и последних
Не нужны.
Формы
Создавать формы регистра также не требуется.
У регистра нет никакой пользовательской функции.
Добавляем одно измерение
Чтобы объект имел нормальную физическую структуру, добавляем одно измерение.
Имя:
Ключ
Тип:
Строка
Длина:
1
Я использовал фиксированную длину строки.
Для измерения можно установить индексирование.
На этом структура регистра фактически закончена.
То есть все расширение состоит из:
Расширение
Регистры сведений
РПП_АварийнаяБлокировкаСеансов
Измерения
Ключ
Все.
Ни одного модуля программного кода создавать не требуется.
Почему это вообще работает
Здесь находится вся суть приема.
Если создать расширение, которое содержит только модуль или какое-нибудь изменение поведения формы, платформа далеко не всегда должна физически изменять структуру базы данных.
Следовательно, ей может не потребоваться та самая жесткая исключительная блокировка.
Нам нужен объект, которому необходима собственная таблица в базе данных.
Регистр сведений идеально для этого подходит.
При первом применении расширения платформа должна создать структуру хранения этого регистра.
Следовательно, выполняется обновление структуры информационной базы.
А изменение структуры должно выполняться при соответствующем уровне блокировки базы.
Если в базе в этот момент есть пользовательские сеансы, препятствующие получению исключительной блокировки, возникает штатный диалог Конфигуратора.
Именно этот диалог нам и нужен.
То есть архитектура решения выглядит примерно так:
Подключаем расширение
В расширении появляется собственный регистр
Платформе требуется создать физическую структуру хранения
Запускаем обновление конфигурации базы данных
Требуется исключительная блокировка
Блокировке мешают активные сеансы
Конфигуратор показывает их
«Завершить сеансы и повторить»
Никакой магии.
Мы просто используем предусмотренное платформой поведение в удобных для себя целях.
Как использовать расширение
После создания расширения сохраняем его.
Затем возвращаемся в основное окно Конфигуратора.
Выполняем:
Конфигурация → Обновить конфигурацию базы данных.
Можно также использовать стандартную клавишу обновления конфигурации базы.
Если в базе сейчас никто не работает, изменение просто применится.
Если база занята и платформа не может получить необходимую исключительную блокировку, появится сообщение об ошибке исключительной блокировки.
В нем будет указано, какой сеанс мешает обновлению.
Например:
База данных заблокирована:
компьютер: developer1c01,
пользователь: ...
сеанс: 10,
приложение: Тонкий клиент
Ниже платформа предупреждает:
Завершение сеансов приведет к аварийному завершению работы всех пользователей информационной базы.
И дает три варианта:
Отмена
Повторить
Завершить сеансы и повторить
Выбираем:
Завершить сеансы и повторить.
После этого Конфигуратор сам выполняет необходимое действие и повторяет попытку обновления базы.
Важное предупреждение
Слово «аварийное» здесь написано не для красоты.
Пользователей действительно отключают принудительно.
Поэтому использовать такой способ нужно осознанно.
Если пользователь прямо сейчас:
- редактирует документ;
- набирает большой текст;
- заполняет форму;
- еще не записал изменения;
- выполняет длительную операцию;
его клиент может быть завершен без возможности корректно закончить работу.
Поэтому если есть возможность предупредить пользователей за несколько минут до обновления, это нужно сделать.
Этот инструмент полезен прежде всего не для того, чтобы ежедневно выбрасывать пользователей из базы, а для административных и аварийных сценариев:
- обновление базы;
- установка расширения;
- техническое обслуживание;
- зависший пользовательский сеанс;
- невозможность получить монопольный режим;
- отсутствие доступа к кластеру 1С.
Расширение не нужно держать в базе постоянно
Это, на мой взгляд, один из главных плюсов подхода.
После того как задача выполнена, расширение можно удалить.
Оно не должно постоянно висеть в рабочей базе.
Фактически логика работы следующая.
Нужно завершить пользовательские сеансы:
- открываем Конфигуратор;
- добавляем техническое расширение;
- обновляем конфигурацию базы данных;
- нажимаем «Завершить сеансы и повторить»;
- выполняем необходимые работы;
- удаляем расширение.
Когда инструмент потребуется снова, расширение можно снова создать или загрузить.
Но есть здесь любопытный нюанс.
Для повторного использования нам снова нужно получить изменение структуры базы.
Если один раз оставить расширение подключенным и больше его не менять, на следующем обновлении структуры может просто не оказаться.
И тогда нужное окно не появится.
Поэтому я использую расширение именно как одноразовый технический переключатель:
Установил ; применил ; использовал ; удалил.
В следующий раз:
Снова установил; снова появилось изменение структуры; снова использовал.
Так поведение наиболее предсказуемое.
Что происходит при удалении
При удалении расширения из информационной базы структура снова изменяется, поскольку технический объект метаданных исчезает.
Поэтому удаление такого расширения тоже является отдельной технической операцией.
После удаления необходимо применить изменение конфигурации базы данных штатным способом.
Именно поэтому я не рекомендую оставлять расширение подключенным просто «на всякий случай».
От него нет никакой пользы в повседневной работе пользователей.
Это скорее отвертка из ящика администратора: достали, сделали работу, положили обратно.
Почему расширение универсальное
В нем отсутствуют заимствованные объекты основной конфигурации.
Мы не используем:
Документы.РеализацияТоваровУслуг
или:
Справочники.Пользователи
или:
ОбщиеМодули.ОбновлениеИнформационнойБазы
или какой-либо другой объект конкретной конфигурации.
Поэтому расширению в принципе все равно, что находится под ним.
УТ это, ЗУП, БП, ERP или самописная конфигурация.
Единственная действительно важная зависимость находится на уровне возможностей платформы 1С и поддержки собственных объектов данных в расширениях.
Именно поэтому я выбрал достаточно старый режим совместимости расширения и не использовал ничего специфического для современных релизов.
Никакого программного кода
Еще раз отдельно подчеркну этот момент, потому что сначала решение может показаться сложнее, чем оно есть на самом деле.
В расширении не нужно писать такую процедуру:
Процедура ЗавершитьВсехПользователей()
Ее вообще нет.
Не нужно получать список соединений.
Не нужно определять идентификаторы сеансов.
Не нужно устанавливать соединение с агентом сервера.
Не нужен логин администратора кластера.
Расширение само по себе никого не отключает.
Отключением занимается Конфигуратор после того, как не смог получить исключительную блокировку базы.
В этом и состоит весь прием.
Почему не внешняя обработка
Изначально возникает идея сделать внешнюю обработку с кнопкой:
«Завершить всех».
Но универсальная внешняя обработка здесь намного сложнее.
Для клиент-серверной базы ей пришлось бы каким-либо способом взаимодействовать с серверной инфраструктурой.
Сразу появляются вопросы:
- доступ к кластеру;
- права;
- версия сервера;
- RAS;
- административная аутентификация;
- клиентские библиотеки;
- безопасность.
Кроме того, программно принудительно завершать чужие соединения из обычного пользовательского контекста специально затруднено по вполне очевидным причинам.
В нашем варианте ничего этого решать не требуется.
Мы передаем работу тому компоненту, который уже умеет это делать: самому Конфигуратору.
А если IT-служба специально не дает доступ к кластеру
Как раз в таком сценарии решение и оказалось наиболее удобным.
Я периодически работаю с базами, где имеется полноценный доступ разработчика к Конфигуратору, но серверную часть администрирует другая организация или внутренний IT-отдел клиента.
Получается парадоксальная ситуация.
Я могу добавить регистр в конфигурацию.
Могу изменить проведение документа.
Могу обновить релиз.
Могу изменить структуру таблиц.
Но не могу нажать кнопку завершения конкретного сеанса через консоль кластера, потому что пароль администратора кластера мне не предоставляют.
Вместо попытки обходить безопасность сервера значительно логичнее использовать штатный механизм, уже доступный из Конфигуратора.
Разумеется, это не заменяет полноценное администрирование кластера.
Но для конкретной задачи получения монопольного доступа этого зачастую достаточно.
Чем этот способ не является
Важно правильно понимать назначение.
Это не полноценная замена консоли администрирования.
Расширение не позволяет:
- просматривать все рабочие процессы кластера;
- управлять лицензиями;
- завершать один выбранный сеанс;
- анализировать соединения;
- управлять блокировками;
- отключать только конкретного пользователя;
- менять параметры рабочего сервера;
- управлять регламентными заданиями.
Если нужно полноценное администрирование серверов 1С, этот инструмент вам не подойдет.
Здесь решается одна конкретная задача:
Мне нужно выполнить операцию из Конфигуратора, для которой необходимо освободить базу, но пользователи продолжают работать, а доступа к административной консоли кластера у меня нет.
Для этой задачи решение получилось крайне маленьким.
Ограничения
У метода есть несколько важных ограничений.
1. Нужен доступ к Конфигуратору
Это очевидно, но все же отмечу.
Если у специалиста нет возможности открыть информационную базу в Конфигураторе и изменять расширения, способ использовать не получится.
2. Нужны соответствующие права
Само наличие Конфигуратора еще не означает возможность обновления конфигурации базы.
Пользователь должен иметь соответствующие административные полномочия.
3. Завершение действительно аварийное
Все несохраненные пользовательские действия могут быть потеряны.
Поэтому применять кнопку нужно только тогда, когда вы понимаете последствия.
4. Не следует постоянно держать расширение подключенным
После первого применения структура уже будет создана.
Если никаких изменений не осталось, следующий запуск обновления не обязан снова создавать ситуацию, ради которой все делалось.
Поэтому удобнее удалить техническое расширение после использования и подключить заново при следующей необходимости.
5. Не выбирайте динамическое обновление, если ваша цель именно получить полное изменение структуры
Если платформа предлагает варианты применения изменений, в данном техническом сценарии нас интересует обычное изменение структуры базы.
Смысл способа именно в необходимости получить полноценную структурную операцию и исключительную блокировку.
Минимальная структура расширения
Для тех, кому нужен совсем короткий рецепт.
Создаем расширение:
Имя:
РПП_АварийноеЗавершениеСеансов
Назначение:
Дополнение
Префикс:
РПП_
Режим совместимости расширения:
8.3.12
Добавляем регистр сведений:
Имя:
РПП_АварийнаяБлокировкаСеансов
Периодичность:
Непериодический
Режим записи:
Независимый
Добавляем измерение:
Имя:
Ключ
Тип:
Строка
Длина:
1
Никаких модулей и форм не создаем.
Сохраняем расширение.
Обновляем конфигурацию базы данных.
При невозможности получения исключительной блокировки выбираем:
«Завершить сеансы и повторить».
После выполнения технических работ расширение удаляем.
Что именно хранится в регистре
Ничего.
В своей задаче я вообще не создаю записи в этом регистре.
Он не является служебным журналом, списком пользователей или таблицей блокировок.
Единственная причина его существования заключается в наличии собственного физического объекта данных.
Поэтому измерение Ключ существует просто для формирования минимальной корректной структуры регистра.
Можно, конечно, придумать более сложный регистр, добавить ресурсы или реквизиты.
Но это совершенно не нужно.
Чем меньше технический объект, тем лучше.
Почему не константа
Можно экспериментировать и с другими объектами данных, но регистр сведений в данном случае удобен своей очевидностью.
Это самостоятельный объект хранения данных.
Он легко создается.
Ему не требуются формы.
Ему не нужны дополнительные типы данных.
Не возникает зависимости от объектов основной конфигурации.
Один регистр плюс одна строка-измерение дают нам именно тот минимальный технический каркас, который нужен.
Безопасность основной конфигурации
Еще одно преимущество заключается в том, что мы вообще не трогаем основную конфигурацию.
Не требуется снимать типовую конфигурацию с поддержки.
Не требуется менять настройки поддержки.
Не требуется заимствовать объекты.
Не нужно объединять конфигурации.
Не нужно потом искать, что именно было изменено ради технической операции.
Основная конфигурация остается такой же, какой была.
Все временное изменение находится внутри отдельного расширения.
Практический сценарий
Допустим, необходимо ночью обновить рабочую клиент-серверную базу.
Пользователей заранее предупредили.
В 22:00 открываем Конфигуратор.
Оказывается, что два человека оставили тонкий клиент открытым.
Один компьютер находится в закрытом офисе.
Второй пользователь подключался удаленно и уже недоступен.
Пароля администратора кластера у разработчика нет.
Можно звонить дежурному системному администратору.
А можно подключить техническое расширение.
Платформа видит новый регистр и начинает обновление структуры.
Получить исключительную блокировку не удается.
Конфигуратор показывает мешающий сеанс.
Нажимаем:
«Завершить сеансы и повторить».
Сеансы завершаются, структура обновляется, после чего можно выполнять запланированные работы.
Когда все завершено, техническое расширение удаляем.
На следующую рабочую задачу оно никак не влияет.
Еще один практический сценарий: файловая база
Небольшая организация использует файловую информационную базу.
База находится на сетевом ресурсе.
Необходимо выполнить техническое обновление.
В офисе десять пользователей, один из которых оставил клиент 1С открытым на рабочем месте.
Искать физически нужный компьютер не всегда удобно.
Принцип остается тем же.
Подключаем техническое расширение, вызывающее изменение структуры, и запускаем обновление конфигурации базы данных.
Дальнейшую работу с блокирующими сеансами выполняет сама платформа.
Почему мне нравится этот вариант
В административных инструментах часто получается обратная зависимость: чем проще задача, тем больше инфраструктуры нужно для ее решения.
Чтобы закрыть один забытый клиент 1С, внезапно требуется:
- сервер;
- административная консоль;
- доступ;
- пароль;
- RAS;
- согласование с IT.
Здесь получилось перевернуть ситуацию.
Мы не пытаемся написать еще один механизм администрирования.
Мы просто создаем условия, при которых уже существующий механизм платформы появляется сам.
Фактически все расширение можно описать одной фразой:
Один пустой технический регистр сведений, существующий только для того, чтобы потребовать изменение структуры информационной базы.
Иногда именно такие маленькие технические приемы экономят больше времени, чем большие обработки.
Заключение
Получился простой универсальный инструмент для ситуации, когда необходимо освободить информационную базу перед техническими работами, но прямого доступа к управлению пользовательскими сеансами нет.
Особенно полезен способ при работе с клиентскими серверами, где IT-служба обоснованно не предоставляет стороннему разработчику права администратора кластера 1С.
При этом решение работает на уровне платформенного механизма изменения структуры и потому не привязано к конкретной прикладной конфигурации.
В расширении нет программного кода.
Нет зависимости от БСП.
Нет командного интерфейса.
Нет внешних компонентов.
Нет обращения к кластеру.
Есть только один технический регистр сведений.
Дальше всю тяжелую работу выполняет сама платформа.
И еще раз отмечу главное правило эксплуатации:
не нужно держать это расширение постоянно подключенным к рабочей базе.
Использовать его удобнее именно как временный технический инструмент:
Подключили
получили изменение структуры
завершили мешающие сеансы
выполнили работы
удалили расширение.
В следующий раз расширение можно создать или подключить заново.
Получается своеобразная одноразовая кнопка вызова штатного механизма исключительной блокировки, причем без вмешательства в основную конфигурацию.
Вступайте в нашу телеграмм-группу Инфостарт