Параметры сеанса в 1С: что хранят, где задаются и чем опасны

Параметры сеанса нужны, чтобы один раз вычислить значение при входе пользователя и потом быстро читать его из любого места программы. Типичный пример: текущий пользователь, его организация по умолчанию, набор подразделений, на которые у него есть права. Значение живёт на сервере, пока жив сеанс, и пропадает при выходе из программы.

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

Что такое параметры сеанса и как они устроены

Параметр сеанса — именованная переменная, видимая всему коду конфигурации в рамках одного сеанса работы пользователя. Обращаются к ней так: ПараметрыСеанса.ТекущийПользователь.

Чем он отличается от других способов хранить данные:

• 🔹 Глобальная переменная модуля живёт отдельно на клиенте и сервере и не переживёт перезапуск серверного контекста. Параметр сеанса виден на сервере единообразно.
• 🔹 Константа хранится в базе и одинакова для всех. Параметр сеанса свой у каждого сеанса.
• 🔹 Регистр сведений с настройками требует запроса к базе при каждом чтении. Параметр сеанса читается без обращения к таблицам.

Тип каждого параметра задаётся заранее: число, строка, дата, ссылка на справочник, составной тип. Значение «из воздуха» присвоить нельзя — только то, что соответствует типу.

Где параметр создаётся и когда получает значение

Создаётся параметр в Конфигураторе. В дереве конфигурации найдите ветку Общие и в ней Параметры сеанса. Добавляете элемент, задаёте имя и тип. На этом объект готов, но значения у него ещё нет.

Значение появляется в обработчике УстановкаПараметровСеанса в модуле сеанса. Это серверная процедура, которую платформа вызывает при начале сеанса. Ей передаётся параметр ТребуемыеПараметры:

• если он Неопределено — платформа просит заполнить всё сразу при старте;
• если это массив имён — просят только перечисленные параметры, потому что кто-то обратился к ещё не заполненному значению.

Типовая заготовка выглядит так:

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)

    Если ТребуемыеПараметры = Неопределено Тогда
        ПараметрыСеанса.ТекущийПользователь = ПолучитьТекущегоПользователя();
        Возврат;
    КонецЕсли;

    Если ТребуемыеПараметры.Найти("ТекущийПользователь") <> Неопределено Тогда
        ПараметрыСеанса.ТекущийПользователь = ПолучитьТекущегоПользователя();
    КонецЕсли;

КонецПроцедуры

Функция ПолучитьТекущегоПользователя здесь условная: в вашей конфигурации она будет называться иначе или вычисляться запросом. Платформа вызывает обработчик сама, вручную его запускать не нужно. Поэтому при отладке ставьте точку останова прямо в этой процедуре и входите в базу под тестовым пользователем: так видно, какие параметры и в каком порядке запрашиваются.

Если не обработать ветку с массивом, получите ошибку при первом обращении к параметру: платформа вызовет обработчик, а значение не появится.

Основные параметры сеанса: что в них обычно кладут

В типовых конфигурациях на базе Библиотеки стандартных подсистем состав параметров стандартный, но имена у разных конфигураций отличаются. Смысл же повторяется.

Состав смотрит разработчик в Конфигураторе, а администратор — через отладчик. В вычислении выражения (Отладка → Вычислить выражение) можно ввести ПараметрыСеанса.ИмяПараметра и увидеть значение в работающем сеансе.

Как параметры сеанса влияют на скорость работы

Скорость страдает не от самих параметров, а от того, что делает обработчик заполнения.

Три типичных источника тормозов:

1. Тяжёлый запрос при старте. Обработчик собирает список всех доступных подразделений через большой запрос по нескольким таблицам. Пользователь ждёт, пока форма входа дойдёт до рабочего стола.
2. Заполнение всех параметров подряд. Если в ветке Неопределено считаются все параметры, а читаются из них два-три, остальное — потерянное время. Выгоднее заполнять лениво: в ветке массива считать только нужное.
3. Обращение к параметрам в цикле. Читать значение внутри цикла на миллион итераций дороже, чем один раз сохранить в локальную переменную перед циклом.

Простая проверка: засеките время входа в базу с замером в технологическом журнале или просто секундомером до и после правки обработчика. Если вход занимает заметно дольше, чем открытие самого рабочего стола, проблему стоит искать в модуле сеанса.

Параметры сеанса и безопасность данных

Здесь параметры работают как «паспорт» сеанса. Платформа знает, кто вошёл, и может сравнить это с ограничениями.

Практические применения:

• 🔒 Ограничения доступа к данным на уровне записей. Условие вида «видит только документы своей организации» опирается на значение, которое уже посчитано при входе. Без этого приходилось бы выполнять запрос на каждое чтение строки.
• 🔒 Отсечение лишнего в формах. Форма проверяет параметр и скрывает кнопку, которой у этого пользователя быть не должно.
• 🔒 Защита от подмены. Значение лежит на сервере, и клиент не может его подделать, в отличие от переменной, переданной с клиента.

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

Типичные ошибки при работе с параметрами сеанса

Отдельная ловушка: цепочки зависимостей. Если параметр А при заполнении читает параметр Б, а Б читает А, получится бесконечный вызов обработчика. Считайте зависимые параметры в одной процедуре и в правильном порядке, а не друг через друга.

Как оптимизировать параметры сеанса под разные сценарии

Разные задачи требуют разного подхода к заполнению.

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

Третий приём: храните в параметре не «собранный список строк», а ссылку или идентификатор, по которому нужное достаётся одним быстрым запросом.

Как изменить параметры сеанса: порядок действий

Нужно различать два случая: изменить значение параметра в текущем сеансе и изменить сам состав параметров конфигурации.

Изменить значение в рабочем сеансе

Из кода на сервере: ПараметрыСеанса.ИмяПараметра = НовоеЗначение;. Значение действует только в этом сеансе. У других пользователей оно останется прежним.

С клиента напрямую присвоить нельзя. Пишется серверная процедура, например с директивой &НаСервере, а форма её вызывает.

Добавить или поменять параметр в конфигурации

1. Откройте базу в Конфигураторе. Для изменения конфигурации потребуется доступ к хранилищу или свой файл, смотря как ведётся разработка.
2. В ветке Общие → Параметры сеанса добавьте новый или откройте существующий элемент.
3. Задайте имя и тип.
4. В модуле сеанса дополните УстановкаПараметровСеанса двумя ветками: полной и по массиву имён.
5. Сохраните конфигурацию (F7 или обновление конфигурации базы данных), затем попросите пользователей перезайти.

Если платформа ругается на отсутствие значения после правки, первым делом проверьте ветку по массиву имён: её забывают чаще всего.

Когда параметр сеанса не нужен

Параметр сеанса — не универсальное хранилище. Три случая, где лучше другое решение:

• ❌ Данные нужны всем одинаково. Название фирмы, ставка, общий флаг — это константа или запись регистра сведений. Дублировать их в каждом сеансе незачем.
• ❌ Значение меняется в течение дня. Параметр не следит за изменениями в базе. Остаток, статус документа, курс валюты нужно читать из источника в момент использования.
• ❌ Значение нужно после перезапуска. Пользовательские настройки формы, отборы, последний выбранный период хранятся в настройках пользователя, а не в сеансе.

Хороший признак удачного параметра: значение вычисляется дорого или громоздко, читается десятки раз за сеанс и не должно меняться без перезахода. Если хотя бы одно из условий не выполнено, подумайте о другом механизме.

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

Частые вопросы