Параметри сеансу. Параметри сеансу 1з8 зберегти параметр сеансу у файл

Стаття продовжує цикл «Перші кроки у розробці на 1С», у ній детально розглянуто такі питання:

• Що таке програмний модуль та з яких розділів він складається?
• Навіщо потрібен модуль докладання? Чому їх два? Коли якийсь запускається? Які тонкощі роботи?
• Які події пов'язані з початком роботи системи, як і де їх обробляти?
• Навіщо потрібен модуль зовнішнього з'єднання? Коли та як його використовувати?
• Коли використовується модуль сеансу?
• Що таке спільні модулі? Які в нього властивості та правила роботи? Для чого потрібно використовувати властивість "Повторне використання значень, що повертаються"?
• Коли використовується модуль форми та які події в ньому можуть бути оброблені?
• Навіщо призначений модуль об'єкта? З яких розділів він складається? Як переглянути доступні події модуля?
• Які тонкощі роботи існують із модулями менеджера значення (для констант) та модулями набору записів (для регістрів)?
• У чому різниця між модулем об'єкта та модулем менеджера? Коли потрібно використати останній?

Застосовність

У статті розглядається платформа "1C:Підприємство" 8.3.4.496. Матеріал є актуальним і для поточних релізів платформи.

Модулі в «1С:Підприємство 8.3»

Модулі – це об'єкти, де міститься програмний код.

У Платформі існує досить велика кількість видів модулів, кожен з яких має своє призначення та особливості.

Будь-який рядок коду повинен знаходитись у якомусь модулі. Розрізняють модулі загального призначення та модулі об'єкта. Деякі модулі можуть бути скомпільовані як на Клієнті, так і на Сервері, а деякі лише на Сервері.

Модуль може складатися з кількох розділів. У розділі опису змінних описуються локальні змінні даного модуля, які можуть бути використані в будь-якій процедурі.

Всередині кожної процедури можна звертатися до змінної модуля. Крім того, всередині самої процедури може бути ще одне оголошення змінної з таким самим ім'ям. Це буде локальна змінна цієї процедури.

Незважаючи на однакову назву, це дві різні змінні: одна використовується всередині конкретної процедури, а інша – поза нею.

У деяких модулях для змінних може бути зазначено місце компіляції (доступність) на Сервері або на Клієнті. Наприклад:

За розділом опису змінних слід розділ процедур і функцій, де вказуються локальні методи даного модуля. У деяких модулях слід вказувати, де буде скомпільовано процедуру або функцію.

У принципі директиву компіляції можна не вказувати. І тут директивою компіляції за умовчанням є Сервер. Тим не менш, для зручності аналізу програмного коду рекомендується явно вказувати, де буде скомпільовано цю процедуру. Порядок опису процедур не має ніякого значення.

Наприкінці модуля, після опису всіх процедур та функцій, розташовується розділ основної програми, де можуть утримуватися деякі оператори, ініціалізуватися локальні змінні модуля форми. Цей розділ виконується під час звернення до модуля.

Приміром, при відкритті форми елемента передусім виконується розділ основний програми модуля форми.

Слід зазначити, що розділ оголошення змінних та розділ основної програми існують не для всіх модулів (тобто в деяких модулях ці розділи неприпустимі). Розділ опису процедур та функцій може існувати абсолютно у будь-якому модулі.

Модуль програми

Цей модуль призначений для того, щоб обробити події запуску програми та завершення його роботи. Наприклад, під час запуску програми можна завантажувати курси валют з Інтернету. Після завершення програми можна переконатися у користувача про його наміри закінчити роботу.

Також у модулі програми існують спеціальні обробники, які дозволяють перехопити зовнішні події від обладнання.

Це можуть бути події від рідера магнітних карток, фіскального реєстратора. І ці події можна якимось чином теж опрацювати.

Слід звернути увагу, що у модулі програми відстежується саме інтерактивний запуск системи.

Модуль програми не працюватиме, якщо запуск програми 1С здійснюється, наприклад, в режимі com-з'єднання. У цьому випадку вікно програми не створюється.

Слід зазначити, що в Платформі 8.3 існує два різних модулі програми: модуль керованого додатка і модуль звичайного додатка. Події модуля керованого додатка відпрацьовуються при запуску Тонкого та Толстого клієнта Керованого додатка та Веб-клієнта.

Модуль Звичайної програмипрацює при запуску Толстого клієнта в режимі Звичайної програми, в якому є звичайний командний інтерфейс у вигляді Головне меню.

Якщо програма працює і в режимі Керованого, і в режимі Звичайної програми, то необхідно описувати процедури-обробники як для модуля Керованого додатка, так і для модуля Звичайної програми.

