Краткое описание задачи.
Необходимо реализовать автоматическую выдачу прав пользователям ЗУП (без участия администратора информационной системы) при оформлении совместителей в конфигурации ЗУП с включенным RLS и настроенным разделением доступа по организациям. Причём доступ к персональным данным физических лиц, пока сотрудник не трудоустроен / отсутствовал.
Подобную задачу решали вот, мы решили пойти немного другим путем.
Описание клиента.
Крупный коммерческий холдинг с количеством сотрудников > 15000, территориальное распределение — это вся Россия со всеми часовыми поясами, но в выходные было нерабочее время, которое мы использовали как технологическое окно.
Глоссарий
ГДФ - группа доступа физических лиц.
ГД - группа доступа.
ИБ - информационная база.
Совместители - сотрудники, которые работают в разных организациях внутри холдинга.
Об исполнителях.
Всем привет, меня зовут Галац Михаил, я работаю в компании Первый Бит на Спортивной. Мы с моим коллегой Экспертом по технологическим вопросам Алексеем Яскеляйненом Iaskeliainen довелось решить интересную задачу в конфигурации 1С Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.34.108).
Пример задачи.
Есть физическое лицо Иванов и сотрудник Иванов Москва, который оформлен в организации Москва с ним работает Кадровик Москва, который ведет организацию Москва.
Решено Иванова трудоустроить в организацию Волгоград как совместителя. Для этого Кадровик Волгоград должен его принять совместителем в организацию Волгоград на соответствующую должность.
- Создать сотрудника Иванов Волгоград.
- Создать документ прием на работу.
Как сейчас это реализовано.
До выполнения доработки функционала, кадровик Волгоград обращается к администратору ЗУПа для выдачи дополнительных прав на физическое лицо Иванов. Администратор ЗУПа создает именную группу доступа физического лица (ГДФ), данную ГДФ добавляется во все группы доступа ГД организации Волгоград. После запускается обработка по расписанию "Обновление доступа на уровне записей" и в течении 5 минут кадровик Волгоград имеет доступ к физ лицу Иванов и кадровик выполняет все ему привычные действия для приема на работу.
Как планируется автоматизировать
В форме справочника сотрудника при создании сотрудника в организации Волгоград подбирать физическое лицо в привилегированном режиме, по сути та же логика, что и при создании физического лица. После создания сотрудника, он будет доступен всем кадровикам организации Волгоград в которой он создан, то есть ГДФ нового сотрудника добавляется в ГД кадровика Волгоград.
После создания сотрудника кадровик создает кадровый документ “Прием на работу”, после этого действия добавляется ГДФ в ГД для другой группы сотрудники расчетчики Волгоград для выполнения расчет зарплаты, отпуска и прочее.
Получение доступа к физическому лицу к которому нет доступа у кадровика Волгоград выполняется путем добавления его в отдельную ГД, я сделал отдельную константу, в которой хранится ГД “Кадровик общий”. Данная группа нужна, чтобы любой кадровик мог видеть физических лиц еще не трудоустроенных и создать сотрудника в любую организацию.
В базе ЗУПа включен производительный вариант работы RLS, а также выполнены следующие настройки прав доступа:
Рисунок 1. Настройки прав пользователей в ЗУП
То есть максимальное возможное разделение прав, которое есть в типовом функционале RLS, который реализован в БСП. Также надо четко понимать, что под такую модель нужно больше ресурсов со стороны сервера приложений, лучше выносить на отдельный сервер выдачу прав, но об этом в подведении итогов напишу.
Мы внутри команды внедрения решили ничего не придумывать нового, а просто автоматизировать то, что делала тех поддержка, чтобы сохранить типовой механизм выдачи прав, сделать изменения в ИБ, так чтобы обработка «Обновление доступа на уровне записей» подхватила изменения и предоставила доступ по существующей логике.
Рисунок 2. Расположение ссылки на вызов обработки «Обновление доступа на уровне записей»
Вся реализация функционала разбита на 2 этапа:
Этап 1. Создать именные группы доступа физических лиц с именем ФИО+дата рождения рисунок 3 и раскидать ГДФ по ГД с наименование организации для примера приведены ГД Кадровик разных организаций рисунок 4.
Рисунок 3. Пример название групп, который необходимо создать в рабочей базе
Рисунок 4. Пример название ГД у кадровиков разных организаций
Этап 2. В каждую ГД добавить ГДФ, где раньше было физическое лицо, чтобы у кадровиков, расчетчиков сохранился доступ к объектам системы, который есть на текущий момент (физические лица, сотрудники, документы, кадровая история и прочее), то есть делаем как было, но более гибко в плане разделения доступа.
Пункты 1 и 2 реализованы обработкой, которая создает ГДФ и раскидывает их по ГД, там где было физическое лицо, чтобы не потерять, то разделение прав которое было до изменений.
Ниже приведен скрин из рабочей базы с настройкой для одной организации и всех сотрудников, которые в ней трудоустроены, обратите внимание тут их 292 ГДФ (физических лица) и ГДФ по целевой схеме уже создана.
Рисунок 5. Результат выполнения обработки по созданию ГДФ
Далее права выдаются запускается по расписанию обработка «Обновление доступа на уровне записей» она будет работать долго, так выполняется глобальный пересчет по всем объектам в системе в нашем случае это 6-8ч.
Вариант 1. Физического лица нет, его надо создать в ЗУПе.
Рисунок 6. Бизнес процесс. Создание физического лица
Пользователь с ролью Кадровик + «Наименование организации», открывает Список физических лиц, жмет Создать или создает физическое лицо из формы Сотрудника.
При создании физического лица отрабатывает БСП метод ПослеЗаписиНаСервере
&НаСервере
Процедура ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
// СтандартныеПодсистемы.УправлениеДоступом
УправлениеДоступом.ПослеЗаписиНаСервере(ЭтотОбъект, ТекущийОбъект, ПараметрыЗаписи);
// Конец СтандартныеПодсистемы.УправлениеДоступом
Описание с ИТС https://its.1c.ru/db/bsp3111doc#content:2661:hdoc
При заполнении ФИО проверяем есть ли такое физическое лицо в базе, даже если физик есть в ЗУПе, подбор выполняется, хотя у кадровика нет доступа к нему. Если нет подходящего физического лица, то создаем его, а если есть то выбираем и создаем сотрудника.
На примере ниже ввели фамилию Иванов и в привилегированном режиме ищем подходящего физическое лицо, и выводим на свою форму ИНН, СНИЛС, год рождения, чтобы убедиться, насколько подходит физические лица, которые уже заведены в базу.
Выбираем нужное физическое лицо из отдельной формы
Рисунок 7. Пример формы с найденным физическим лицом, но с ограниченным выводом на форму персональных данных.
Если нет подходящего физлица создаем его и ГДФ для него, ниже на рисунке 8, отмечено действие под цифрой 3, для этого заполняем:
- ФИО
- Дату рождения.
- Создать. Для создания ГДФ по шаблону.
- Сохраняем объект.
Рисунок 8. Создание физического лица
При сохранении создаем физическое лицо, новую ГДФ добавляем в специально созданную ГД «Кадровик Общий» и доступ к физическому лицу сразу появляется кто состоит в ГД «Кадровик Общий».
То есть период появится у всех кадровиков, чтобы другой кадровик имел доступ к новому физическому лицу и мог создать сотрудника.
Так как при записи нового физического лица создается ГДФ и в нее добавляется новое физическое лицо, а ГДФ добавляется в ГД, чтобы типовой механизм выдал права, что равнозначно вызову процедуры:
УправлениеДоступомСлужебный.ЗапланироватьОбновлениеЗависимыхСписковПоЗначениямСГруппами (ЗначенияСИзменениямиПоТипам);
Вариант когда выдается доступ на определенный объект (физическое лицо) выполняется при создании, все хорошо (я оцениваю время создание объекта), но создание физического лица увеличилось на 2-3 секунды, это то с чем придется мириться пользователю за новый функционал.
_УстановкаДоступаПоФизическимЛицам._ОбновитьДоступКОбъектуДляВидаПользователей(Сотрудник.ФизическоеЛицо, Ложь);
Чтобы корректно отрабатывала процедура создания физического лица, пришлось добавить привилегированный режим
ОбщийМодуль.СотрудникиФормы.Модуль(181, 35) :
- Так как новый сотрудник добавляется в отдельную ГД, то доступ предоставляется обработкой выдача прав на уровни записи по расписанию, что является аналогией выполнения команды
_УстановкаДоступаПоФизическимЛицам._ОбновитьДоступКОбъектуДляВидаПользователей(Сотрудник, Ложь)
В процедуре при создании нового сотрудника _ПередЗаписью делаем вставку
- Предоставление доступа для «НаименованиеНовогоСотрудника»
Расширение конфигурации "(БИТ) Доработки" Справочник.Сотрудники.Форма.ФормаЭлемента.Форма.Модуль(375, 36) в процедуру "ПослеЗаписиНаСервере"
- Предоставление доступа для метода «СотрудникиФормы.Сотрудники ПослеЗаписьюНаСервере»
Расширение конфигурации "(БИТ) Доработки" Справочник.Сотрудники.Форма.ФормаЭлемента.Форма.Модуль(410, 36) в процедуру ПередЗаписьюНаСервере
- Предоставление доступа для метода «СотрудникиФормы.СотрудникиПередЗаписьюНаСервере»
Выдачу прав сделал точечно на объект только при создании кадрового документа “Прием на работу”.
Дополнительно убрал ручной запуск предоставление прав на уровне записи. Поэтому при создании нового физического лица и сотрудника в явном виде не выполняется команда по обновлению прав, это тоже оптимизация, которая повлияла на скорость предоставления доступа другим сотрудникам на новые объекты.
Реализовали выдачу прав точечно на объект для новых элементов справочников следующей процедурой, важно теперь передается в качестве параметра ссылка на объект, а не массив как было ранее, см рисунок 8.
Процедура _ОбновитьДоступКОбъектуДляВидаПользователей(СсылкаНаОбъект, ДляВнешнихПользователей) Экспорт
ПолноеИмя = СсылкаНаОбъект.Метаданные().ПолноеИмя();
ИдентификаторТранзакции = Новый УникальныйИдентификатор;
ПараметрыОграничения = УправлениеДоступомСлужебный.ПараметрыОграничения(ПолноеИмя,
ИдентификаторТранзакции, ДляВнешнихПользователей);
НовПараметры = Новый Структура(ПараметрыОграничения);
НовПараметры.БезЗаписиКлючейДоступаДляПользователейИВнешнихПользователей = Ложь;
НовПараметры.БезЗаписиКлючейДоступа = Ложь;
ПараметрыОграничения = Новый ФиксированнаяСтруктура(НовПараметры);
ЕстьИзмененияПрав = Ложь;
УправлениеДоступомСлужебный.ОбновитьКлючиДоступаЭлементовДанныхПриЗаписи(СсылкаНаОбъект,
ПараметрыОграничения, ИдентификаторТранзакции, Истина, ЕстьИзмененияПрав);
КонецПроцедуры
Что хотелось бы отметить по итогу задачи.
-
Ресурсов сервера потребуется значительно, отдельный сервер под выдачу прав 16 ядер, думаю целевой сайзинг, не забываем управление где будут запускаться фонки это КОРП лицензии.
-
Помогло в реализации описание процедур из БСП «УправлениеДоступомСлужебный.ЗапланироватьОбновлениеЗависимыхСписковПоЗначениямСГруппами» вот таким вызовом мы говорим обработке: «Обновление доступа на уровне записей», что надо в группе доступа добавить только один новый элемент физического лица для определенной ГД, ускорение получаем за счет того что другие аналитики из ГД не пересчитываются. На рисунке 5 обработка понимает, что последний добавленный элемент это физическое лицо Дарья добавляется в ГД, и для Организации и других 291 физическое лицо пересчитывать права не нужно.
- Надо делать тестовые учения по переезду, а именно я сделал тестовый переезд на прод, чтобы понять хватит ли мне выделенного технологического окна по созданию ГДФ и выдачу прав с учетом нового наполнения ГД. В выходные на рабочем сервере развернул тестовую базу и проделала все действия, поняла что я успеваю и останется время если будут проблемы.
Ресурсов сервера потребуется значительно, отдельный сервер под выдачу прав 16 ядер, думаю целевой сайзинг, не забываем управление где будут запускаться фонки это КОРП лицензии.
Помогло в реализации описание процедур из БСП «УправлениеДоступомСлужебный.ЗапланироватьОбновлениеЗависимыхСписковПоЗначениямСГруппами» вот таким вызовом мы говорим обработке: «Обновление доступа на уровне записей», что надо в группе доступа добавить только один новый элемент физического лица для определенной ГД, ускорение получаем за счет того что другие аналитики из ГД не пересчитываются. На рисунке 5 обработка понимает, что последний добавленный элемент это физическое лицо Дарья добавляется в ГД, и для Организации и других 291 физическое лицо пересчитывать права не нужно.
В частности выполнение обработки по созданию ГДФ и добавление в ГД на отдельной базе на рабочем сервере это у меня заняло 12ч
Пересчет прав в 12 потоков, так как у меня лицензия ПРОФ, 6ч.
Первую обработку конечно можно было оптимизировать, но она разовая и время нам было достаточно, поэтому не стали менять и оптимизировать.
Допущения в решении:
- Используется привилегированный режим при создании нового физического лица и сотрудника.
- Доступны персональные данные физических лиц, на период когда еще не трудоустроены.
- Анализ полного ТЖ показывает, что использование RLS на уровне записей показывает насколько «дорого» надо платить за включенный RLS, привожу ниже статистику длительных запросов фоновых заданий, собранных с рабочей базы за рабочие сутки:
Данные разобраны следующим скриптом, которые выдергивает вызовы CALL из фоновых заданий:
cat d:/temp/1clogs/calls/rphost_*/*.log | grep -E -i ',CALL.+,Module=' | sed -r 's/^[0-9]+:[0-9]+.[0-9]+-//g; s/CALL.+,Module=/CALL,Module=/g; s/,Memory.+//g' | gawk -F',CALL,' '{Dur[$2]+=$1; Execs[$2]+=1} END {for (i in Dur) printf "%.2f=Duration(sec); %d=NumOfExecs; %.2f=Average(sec); %s\n", Dur[i]/1000000, Execs[i], Dur[i]/Execs[i]/1000000, i}' | sort -rnb | head -n 200 > d:/temp/1clogs/callresult_func_sec.txt
Результат разбора ТЖ при включенном RLS за рабочие сутки
169259.12=Duration(sec); 347=NumOfExecs; 487.78=Average(sec); Module=УправлениеДоступомСлужебный,Method=ВыполнитьОбновлениеДоступаСпискаВФоне
46013.63=Duration(sec); 9=NumOfExecs; 5112.63=Average(sec); Module=ДополнительныеОтчетыИОбработки,Method=ВыполнитьОбработкуПоРегламентномуЗаданию
25989.50=Duration(sec); 1021=NumOfExecs; 25.45=Average(sec); Module=УправлениеДоступомСлужебный,Method=ОбновлениеДоступаНаУровнеЗаписей
7587.14=Duration(sec); 1873=NumOfExecs; 4.05=Average(sec); Module=ДлительныеОперации,Method=ВыполнитьСКонтекстомКлиента
7058.23=Duration(sec); 743=NumOfExecs; 9.50=Average(sec); Module=ОбменДаннымиСервер,Method=ВыполнитьОбменДаннымиПоРегламентномуЗаданию
4759.27=Duration(sec); 9=NumOfExecs; 528.81=Average(sec); Module=ЭлектронныйДокументооборотСФСС,Method=ВыполнитьОбменСФСС
3655.35=Duration(sec); 1048=NumOfExecs; 3.49=Average(sec); Module=РаботаСФайламиСлужебный,Method=ИзвлечьТекстИзФайловНаСервере
1853.18=Duration(sec); 525=NumOfExecs; 3.53=Average(sec); Module=ПолнотекстовыйПоискСервер,Method=ОбновлениеИндексаППДПоРасписанию
1138.08=Duration(sec); 148=NumOfExecs; 7.69=Average(sec); Module=ОбработкаНовостейСлужебный,Method=ВсеОбновленияНовостей
517.97=Duration(sec); 74=NumOfExecs; 7.00=Average(sec); Module=ОбменДаннымиЕГАИС,Method=ЗапуститьОбработкуОтветовЕГАИС
258.84=Duration(sec); 109=NumOfExecs; 2.37=Average(sec); Module=СЭДОФСС,Method=ОчередьОбработкиКадровыхДанныхФСС
Обратите внимание на первую строку, держать открытую обработку «Обновление доступа на уровне записей» ресурсозатратно, очевидно, но вот подтверждение фактурой. Реализация прав на уровне записей это третья строка, имеет заметный вес, она в топе тяжелых запросов.
Вывод.
Обязательно согласуйте с бизнесом данные изменения.
Получена очень гибкая система выдачи прав, и для администратора ЗУП меньше трудозатрат, и для бизнеса решена задача - прием совместителя без формирования заявки в техподдержку, но значительно увеличено время таких операциях как запись физического лица, сотрудника, проведение документа ПриемНаРаботу.
Вступайте в нашу телеграмм-группу Инфостарт