Параметры сеанса 1с 8.3 текущий пользователь. Параметры сеанса. Осуществить блокировку сеансов

Настройка панели разделов - это один из стандартных интерфейсных механизмов. Он предоставляется платформой и доступен пользователям любых прикладных решений. С его помощью пользователь может изменить внешний вид панели разделов в соответствии со своими предпочтениями - установить порядок следования разделов, добавить/удалить разделы и изменить их внешнее представление.

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

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

Вызвать настройку панели разделов можно из главного меню командой Вид - Настройка панели разделов...

Можно изменять порядок разделов, добавлять и удалять разделы. Нельзя добавить любой, произвольный раздел. Добавить можно только те разделы, которые разработчик разместил в панели разделов, но не включил для них видимость. Они перечислены в окне Доступные разделы .

Можно изменить внешний вид закладок, обозначающих разделы. Стандартно разделы обозначаются картинкой и расположенным под ней текстом. Можно отображать разделы только картинками, или только текстом.

Итак в 1С есть справочники. Например, справочник товаров (номенклатуры). Там мы укажем список товаров, которыми торгует наша организация.

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

Товары бывают разные. Например, продукты и химия. Что делать, если руководитель попросит сделать отчет – сколько денег мы заработали на продуктах, а сколько на химии?

Легко! – ответим мы. Нужно добавить справочник Видов товаров, а в справочнике Номенклатура добавить такой реквизит. Теперь когда мы вводим новый товар – нужно будет выбрать вид товара.

Однако девочки не рады такому нововведению – ведь теперь нужно им заполнять целое дополнительное поле, а у них и так много работы и они ничего не успевают. Да и вообще! – говорят они – у нас 900 наименований продуктов, и только 50 наименований химии! Даже дураку ясно, что нужно по умолчанию ставить вид товара продукты.

Отлично! – отметим мы. И… что делать?

Константы 1С

Для редактирования констант открывается форма констант по умолчанию. Каждое поле на такой форме – это одна константа.

Добавить форму констант можно двумя способами:

• Нажать правой кнопкой на ветку Константы 1С и выбрать пункт меню Создать форму констант
• Добавить форму в ветку Общие/Общие формы и в мастере выбрать тип формы – Форма констант.

Посмотреть (и выбрать) форму констант можно следующим образом:

• Войти в свойства конфигурации (правой кнопкой мыши на верхней корневой ветке конфигурации, которую программисты обычно называют «Голова») и использовать свойство Основная форма констант.

Форма констант отличается тем, что основной реквизит формы имеет тип «КонстантыНабор». Это позволяет записывать константы 1С не поштучно, а сразу набором.

Кстати, реквизит формы становится «основным», если в свойствах формы он указан в свойстве Данные.

В программе на языке 1С к любой константе можно обратиться легко и просто:

Знч = Константы.НужнаяКонстанта.Получить(); //считываем
Константы.НужнаяКонстанта.Установить(Знч); //записываем

Параметры сеанса 1С

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

При создании нового товара программа на языке 1С в ПриОткрытииФормы() будет устанавливать значение поля Вид товара в тот, который назначен в константе. Вуаля!

Теперь программа работает, но мы на этом не остановимся! Еще бы – мы же крутые программисты, мы хотим, чтобы программа не просто работала, но и работала быстро!

Где хранятся константы 1С? В базе данных, в специальной таблице. Каждый раз, когда оператор создает новый товар, будет ломиться на сервер и считывать значение константы 1С. А что если операторов 200 человек? Оптимально ли это?

Что же тогда делать?

И тут мы вспоминаем про параметры сеанса 1С. Это значения наподобии констант, которые заполняются в момент старта 1С в режиме Предприятие и доступны сразу на клиенте. Иначе говоря – это некий кеш на стороне клиента.

Кроме того, если в константе список мы можем хранить только в хранилище значений, то в параметр сеанса 1С мы ее уже можем распаковать, правда она будет не динамической – с типом ФиксированныйМассив.

Параметры сеанса 1С это тоже , в окне конфигурации находится в ветке Общие/Параметры сеанса 1С.

Мало добавить параметр сеанса 1С, потому что если он не заполнен, то программа покажет ошибку.

Заполнение (установка) параметров сеанса 1С должна производиться при старте 1С в режиме Предприятие. Нажмите правой кнопкой на верхнюю ветку конфигурации (программисты называют ее «Голова») и выберите пункт меню Открыть модуль сеанса.

В модуле уже может быть функция УстановкаПараметровСеанса(). Если таковой еще нет, то выберите это события в соответствующем выпадающем списке. Вот пример установки значения параметра сеанса 1С:

ПараметрыСеанса.НужныйПараметр = Знч; //запись, один раз в самом начале
Знч = ПараметрыСеанса.НужныйПараметр; //чтение, строго после записи.

Что из себя представляют параметры сеанса.

Параметы сеанса - это общие объекты конфигурации. Они предназначены для использования в ограничении доступа к данным для текущего сеанса (но могут применяться и для других целей). Их значения сохраняются в течение данного сеанса 1С:Предприятия. Использование параметров сеанса позволяет снизить время доступа к данным при ограничении доступа на уровне записей и полей.

Система прав доступа позволяет описывать наборы прав, соответствующие должностям пользователей или виду деятельности. Структура прав определяется конкретным прикладным решением.

Кроме этого, для объектов, хранящихся в базе данных (справочники, документы, регистры и т.д.) могут быть определены права доступа к отдельным полям и записям. Например, пользователь может оперировать документами (накладными, счетами и т.д.) определенных контрагентов и не иметь доступа к аналогичным документам других контрагентов.

Для реализации ограничения прав доступа в прикладных решениях предназначены специальные объекты конфигурации - Роли.

Все права, поддерживаемые системой 1С:Предприятие, можно разделить на две большие группы: основные и интерактивные. Основные права описывают действия, выполняемые над элементами данных системы или над всей системой в целом и проверяются всегда, независимо от способа обращения к данным. Интерактивные права описывают действия, которые могут быть выполнены пользователем интерактивно. Соответственно проверяются они только при выполнении интерактивных операций стандартными способами, причем в клиент-серверном варианте все проверки прав (кроме интерактивных) выполняются на сервере.

Основные и интерактивные права взаимосвязаны. Например, существует основное право Удаление, которому соответствуют два интерактивных права: Интерактивное удаление и Интерактивное удаление помеченных. Если пользователю запрещено Удаление, то и все интерактивные "удаления" также будут запрещены для него. В то же время, если пользователю разрешено Интерактивное удаление помеченных, это значит, что Удаление ему также разрешается.

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

Например, для того, чтобы пользователь имел право Итерактивное удаление помеченных , ему необходимо обладать интерактивными правом Редактирование . Это право, в свою очередь, требует наличия интерактивного права Просмотр.

Право Интерактивное удаление помеченных Удаление . Интерактивное право Редактирование требует наличия основного права Изменение . Интерактивное право Просмотр требует наличия основного права Чтение .

Кроме этого основные права Изменение и Удаление требуют наличия основного права Чтение.

Среди действий над объектами, хранящимися в базе данных (справочниками, документами и т.д.), есть действия, отвечающие за чтение или изменение информации, хранящейся в базе данных. К таким действиям относятся:

• чтение - получение записей или их фрагментов из таблицы базы данных;
• добавление - добавление новых записей без изменения существующих;
• изменение - изменение существующих записей;
• удаление - удаление некоторых записей без внесения изменений в оставшиеся.

Для этих действий в процессе настройки ролей могут быть заданы дополнительные условия на данные (ограничение доступа к данным). В этом случае над конкретным объектом, хранимым в базе данных, может быть выполнено запрошенное действие только в том случае, если ограничение доступа к данным для данных этого объекта принимает значение "истина". Аналогичные условия могут быть заданы и для таблиц базы данных, не имеющих объектной природы (регистров).

Вообще, параметры сеанса - это некоторые значения, которые хранятся для конкретной клиентской сессии. Это может быть "имя пользователя" или "список регионов", доступных для конкретного пользователя. Контекст доступности параметров сеанса - "сервер". Поэтому устанавливать и читать их мы можем только на "сервере". Следует отметить, что параметры сеанса кэшируются, т.е. хранятся в памяти клиентского приложения, и поэтому к ним обеспечивается достаточно быстрый доступ.

Что касается области их применения, то в основном это разграничение доступа на уровне детальных записей. Допустим есть список контрагентов, которые сегментированы по различным регионам. Пользователю при входе устанавливается значение параметра сеанса "Регион" (допустим это "62" и "51") и далее в запросах на органичение доступа система может обращаться к параметрам сеанса напрямую -

&Регион

При этом в самих запросах значение параметров сеанса не устанавливается. Система точно знает, что это параметр сеанса.

Посмотрим на типы данных, которые могут принимать параметры сеансов:

Среди доступных типов мы можем видеть не только стандартные типы (ссылочные типы, примитивные типы данных), но и такие типы как "Фиксированный массив", "Фиксированная структура", "Фиксированное соответствие".