Модуль Керованого додаткаВи можете вибрати з контекстного меню кореневого вузла конфігурації.

Також цей модуль можна відкрити з палітри властивостей кореневого конфігураційного елемента.

Щоб відкрити модуль Звичайної програми, слід звернутися до налаштувань конфігурації (команда Параметрив меню Сервіс).

Відкриється форма Параметри. На закладці Загальнімає бути вказано режим редагування конфігурації Керований додатокі Звичайний додаток.

У цьому випадку модуль Звичайної програмитакож можна буде відкрити властивості кореневого вузла.

Список подій, які можна обробляти, для Керованогоі Звичайної програмиоднаковий.

У цьому модулі можна розміщувати розділ оголошення змінних, розділ опису довільних процедур та функцій та розділ основної програми. Але крім довільних процедур та функцій у модулі можуть бути розташовані спеціальні обробники подій.

Список доступних обробників можна переглянути, якщо при відкритому модулі викликати список процедур та функцій поточного модуля.

У вікні Процедури та функції відображаються всі процедури та функції цього модуля, а також події, для яких обробники ще не створені.

Є дві події, пов'язані з початком роботи системи (“перед” та “прі”). Дві події, пов'язані із завершенням роботи системи (“перед” та “при”). А також опрацювання зовнішньої події (наприклад, події торговельного обладнання).

Коли виконується обробник події “перед”, вважається, що дія ще скоєно. Коли виконується обробник події “при” – дія вже вчинена.

Подія ПередПочаткомРоботиСистемивиникає в той момент, коли проводиться запуск Підприємства 8.3, але сама програма ще не з'явилася на екрані. Ця подія має такий параметр, як Відмова.

Якщо цей параметр набуде значення Істина, то програма не запуститься. Подія ПриПочаткуРоботиСистемиприпускає, що дія вже здійснена, вікно вже створено, і в цьому випадку ми можемо, наприклад, відобразити якусь спеціальну форму. Від запуску відмовитись уже не можна.

Аналогічно перед завершенням роботи системи програма ще відкрита і можна відмовитися від її завершення. Після завершення роботи системи вікно програми вже закрилося. Можливо виконати лише додаткові дії, наприклад, видалення якихось файлів або відправлення електронного листа.

У модулі Керованого додаткане вказуються директиви компіляції процедур та функцій, оскільки модуль повністю компілюється на стороні Клієнта. Це означає, що у процедурах та функціях модуля ми не зможемо безпосередньо звернутися, наприклад, до довідників.

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

У модулі Звичайної програмиподібних обмежень немає, оскільки даний модуль компілюватиметься під час завантаження Толстого клієнта. У товстому клієнті доступні практично всі типи даних.

Процедури, функції та змінні модулі програми можуть бути описані як експортні.

Оскільки модуль скомпільований повністю на Клієнті, це означає, що в клієнтських процедурах ми можемо звертатися до даного методу та даної властивості.

Наприклад, з модуля форми якогось об'єкта можна викликати процедуру або функцію модуля програми. Однак для опису загальних алгоритмів рекомендується використовувати Загальні модулі. Основне призначення модуля програми – обробити точку старту та точку завершення.

За аналогією з модулем програми даний модуль призначений для того, щоб обробити подію відкриття програми та подію завершення роботи.

На відміну від модуля програми, який ініціюється у момент інтерактивного запуску програми, модуль зовнішнього з'єднання працює як com-соединения, тобто. коли створюється об'єкт 1С:Підприємство 8 і здійснюється підключення до певної бази.

У цьому модулі є події: ПриПочаткуРоботиСистемиі ПриЗавершенніРоботиСистеми.

Модуль зовнішнього з'єднання можна відкривати, використовуючи або контекстне меню на рівні кореневого об'єкта конфігурації, або палітру властивостей кореневого вузла.

Сам процес зовнішнього з'єднання – це процес програмної роботи з інформаційною базою, а чи не інтерактивний. Відповідно, в цей момент не можна використовувати діалогові форми, виводити попереджувальні повідомлення, так як немає інтерфейсу користувача.

У Модулі зовнішнього з'єднання можна описувати експортні змінні та експортні методи, які будуть доступні на тій стороні, де відбувається зовнішній виклик 1С:Підприємство 8.3.

Оскільки у зовнішньому з'єднанні немає інтерфейсу користувача, Модуль зовнішнього з'єднання компілюється повністю на Сервері.

Модуль сеансу

Цей модуль потрібний для того, щоб ініціалізувати параметри сеансу. Параметри сеансу – це швидкі глобальні змінні, значення яких доступні будь-де конфігурації.

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

