Как устроен модуль сеанса в 1С 8.3 и что в нём писать разработчику

Модуль сеанса 1С — это серверный модуль конфигурации с одним-единственным обработчиком УстановкаПараметровСеанса. Его задача — заполнить параметры сеанса: текущего пользователя, организацию по умолчанию, флаги режима работы. Открывают его в Конфигураторе: правой кнопкой по корню дерева конфигурации → Открыть модуль сеанса.

Частое заблуждение — считать модуль сеанса местом для «кода при запуске программы». Это не так. Он выполняется на сервере, в привилегированном режиме, не видит форм и не может ничего показать пользователю. Окна, предупреждения и проверки при входе пишут в модуле управляемого приложения, а модуль сеанса только готовит значения, которыми потом пользуются запросы, права и бизнес-логика.

Зачем нужен модуль сеанса и где он стоит в конфигурации

Модуль сеанса — один на всю конфигурацию. Он не принадлежит ни справочнику, ни документу, ни общему модулю. Это свойство корневого объекта «Конфигурация», рядом с модулем управляемого приложения, модулем обычного приложения и модулем внешнего соединения.

Что в нём делают на практике:

• 👤 определяют текущего пользователя и пишут ссылку на его элемент справочника в параметр сеанса;
• 🔐 готовят значения для ограничения доступа на уровне записей (RLS) — шаблоны ограничений читают именно параметры сеанса;
• 🏢 запоминают настройки, которые нужны на каждом шагу: основную организацию, признак разделения данных, режим обмена;
• 🧭 ставят флаги, по которым код потом понимает, в каком контексте работает (например, «сеанс запущен регламентным заданием»).

Сам по себе модуль сеанса бесполезен без объектов метаданных Параметры сеанса. Они лежат в ветке Общие → Параметры сеанса. Модуль — это код, который их заполняет, а параметры — переменные, которые живут всё время сеанса.

Когда модуль выполняется

Порядок старта сеанса у тонкого клиента выглядит так:

1. Пользователь проходит аутентификацию.
2. Платформа создаёт сеанс на сервере. Модуль сеанса доступен с этого момента.
3. Выполняются обработчики модуля управляемого приложения: ПередНачаломРаботыСистемы, затем ПриНачалеРаботыСистемы.

Обработчик УстановкаПараметровСеанса срабатывает не только при старте. Платформа вызывает его и позже — когда код обращается к параметру сеанса, которому ещё не присвоено значение. Об этом ниже.

Свойства модуля сеанса и параметров сеанса

У самого модуля сеанса настраиваемых свойств нет. Это просто текст на встроенном языке. Всё, что конфигурируется, относится к параметрам сеанса.

Свойства объекта Параметр сеанса в палитре свойств:

Права на параметры сеанса задают в ролях. У каждого параметра в роли два права: Получение и Установка. Обычному пользователю обычно хватает получения. Установить значение в модуле сеанса можно и без права Установка — модуль работает в привилегированном режиме.

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

Что ограничивает тип параметра

Значение параметра сеанса платформа хранит на сервере и передаёт между рабочими процессами кластера. Поэтому для параметра выбирают простые и неизменяемые типы. Изменяемая коллекция — плохая идея: поменять её «на месте» всё равно нельзя, нужно присваивать параметру новое значение целиком.

Время жизни данных: что видит модуль и сколько хранит

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

Область видимости:

• ✅ значение одного пользователя не видно другим — у каждого сеанса свой набор;
• ✅ значение доступно во всех серверных модулях этого сеанса: общих модулях, модулях объектов и менеджеров, серверных процедурах форм;
• ❌ процедуры и функции модуля сеанса нельзя вызвать из других модулей — экспорт тут не работает ;
• ❌ из клиентского кода к ПараметрыСеанса не обратиться.

Ленивая установка параметров

В платформе 8.3 обработчик УстановкаПараметровСеанса(ТребуемыеПараметры) получает аргумент:

• Неопределено — вызов при старте сеанса;
• Массив строк с именами — вызов при первом обращении к параметрам, которые ещё не установлены.

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

Программная работа с модулем сеанса: примеры кода

Базовый каркас для небольшой самописной конфигурации. При старте ставим дешёвые параметры, остальные — по запросу.

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

	Если ТребуемыеПараметры = Неопределено Тогда
		// Старт сеанса: только то, что нужно всегда и считается быстро
		ПараметрыСеанса.ЭтоФоновыйСеанс = (ТекущийСеансИнформационнойБазы().ИмяПриложения = "BackgroundJob");
		Возврат;
	КонецЕсли;

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

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

Функция НайтиТекущегоПользователя()

	ИдентификаторПользователя = ПользователиИнформационнойБазы.ТекущийПользователь().УникальныйИдентификатор;

	Запрос = Новый Запрос;
	Запрос.Текст =
	"ВЫБРАТЬ ПЕРВЫЕ 1
	|	Пользователи.Ссылка КАК Ссылка
	|ИЗ
	|	Справочник.Пользователи КАК Пользователи
	|ГДЕ
	|	Пользователи.ИдентификаторПользователяИБ = &Идентификатор";
	Запрос.УстановитьПараметр("Идентификатор", ИдентификаторПользователя);

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

	Возврат Справочники.Пользователи.ПустаяСсылка();

КонецФункции

В примере предполагается, что в справочнике Пользователи есть реквизит ИдентификаторПользователяИБ с типом УникальныйИдентификатор, а параметры сеанса ЭтоФоновыйСеанс, ТекущийПользователь, ОсновнаяОрганизация созданы в ветке Общие. Функцию ОсновнаяОрганизацияПользователя() вы пишете сами — откуда брать организацию, зависит от вашей модели данных.

Как это сделано в типовых конфигурациях

В Бухгалтерии 3.0, ЗУП 3.1, УТ 11 и других решениях на Библиотеке стандартных подсистем модуль сеанса почти пустой. Он передаёт управление библиотеке:

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

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

Модуль сеанса в расширении

Расширение конфигурации тоже может иметь свой модуль сеанса. Его обработчик выполняется вместе с обработчиком основной конфигурации, а через аннотации &Перед, &После или &Вместо можно вклиниться в типовую процедуру. Для доработки типовых решений это самый безопасный путь: основная конфигурация остаётся на поддержке.

Отладка

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

Чем модуль сеанса отличается от других модулей конфигурации

Путаница чаще всего возникает с модулем управляемого приложения: оба «срабатывают при входе». Разница — в месте выполнения и задачах.

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

Как не замедлить вход: оптимизация и практика

Модуль сеанса — узкое горло. Он выполняется тысячи раз в день: каждый вход, каждое фоновое задание, каждый вызов HTTP-сервиса. Лишние 300 мс на сеанс при 2 000 сеансов в день — это больше 10 минут чистого ожидания.

Что помогает:

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

Частые ошибки в модуле сеанса

Ещё одна типичная ловушка — менять параметр сеанса из обычного кода «на ходу». Это возможно на сервере при наличии права Установка, но ломает логику: ограничения доступа и кеши начинают работать по новому значению посреди операции. Меняйте параметры только тогда, когда это действительно часть сценария, например при смене рабочей организации.

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