Каким образом выглядит технология работы с параметрами сеанса. Во-первых их нужно инициализировать. Выполняется это в модуле, который исполняется самым первым при старте системы - это "Модуль сеанса". Здесь есть стандартный обработчик события - "УстановкаПараметровСеанса()".

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры) Регионы = Новый Массив; Регионы.Добавить("62"); Регионы.Добавить("51"); ПараметрыСеанса.Регионы = Новый ФиксированныйМассив(Регионы); КонецПроцедуры

Важно отметить, что "Модуль сеанса" всегда исполняется в привилегированном режиме, т.е. контроля прав в этом модуле не существует.

Вообще, касательно привелегированных модулей:

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

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

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

Использование привилегированного режима позволяет, во-первых, ускорить работу, так как не будут накладываться ограничения на доступ к данным, а во-вторых, позволяет выполнять операции с данными от лица пользователей, которым эти данные недоступны.

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

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

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

Для каждой роли мы можем указать возможность получения параметра сеанса и возможность установки. Таким образом для обычного пользователя мы можем указать, что он может параметры сеанса получать, т.е. обращаться к нему, но поменять значение параметра сеанса он не сможет. Это очень важный момент, поскольку при ограничении прав доступа на уровне записей мы позволяем себе опираться на значения которые содержатся в параметрах сеанса. И если вдруг пользователь смог бы превысить свои полномочия, т.е. переустановит параметры сеанса (в нашем случае добавить еще один регион), он мог бы увидеть те документы, которые не должен.

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

Мы рассмотрели объект параметры сеанса и может возникнуть такой соблазн, использовать параметры сеанса как глобальные переменные. Действительно ведь у нас, те переменные, которые объявляются в модуле управляемого приложения доступны только на "клиенте", а как таковых серверных глобальных переменны у нас нет. А параметры сеанса как раз доступны на "сервере".

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

Заполняем свойства параметра:

Теперь нам необходимо задать параметру имя текущего пользователя. Открываем модуль сеанса:

Процедура УстановкаПараметровСеанса(ИменаПараметровСеанса) ПеремИДПользователя,СпрПользователейДляПоиска,СсылкаНаНайденногоПользователя; ЕслиИменаПараметровСеанса= Неопределено Тогда Иначе СпрПользователейДляПоиска=Справочники.Пользователи; ИДПользователя=ПользователиИнформационнойБазы.ТекущийПользователь().УникальныйИдентификатор; ПараметрыСеанса.ТекущийПользователь=СпрПользователейДляПоиска.НайтиПоРеквизиту("ИДПользователя",ИДПользователя); КонецЕсли; КонецПроцедуры

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

//Возвращает ссылку на текущего пользователя базы данных ФункцияТекущийПользователь()Экспорт ВозвратПараметрыСеанса.ТекущийПользователь; КонецФункции Осталось только создать какой-нибудь документ, добавить туда реквизит "автор" и заполнить свойства:

разместить на форме и добавить событие " ПриСозданииНаСервере ":

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

Результат:

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

Хотелось бы обратить внимание на еще одну особенность, связанную с параметрами сеанса. Речь будет идти о "Модуле сеанса" и конкретно о событии - "УстановкаПараметровСеанса". Мы знаем, что это событие вызывается в момент старта приложения. Кроме того контекст "Модуля сеанса" это "сервер" и соответственно может возникнуть желание выполнять какие - либо действия, выполняемые на сервере, при старте приложения. Но делать этого категорически нельзя, потому что обработчик события "УстановкаПараметровСеанса" вызывается не только при старте приложения, но и в момент чтения параметра сеанса, который не был инициализирован.

Отличие понятий сеанс и соединение в «1С:Предприятие 8»

Что Вы узнаете из этой статьи?

• Правильный ответ на один из самых популярных вопросов при сдаче 1С:Эксперт
• Предназначение и особенности соединений и сеансов 1С
• Что хранят сеансовые данные

В чем отличия между сеансом и соединением? Этот, на первый взгляд, простой вопрос на экзамене 1С:Эксперт многих ставит в тупик. Несмотря на немалый опыт программирования, сформулировать четкий и правильный ответ сможет далеко не каждый специалист.

В данной статье проведем детальный разбор этого вопроса. Для начала рассмотрим по отдельности понятия сеанс и соединение в 1С:Предприятие. Отметим, что информация актуальна для версий платформы 8.2.x и 8.3.x.

Сеанс 1С

Обратимся к руководству администратора. В нем понятие сеанса определено следующим образом:

Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя.

Можно сказать, что кластер серверов не видит пользователей, вместо них он видит сеансы и сеансовые данные. В консоли управления кластером в принципе отсутствует раздел «Пользователи», под пользователями кластер понимает сеансы.

Это подтверждает визуальное представление пункта «Сеансы» – иконка отображается в виде пользователей.