У Модулі сеансу передбачено подію УстановкаПараметрівСеансу.

При старті програми дана процедура викликається найпершою. Параметри сеансу потрібні для будь-якої роботи програми: як при інтерактивному запуску, так і при запуску в режимі зовнішнього з'єднання.

Модуля сеансу описує різні дії з ініціалізації параметрів сеансу в залежності від різних умов.

В даному модулі, як правило, описуються кілька процедур, що викликаються з процедури УстановкаПараметрівСеансу. Тому всі ці процедури виділено в окремий модуль.

Модуль сеансу завжди виконується у привілейованому режимі. Це означає, що не буде перевірено права доступу при зверненні до бази даних. Модуль сеансу компілюється на сервері, тобто. можливе звернення до будь-яких серверних методів (зокрема і читання значень із бази).

У Модулі сеансу можна визначати лише процедури та функції, тобто. немає розділу опису змінних і немає розділу основної програми. Модуль сеансу не може описувати експортні методи.

Якщо при запуску системи необхідно виконати деякі дії на Сервері, наприклад створити елемент будь-якого довідника, то, як варіант, можливо використовувати Модуль сеансу, т.к. він компілюється на сервері і завжди достовірно виконується при старті системи. Однак при цьому необхідно враховувати такі моменти:

• процедура УстановкаПараметрівСеансувиконується не тільки під час старту системи, а також при зверненні до неініціалізованих параметрів сеансу. Тобто. обробник УстановкаПараметрівСеансу може викликатися неодноразово в процесі роботи програми;
• якщо кількість елементів у масиві параметрів сеансу дорівнює нулю (у масиву необхідних параметрів тип даних невизначено), це момент запуску програми;
• оскільки Модуль сеансу працює у привілейованому режимі та перевірки прав доступу не буде, слід дуже акуратно працювати з об'єктами бази даних, тому що користувач може отримати доступ до тих даних, які йому не повинні бути надані;
• під час запуску системи достовірно ще відомо: чи буде запущено додаток. При цьому в обробнику події Встановлення параметрів Сеансу можуть бути зайві дії.

Дані модулі є опис деяких загальних алгоритмів, тобто. процедур та функцій, які можуть викликатися з різних місць.

Логічно пов'язані методи можна групувати у різні Загальні модулі. Ці модулі створюються всередині гілки Загальні.

Можна додати будь-яку кількість спільних модулів. Щоб використовувати методи Загальних модулів в інших місцях конфігурації, необхідно їх визначати з ключовим словом Експорт. Клієнтські процедури загальних модулів будуть доступні на Клієнті, а серверні – на Сервері.

У Загальних модулях доступний лише розділ опису процедур та функцій. Тобто. у Загальному модулі не можна описувати змінні та не можна описувати розділ основної програми.

Якщо потрібна глобальна змінна, можна використовувати або параметри сеансу, або експортні змінні модуля програми.

Для Загальних модулів можна встановити певні параметри, які впливатимуть на поведінку цього модуля. Якщо для Загального модуля виставлено властивість Глобальний, то оголошені в даному модулі експортні методи будуть доступні безпосередньо, без будь-яких додаткових вказівок.

Тобто. даний Загальний модульбратиме участь у формуванні глобального контексту конфігурації.

Властивість Глобальнийдля загальних модулів може бути корисним. Однак не варто використовувати його повсюдно для всіх загальних модулів.

Ті , які позначені ознакою Глобальний, компілюватимуться при старті системи. Чим більше таких модулів, тим повільніше програма стартуватиме.

Якщо прапор Глобальнийдля Загального модуляне вказано, то компіляція даного модуля буде виконуватися в момент першого звернення до нього (тобто вже після старту системи).

З іншого боку, використання глобальних загальних модулів впливає розуміння коду. Виклик методів не глобального загального модуля здійснюється через ім'я Загального модулята ім'я методу, наприклад:
Модуль Розрахунки Собівартості.

При цьому імена Загальних модулів повинні відображати зміст процедур, які в них описуються. Вказівка ​​імені Загального модуля під час виклику процедури сприяє кращому розумінню коду.

Для Загального модуляв Палітрі властивостейможна встановити властивість Привілейований.

У привілейованому модулі не контролюються права доступу. Це необхідно в тому випадку, якщо у Загальний модульпотрібно виконувати масову обробку даних, отримання даних із бази.

Контроль прав доступу збільшує час звернення до бази даних, а масові алгоритми найчастіше мають працювати якнайшвидше.

Наприклад, ресурсомісткою операцією є розрахунок заробітної плати. Необхідно, щоб вона виконувалася якнайшвидше. Для цього алгоритми, які розраховують заробітну плату, поміщають у привілейовані .

