Объект полномочий P_ABAP, или как приструнить сервис Who's Who?

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

На одном проекте я столкнулся с интересной, как мне показалось, проблемой, связанной с пользовательскими полномочиями. Суть этой проблемы заключалась в следующем: пользователям, работающим в back-end системе, присвоен определенный набор полномочий, в котором настроено разграничение доступа по разделам персонала с помощью объекта полномочий P_ORGIN. Спустя какое-то время в этой же компании началось внедрение сервисов самообслуживания сотрудников/руководителей. Когда подошло время тестирования, «нарисовалась» следующая картина: пользователи, которые ранее работали в back-end системе, теперь являлись и, так называемыми, «портальными» пользователями. То есть вход под одним «логином» осуществляется как в портал, так и в back-end. В общем и целом — это совершенно нормальная ситуация. В пользовательские роли добавили объекты полномочий, которые позволяли им работать с портальными сервисами, при этом не изменяли значения объекта P_ORGIN. И вот руки дошли до тестирования приложения Who's Who. После первого запуска выяснилось, что пользователям не хватает полномочий на просмотр данных по сотрудникам, отображающимся с помощью данного сервиса.

Прежде чем продолжить, добавлю несколько деталей, относящихся к данному сервису. Сервис Who's Who, или Поиск сотрудников построен на базе инфо-набора /SAPQUERY/HR_XX_PA_ESS, который, в свою очередь, использует логическую базу данных PNP

При запуске запроса, сформированного на базе данного инфо-набора, отрабатывает стандартная проверка полномочий (исходя из обрабатываемых в запросе данных).

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

Второй вариант, который был рассмотрен — расширение полномочий пользователей, требуемых для запуска данного сервиса. Но этот вариант также пришлось отклонить, потому что это привело бы к катастрофической, с точки зрения разграничения полномочий, ситуации. Логика работы сервиса Поиск сотрудников заключается в том, чтобы любой сотрудник компании мог посмотреть информацию по всем работающим в компании людям. Повторюсь, именно по всем работающим людям в компании, независимо от того, к какому разделу персонала принадлежит сотрудник, который запрашивает искомую информацию, и тот(те) сотрудник(и), который(е) отображается(ются) по результатам поиска. Таким образом, чтобы второй вариант заработал, пользователям необходимо добавить в роль P_ORGIN со «звездами» для значения раздела персонала (PERSA). Как вы уже понимаете, если такое допустить, то сервис Who's Who, конечно же, отработает на отлично, в то время, как в back-end системе, пользователю станут доступны данные по персоналу (включая зарплатные данные, при условии, что инфо-тип 0008 включен в его роль), абсолютно по всей компании. В данной ситуации не нужно «знать высшую математику», чтобы представить последствия. Логично предположить, что этот вариант был также отклонен.

Третий вариант был найден довольно быстро. Объект полномочий P_ABAP. С помощью данного объекта можно отключить проверку полномочий на определенные отчеты (программы). Опять отлучусь в технические дебри.

Как я уже писал выше, сервис поиска сотрудников работает на основе инфо-набора /SAPQUERY/HR_XX_PA_ESS. Настройка же инфо-набора находится по следующему пути в SPRO:

IMG: Менеджмент персонала -> Employee Self-Service (Java) -> Настройки, специфичные для услуг -> Адресная книга -> Поиск сотрудников -> Каталог сотрудников (ESS): выбор и вывод

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

• Закладка «Поля выбора» отвечает за настройку, так называемого селекционного экрана сервиса Who's Who

• Заклада «Поля вывода - подробно» отвечает за настройку полей, используемых для расширенного поиска сервиса Who's Who

• Закладка «Поля вывода - список» отвечает за настройку полей, отображаемых по результатам поиска

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

При выборе данных опций, для всех трех областей будут применены стандартные настройки отображения полей инфо-набора (при необходимости можно активировать, например, только одну опцию).

Если инфо-набор расширяется доп. полями, и эти поля включаются в группу, например, Полей выбора, в системе автоматически генерируется два вида запросов, идентификаторы которых сохраняются в таблице T777WWW_WHO

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

• Workspace = G
• Usergroup = SYSTGENERATE
• Query = SY00000000_nnnn_ , где nnn — номер запроса, автоматически сформированный в таблице T77WWW_WHO, после добавления Z* полей в инфо-набор.
  Имя отчета, сформированное во внутренней таблице REPORTNAME, как раз и является тем самым отчетом, для которого необходимо отключить проверку полномочий с использованием объекта P_ABAP

Возвращаюсь к третьему варианту решения «головоломки» с полномочиями. Объект полномочий P_ABAP был добавлен в пользовательские роли со следующими значениями:

Значения для объекта P_ORGIN изменять не пришлось. То есть в back-end системе у пользователя остался такой же доступ к данным, как и был (на определенные разделы персонала). Но только при работе с сервисом Поиск сотрудников проверка полномочий отключалась, что дало пользователю возможность просматривать контактные данные по всем работникам компании, независимо от раздела персонала.

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

Have fun!