Следует уточнить, что под активным пользователем не обязательно понимается клиентское соединение, это также может быть:

• экземпляр клиентского приложения «1С:Предприятие»
• экземпляр веб-приложения, где исполняется веб-клиент
• экземпляр внешнего соединения, полученный из объекта V83.COMConnector
• 1 экземпляр фонового задания
• 1 обращение к Web-сервису

Сеансовые данные

Рассмотрим понятие сеансовые данные. Сеанс содержит в себе некоторую информацию, такую как:

• наименование информационной базы
• номер сеанса
• имя аутентифицированного пользователя информационной базы
• язык интерфейса
• значения параметров сеанса
• временные хранилища
• статистику работы сеанса
• информацию форм управляемого приложения
• некоторые внутренние данные платформы

Такая информация называется сеансовыми данными. Причем для каждого активного пользователя сеансовые данные свои, и актуальны они только на время его работы. Если пользователь покидает базу (завершил сеанс) – его сеансовые данные удаляются.

Данные сеансов хранятся на кластере серверов, за это отвечает менеджер кластера, именно для этого существует сервис сеансовых данных. Чтобы ускорить работу, данные сеансов кешируются в рабочих процессах и в толстых клиентах.

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

Для поддержания сеанса тонкий клиент и веб-клиент обеспечивают обращение к кластеру не реже 1 раза в 10 минут.

Соединение 1С

Теперь разберемся с понятием соединение. Вновь обратимся к руководству администратора:

Соединение является средством доступа сеансов к кластеру серверов «1С:Предприятие», содержит ограниченное множество данных соединения, не отождествляется с активным пользователем.

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

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

Нужно отметить, что сеансовые данные хранятся на сервере, поэтому если разрыв соединения длится менее 20 минут, то на сеансе это не отразится, ведь соединение – всего лишь средство доступа.

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

Также соединения используются для взаимодействия процессов кластера, то есть рабочие процессы (rphost) общаются с менеджером кластера (процесс rmngr) при помощи соединений, а не с помощью сеансов.

Отличия соединения от сеансов

Для того чтобы описать основное отличие данных понятий, приведем аналогию.

Допустим, что сеанс – это пассажир, а соединение – такси. Когда пассажиру необходимо добраться домой (сеансу нужно подключится к серверу), он вызывает такси (сеансу назначается соединение из пула соединений).

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

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

Бурмистров Андрей

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

Глобальная переменная – такая же переменная, как и любая другая, но особенность ее в том, что обратиться к ней можно из любой точки программы, а в случае с параметром сеанса это работает только в пределах текущего сеанса.

Поскольку параметр сеанса является объектом метаданных, он имеет определенные особенности:

• Он может быть определенного типа. Разрешенные типы определяются платформой. Перечень их достаточно обширный, но даже если в данном списке нет нужного для вас, всегда можно сериализовать значение и хранить его в параметре в виде строки.

• Права на него, как и на любой другой объект метаданных, можно ограничивать ролями (как на запись, так и на чтение). При этом существует особенность при использовании его в RLS, но об этом будет написано ниже.
• Он имеет ограничение на объем помещаемых данных в сериализованном виде. Их объем не должен превышать 4 Гб.

Если тип параметра сеанса:

• ФиксированныйМассив
• ФиксированнаяКоллекция
• ФиксированнаяСтруктура

Тогда значение элемента коллекции может быть Неопределено.

Основная область параметров – применение их значений в запросах RLS (ограничение доступа на уровне записей).

Например, нам нужно в запросе RLS установить условие по текущему пользователю. Для этого заводим параметр сеанса «ТекущийПользователь», из кода встроенного языка устанавливаем значение:

ПараметрыСеанса.ТекущийПользователь = <значение>

Таблица.Пользователь = &ТекущийПользователь

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

ТекущийПользователь = ПараметрыСеанса.ТекущийПользователь;

Установить параметр сеанса, то есть его значение, можно только программно и только на сервере. Для этого с клиента потребуется вызвать серверную процедуру. При обращении к параметру сеанса (установка, получение), если параметр не инициализирован, будет вызвана процедура УстановкаПараметровСеанса в модуле сеанса. Данная процедура имеет один параметр ТребуемыеПараметры – массив устанавливаемых идентификаторов параметров сеанса. УстановкаПараметровСеанса вызывается также при установке соединения с информационной базой до вызова всех остальных обработчиков. В этом случае ТребуемыеПараметры будет равен Неопределено.

Рекомендовано использовать отложенную (ленивую) инициализацию, то есть инициализировать параметры сеанса по требованию, а не при старте системы, так как не все параметры сеанса требуются непосредственно при старте системы. Отложенная инициализация выполняется так:

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