При цьому всі процедури, які забезпечують заповнення документів щодо нарахування заробітної плати, знаходяться поза цими Загальних модулів. Саме у цих процедурах і виконується контроль за правами доступу.

Таким чином, можна досягти значного підвищення швидкодії. Особливо це стосується випадку застосування механізму рядкового розмежування доступу до записів таблиці.

Якщо Загальний модуль є привілейованим, процедури цього модуля можуть бути скомпільовані тільки на Сервері.

Бувають ситуації, коли користувачеві якийсь об'єкт має бути недоступним, наприклад, певний довідник. Але при проведенні якогось одного документа звернення до цього довідника необхідне.

Тобто. виникає потреба тимчасово розширити права користувача, та був повернути в вихідний стан. Цей ефект може бути отриманий при використанні привілейованих Загальних модулів.

Для цього в привілейованому Загальний модульслід оформити процедуру, яка звертається до потрібних даних.

Ця процедура викликатиметься з відповідного документа. Тобто. Користувачеві на момент виклику цієї процедури фактично надаються розширені права.

Для Загальних модулівІснує можливість вказувати місце компіляції. За допомогою прапорів встановлюється: чи буде доступний Загальний модуль на Клієнті (керований додаток) на Сервері в режимі роботи Зовнішнього з'єднання.

Крім того, якщо перевести режим редагування конфігурації в Керовану програму та звичайну програму, то буде можливий ще один контекст компіляції – Клієнт (звичайний додаток).

Таким чином, виділяється чотири варіанти функціонування програми. Залежно від запущеної програми, залежно від роботи на Клієнті або Сервері будуть доступні або недоступні певні Загальні модулі.

Крім можливості вказувати прапори компіляції, є можливість вказувати директиви компіляції для процедур і функцій, що знаходяться в Загальному модулі.

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

При цьому процедура не може бути доступна в контексті, який не є доступним в цілому для всього модуля.

Якщо директиву компіляції для процедури (функції) не вказувати, вона буде скомпільована у всіх контекстах, визначених для модуля.

Тобто. насправді буде зроблено кілька копій процедури. Вибір конкретного скомпільованого екземпляра залежить від місця виклику процедури (за правилом найближчого виклику). При цьому слід враховувати, що код такої процедури має бути написаний з урахуванням його доступності у всіх контекстах, визначених для модуля.

Загальні модулі, одночасно доступні в різних контекстах, в основному призначені для того, щоб створювати процедури, доступні в декількох контекстах.

При створенні Загального модуля правилом хорошого тону вважається не вказувати директиви компіляції. Тобто. доступність процедур та функцій має визначатися властивостями самого модуля.

При такому підході в окремих Загальних модулях будуть розміщені клієнтські процедури, і в окремих Загальних модулях – серверні процедури.

Модулі, у яких встановлено кілька прапорів компіляції, практично використовуються вкрай рідко. Це деякі спільні дії, доступні як на Клієнті, так і Сервері. Зазвичай це якісь найпростіші обчислення.

Важливо! З Клієнта можна звертатися до експортних серверних методів Спільного модуля, але тільки в тому випадку, якщо цей Спільний модуль скомпільований тільки на Сервері. При цьому для забезпечення доступу з Клієнта призначений спеціальний прапорець .

Для неглобальних загальних модулів існує можливість кешування тих значень, які повертаються функціями. Тобто. система може після першого виклику функції запам'ятати результат виконання. Якщо ця функція буде викликана знову з тими самими параметрами, система видасть значення вже з кешу.

Мета цього механізму – прискорити повторні дзвінки. Для налаштування такої поведінки необхідно в Палітрі властивостеймодуля виставити відповідне значення для властивості Повторне використання значень, що повертаються.

За промовчанням для цієї властивості визначено значення Не використовувати. Інші можливі значення: кешувати На час дзвінка, або На час сеансу.

Ця властивість має сенс використовувати тільки для тих функцій, результат яких залежить виключно від вхідних параметрів. Даний механізм доступний тільки для глобальних Загальних модулів.

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

Тим не менш, існують певні часові обмеження. Очищення кешу відбувається автоматично через 20 хвилин після потрапляння значення в кеш.

Модуль форми

Цей модуль призначений для того, щоб обробити дії користувача. Наприклад, описати алгоритм реакції програми при натисканні кнопки. Або, наприклад, у момент введення в поле значення одразу ж виконати перевірку на коректність.

Крім подій, що з елементами управління форми (кнопки, поля введення) існують події, пов'язані безпосередньо з формою.

Наприклад, можна опрацювати подію відкриття форми та провести якусь початкову ініціалізацію. Також можна обробити подію закриття форми і перевірити, чи все правильно ввів користувач.

Існують форми керовані та форми звичайні. Модулі даних форм відрізняються передусім тим, що модуль керованої форми чітко поділяється на контекст. Кожна процедура повинна мати директиву компіляції. У звичайній формі весь код використовується на Клієнті.

У модулі керованої форми можна оголошувати процедури та функції, можна оголошувати змінні та описувати розділ основної програми.

Програмний код основної програми виконуватиметься на момент ініціалізації форми, тобто. коли користувач починає її відчиняти. На малюнку представлено перелік стандартних подій для керованої форми.

Список подій керованої форми видно також у списку властивостей безпосередньо самої форми. Цей список викликається у редакторі керованих форм.

У керованій формі можна опрацювати подію запису елемента. Ця подія є лише форм об'єктів (довідників, документів та інших). Якщо форма не прив'язана до конкретного об'єкта, подія запису відсутня.

Для модуля нормальної форми перелік стандартних подій трохи менше, т.к. в керованій формі багато подій зроблено парними (одне виконується на Клієнті, а інше на Сервері). У звичайній формі весь код виконується на Клієнті.

Модуль об'єкту

Дані модулі характерні для довідників, документів, планів видів розрахунків, планів рахунків та багатьох інших об'єктів. Модуль об'єкта призначений для обробки стандартних подій. Наприклад, подія на введення елемента довідника, подія запис елемента, видалення, проведення документа тощо.

У принципі, подія запису існує й у Модулі форми. Але подія запису Модулі форми виникає у процесі інтерактивної записи, під час роботи з конкретної формою.

Подія запису в Модулі об'єкта буде виконуватися за будь-якого запису з будь-якої форми даного об'єкта. Крім того, якщо об'єкт записується програмно, в цьому випадку спрацьовуватиме подія модуля об'єкта.

У події запису Модуля об'єкта можна вбудовувати всі перевірки на коректність даних, що записуються, так як ця процедура буде відпрацьовувати в момент абсолютно будь-якого запису.

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

Нижче на малюнку представлено список доступних подій модуля довідника.

У Модулі об'єкта можна розміщувати розділ опису змінних, описувати довільні функції, які можуть бути не пов'язані з подією, а також розділ основної програми.

У розділі основної програми можна, наприклад, виконувати ініціалізацію локальних змінних модуля. Цей програмний код буде виконуватися при зверненні до цього Модулю об'єкта.

Слід зазначити, що всі процедури Модуля об'єкта скомпільовані на сервері. Відповідно директиви компіляції у процедур та функцій Модуля об'єкта вказувати не потрібно. Деякі об'єкти конфігурації не мають Модулів об'єктів.

Це з особливостями самих об'єктів. До таких об'єктів відносяться Константиі Реєстри. Для Константне існує модуля об'єкта, але існує дуже схожий модуль, який називається Модулем менеджера значення.

У Модулі менеджера значенняможна виконати обробку подій запису Константита обробку перевірки заповнення.

Весь контекст модуля виконується на сервері.

Для регістрів існує модуль набору записів.

У цьому модулі також є можливість обробляти події запису та виконувати перевірку заповнення.

У Модулях об'єктів, Модулях менеджера значення (для констант) та Модулях набору записів (для регістрів) можна описувати методи, які можна робити експортними, і ці методи будуть доступні з-за.

Тобто. Крім використання фіксованих методів класу об'єктів, можна створювати для об'єкта додаткові методи в Модулі об'єкта. У цьому модулі слід описати відповідну процедуру з ключовим словом Експорт.

Тоді можна буде звертатися до цієї процедури ззовні. Причому цей метод відображатиметься у контекстній підказці. Нові методи у контекстній підказці виділяються синім шрифтом (синій значок p()для процедур та f()для функцій).

Аналогічно можна створювати нову властивість, оголосивши змінну з ключовим словом Експорт. До цієї властивості також можна буде звертатися з зовні.

Таким чином можна розширювати функціональність об'єктів (довизначати нові методи та нові властивості). У цьому характеристики є динамічними і зберігаються у базі даних.

Якщо необхідно використовувати для об'єкта властивість, яка зберігатиметься у базі даних, слід створювати реквізит об'єкта.

Модуль менеджера

Цей модуль існує для багатьох об'єктів (довідники, документи, регістри та ін.). Модуль відкривається або через контекстне меню для об'єкта або через Палітру властивостейабо через вікно редагування.

У Модулі менеджера можна перевизначити деякі стандартні події. ОбробціОтриманняДанихВибору, коли вибирається елемент із довідника, можна зробити якусь додаткову фільтрацію чи перевірку.

Крім цього, у Модулі менеджера можна створити додаткові методи та вказати, що вони є експортними. У цьому випадку можливе звернення до даних методів ззовні.

Для того, щоб виконати це звернення, необхідно отримати тип даних Довідник Менеджер.

Відмінність експортних методів Модуля менеджера і Модуля об'єкта у тому, що з звернення до методу Модуля об'єкта спочатку необхідно одержати сам об'єкт (тобто якимось чином одержати посилання і далі це посилання перетворити на об'єкт).

Після цього будуть доступні експортні змінні та методи Модуля об'єкта. Для Модуля менеджера звернення простіше, наприклад:
Довідники.Контрагенти.Ім'яМетода

Це два різні звернення. Перетворення з посилання на об'єкт (метод ОтриматиОб'єкт) - це досить серйозна дія для системи, так як при отриманні об'єкта читаються абсолютно всі дані цього об'єкта, що може бути досить тривалим.

Друга відмінність у тому, що МодульОб'єктавикликається у контексті конкретного елемента. Відповідно можна вважати, що він застосовний для даного елемента (у більшості випадків закладається саме така логіка).

Що стосується Модуля менеджера, то в ньому описується якась спільна дія для групи або для всіх елементів довідника чи документа. Наприклад, якщо потрібно надрукувати елемент довідника, можна використовувати Модуль об'єкта.

Але в Модулі менеджера можна створити більш універсальний механізм, який друкуватиме, в тому числі, і групу елементів.

Крім того, звернення до Модуля об'єкта – це все-таки триваліша дія. Тому вирішувати це завдання в модулі менеджера краще.

На цьому завершимо наше знайомство з модулями у конфігурації системи «1С:Підприємство». Якщо підвести коротке резюме всьому вищенаписаному, то в сухому залишку виходять такі висновки:

• Програмний модуль – це частина конфігурації, яка може містити лише текст вбудованою мовою 1С
• Програмні модулі класифікуються за видами, які ми розглянули у статті. Кожен вид визначається місцем розміщення та доступним програмним контекстом.
• Структура модуля складається з деяких розділів, що розташовуються у певній послідовності. Склад розділів визначається видом модуля.

Також наголосимо, що ми свідомо опустили один вид модуля, а саме модуль команди. Нічого примітного він не представляє, і ми пропонуємо вам самостійно ознайомитися з його функціональністю.

Поки весь наш програмний код ми розглядали уривчасто від прикладного рішення, і, як правило, писали його в якійсь своїй невеликій тестовій конфігурації. А ви знаєте, що «не можна просто так взяти» і почати редагувати код типової конфігурації? Ні? Тоді у наступній статті ми все це пояснимо!

Налаштування панелі розділів- це один із стандартних інтерфейсних механізмів. Він надається платформою та доступний користувачам будь-яких прикладних рішень. За його допомогою користувач може змінити зовнішній вигляд панелі розділів відповідно до своїх переваг - встановити порядок прямування розділів, додати/видалити розділи та змінити їхнє зовнішнє уявлення.

Наприклад, панель розділів, спроектована розробниками, може виглядати так:

Користувач може прибрати розділи Товарні запасиі Підприємствоі сказати, щоб розділи відображалися лише у вигляді тексту.

Викликати налаштування панелі розділів можна з головного меню командою Вигляд - Налаштування панелі розділів...

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

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

Розглянуті параметри в 1С:Підприємство представлені як об'єкт метаданих. Фактично, це нічим іншим, як глобальна змінна, прив'язана до поточного сеансу.

Глобальна змінна - така ж змінна, як і будь-яка інша, але особливість її в тому, що звернутися до неї можна з будь-якої точки програми, а у випадку параметра сеансу це працює тільки в межах поточного сеансу.

Оскільки параметр сеансує об'єктом метаданих, він має певні особливості:

• Він може бути певного типу.Дозволені типи визначаються платформою. Перелік їх досить великий, але навіть якщо в цьому списку немає потрібного для вас, завжди можна серіалізувати значення та зберігати його у параметрі у вигляді рядка.

• Права на нього, як і будь-який інший об'єкт метаданих, можна обмежувати ролями (як на запис, так і на читання). При цьому існує особливість при використанні його RLS, але про це буде написано нижче.
• Він має обмеження на обсяг даних, що розміщуються в серіалізованому вигляді.Їхній обсяг не повинен перевищувати 4 Гб.

Якщо тип параметра сеансу:

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

Тоді значення елемента колекції може бути НЕ визначено.

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

Наприклад, нам потрібно в запиті RLS встановити умову поточного користувача. Для цього заводимо параметр сеансу "Поточний Користувач", з коду вбудованої мови встановлюємо значення:

Параметри Сеансу.ПоточнийКористувач =<значение>

Таблиця.Користувач = &ПоточнийКористувач

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

Поточний Користувач = Параметри Сеансу.

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

Рекомендовано використовувати відкладену (ліниву) ініціалізацію, тобто ініціалізувати параметри сеансу на вимогу, а не при старті системи, оскільки не всі параметри сеансу потрібні безпосередньо при старті системи. Відкладена ініціалізація виконується так:

Оскільки параметр сеансу прив'язаний до сеансу, не вдасться звернутися до параметра сеансу з методу, що виконується у фоні, оскільки це вже інший сеанс. Цей нюанс може стати несподіванкою, тому краще до нього підготуватися заздалегідь, передавши потрібне значення як параметр методу та ініціалізувавши параметр сеансу на початку процедури.

Що собою представляють параметри сеансу.

Параметри сеансу – це загальні об'єкти конфігурації. Вони призначені для використання в обмеженні доступу до даних для поточного сеансу (але можуть застосовуватись і для інших цілей). Їх значення зберігаються протягом цього сеансу 1С:Підприємства. Використання параметрів сеансу дозволяє знизити час доступу до даних при обмеженні доступу на рівні записів та полів.

Система прав доступудозволяє описувати набори прав, які відповідають посадам користувачів чи виду діяльності. Структура прав визначається конкретним прикладним рішенням.

Крім цього, для об'єктів, що зберігаються в базі даних (довідники, документи, регістри тощо) можуть бути визначені права доступу до окремих полів та записів. Наприклад, користувач може оперувати документами (накладними, рахунками тощо) певних контрагентів і мати доступу до аналогічних документів інших контрагентів.

Задля реалізації обмеження прав доступу прикладних рішеннях призначені спеціальні об'єкти зміни - Роли.

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

Основні та інтерактивні права взаємопов'язані. Наприклад, існує основне право Видалення, якому відповідають два інтерактивні права: Інтерактивне видалення та Інтерактивне видалення позначених. Якщо користувачу заборонено Видалення, всі інтерактивні "видалення" також будуть заборонені для нього. У той же час, якщо користувачеві дозволено інтерактивне видалення позначених, це означає, що видалення йому також дозволяється.

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

Наприклад, для того, щоб користувач мав право Ітерактивне видалення помічених, йому необхідно мати інтерактивне право Редагування. Це право, своєю чергою, вимагає наявності інтерактивного права Перегляд.

Право Інтерактивне видалення помічених Вилучення. Інтерактивне право Редагуваннявимагає наявності основного права Зміна. Інтерактивне право Переглядвимагає наявності основного права Читання.

Крім цього, основні права Змінаі Вилученнявимагають наявності основного права Читання.

Серед дій над об'єктами, що зберігаються в базі даних (довідниками, документами тощо), є дії, які відповідають за читання або зміну інформації, що зберігається в базі даних. До таких дій належать:

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

Для цих дій у процесі налаштування ролей можуть бути задані додаткові умови на дані (обмеження доступу до даних). У цьому випадку над конкретним об'єктом, що зберігається в базі даних, може бути виконана запитана дія лише в тому випадку, якщо обмеження доступу до даних для даних цього об'єкта набуває значення "істина". Аналогічні умови можуть бути і для таблиць бази даних, які мають об'єктної природи (регістрів).

Взагалі параметри сеансу - це деякі значення, які зберігаються для конкретної сесії клієнта. Це може бути ім'я користувача або список регіонів, доступних для конкретного користувача. Контекст доступності параметрів сеансу – "сервер". Тому встановлювати та читати їх ми можемо лише на "сервері". Слід зазначити, параметри сеансу кешуються, тобто. зберігаються в пам'яті клієнтської програми, і тому до них забезпечується швидкий доступ.

Що стосується сфери їх застосування, то в основному це розмежування доступу на рівні детальних записів. Припустимо, є список контрагентів, які сегментовані по різних регіонах. Користувачу при вході встановлюється значення параметра сеансу "Регіон" (припустимо це "62" та "51") і далі в запитах на організацію доступу система може звертатися до параметрів сеансу безпосередньо -

&Регіон

При цьому в самих запитах параметрів сеансу не встановлюється. Система точно знає, що це параметр сеансу.

Подивимося типи даних, які можуть приймати параметри сеансів:

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

Як виглядає технологія роботи з параметрами сеансу. По-перше, їх потрібно ініціалізувати. Виконується це в модулі, який виконується першим при старті системи - це "Модуль сеансу". Тут є стандартний обробник події - "Установка параметрів Сеансу ()".

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

Важливо, що " Модуль сеансу " завжди виконується у привілейованому режимі, тобто. контролю прав у цьому модулі немає.

Взагалі, щодо привілейованих модулів:

Існує можливість призначення привілейованих модулів. У такі модулі можуть бути перенесені операції, які використовують дані, на які поточний користувач не має прав.

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

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

Використання привілейованого режиму дозволяє, по-перше, прискорити роботу, оскільки не накладатимуться обмеження доступу до даних, а по-друге, дозволяє виконувати операції з даними від імені користувачів, яким ці дані недоступні.

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

Зазвичай значення параметрів сеансу беруться зі службових об'єктів, наприклад, з регістра відомості зчитуються значення, що відповідають користувачеві, що входить до системи. Надалі можемо звертатися до параметрів сеансу, тобто. читати значення, перезаписувати у будь-якому серверному програмному коді. Слід зазначити, що й спробуємо звернутися до параметрів сеансу, значення яких не ініціалізовано, станеться помилка.

Оскільки параметри сеансу є об'єктами конфігурації, ми можемо виставити їм права доступу:

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

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

Ми розглянули об'єкт параметри сеансу і може виникнути така спокуса використовувати параметри сеансу як глобальні змінні. Адже у нас, ті змінні, які оголошуються в модулі керованого додатка доступні тільки на "клієнті", а таких серверних глобальних змінні у нас немає. А параметри сеансу доступні на "сервері".

Наприклад, під час створення документа, непогано було б знати його автора. Створюємо новий параметр і задаємо йому ім'я "Поточний Користувач":

Заповнюємо властивості параметра:

Тепер нам необхідно задати параметр ім'я поточного користувача. Відкриваємо модуль сеансу:

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

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

//Повертає посилання на поточного користувача бази даних ФункціяПоточнийКористувач()Експорт ПоверненняПараметриСеансу.ПоточнийКористувач; КінецьФункції Залишилося тільки створити якийсь документ, додати туди реквізит "автор" та заповнити властивості:

розмістити на формі та додати подію "При створенні на сервері":

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

Результат:

Але все ж таки не слід використовувати параметри сеансу саме як глобальні змінні. Оскільки вони зберігаються на сервері, тобто вони розширюють сеансові дані нашого робочого процесу і у параметрів сеансу розширений інтерфейс, на відміну від змінних. По суті, об'єкт призначений для вирішення іншого завдання. По-перше параметри сеансу жорстко типізовані, тобто. ми можемо вказати тип даних, який зберігається у параметрі сеансу і змінити його не можна. Крім цього, на рівні параметрів сеансу налаштовуються права доступу. І також основне призначення параметрів сеансу – це використання звернення до них у запитах щодо обмеження доступу на рівні записів. Тому той об'єкт, з яким ми маємо справу, має досить великий командний інтерфейс, і використовувати його як глобальну змінну було б не правильно.

Хотілося б звернути увагу ще на одну особливість, пов'язану з параметрами сеансу. Йтиметься про "Модуль сеансу" і конкретно про подію - "УстановкаПараметрів Сеансу". Ми знаємо, що ця подія викликається у момент старту програми. Крім того контекст "Модуля сеансу" це "сервер" і відповідно може виникнути бажання виконувати якісь дії, що виконуються на сервері, при старті програми. Але робити цього категорично не можна, тому що обробник події "УстановкаПараметрів Сеансу" викликається не тільки при старті програми, але й у момент читання параметра сеансу, який не був ініціалізований.

Параметри сеанси 1С 8.3— змінна, в якій зберігається значення потрібного параметра під час сеансу користувача. По суті це якась глобальна змінна, прив'язана до сеансу поточного користувача.

Використання параметрів сеансу в 1С

Параметри сеансу задаються лише програмно, універсального інтерфейсу для встановлення параметрів сеансу у системі немає. Зазвичай вони задаються при старті системи, у «Модулі сеансу». Якщо параметр не визначено, під час звернення до нього буде викликана помилка.

Приклад установки параметра сеансу 1С

Розглянемо типовий приклад використання параметрів сеансу - встановлення поточного користувача. Приклад я візьму з підготовки до.

У дереві метаданих створимо новий параметр сеансу - Поточний Користувач, призначимо йому тип - Довідник Посилання. Фізичні Особи:

Отримайте 267 відеоуроків з 1С безкоштовно:

У модулі сеансу створимо процедуру, в якій визначатиметься поточний параметр сеансу:

Код процедури: