Сигрид Хагеман - SAP R/3 Системное администрирование

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

Рис. 8.4. Двухэтапная проверка полномочий

В идеале администратор должен только выбрать одну из предопределенных ролей и присвоить ее пользователю. Затем во время сравнения пользователей (см. раздел 8.3.8) полномочия будут записаны в соответствующие контексты пользователя как профили.

Каждое полномочие в системе R/3 основано на так называемом объекте полномочий. С технической точки зрения этот объект представляет собой модуль, содержащий имя, поля полномочий и, возможно, значения, которые представляют операции (действия). Присваивание объекта полномочий процессу (например, отчету, транзакции или обновлению) определяется SAP. Технически полномочие является набором значений для определенного объекта полномочий, который предоставляет пользователю разрешение выполнять действие в системе SAP. Система полномочий SAP работает только с полномочиями; не существует определенных запрещений деятельности. Конечно, это означает также, что все действия, которые явно' не разрешены полномочиями, будут запрещены.

Классы объектов

Число объектов авторизации в системе R/3 весьма значительно, что связано с диапазоном функций R/3. Чтобы лучше различать их, объекты разделяются на классы объектов. Чтобы просмотреть все доступные в системе SAP объекты полномочий можно использовать ► Object Classes. Например, MM_E — класс объектов Materials Management-Purchasing (управление материалами-закупками). Выбрав эту область, можно получить все доступные для нее объекты полномочий. Небольшой текст дает описание объекта полномочий. Например, выберите M_BEST_EKG для заказа детали. Такой объект полномочий включает в себя поле полномочий ACTVT, содержащееся в каждом объекте полномочий по умолчанию, и специальное поле EKGRP (см. рис. 8.5). Назначение данных полей и значений, которые они могут содержать, описываются в документации по R/3.

Рис. 8.5. Объект полномочий M_BEST_EKG

В данном примере в поле EKGRP можно задать имя или диапазон имен определенных групп закупки. Щелкните на кнопке Permitted activities,чтобы определить все возможные значения для деятельности.

Таблица 8.3. Возможные значения в поле ACTVT и их описания

Большинство полномочий уже определены с помощью значения «*», поэтому нужно ввести для компании только необходимые специфические значения. Можно использовать ►Role Maintenance • Environment • Auth.Objectsдля вывода всех существующих полномочий для объекта полномочий, изменения существующих полномочий или добавления новых.

Если принять во внимание сложность системы R/3, станет очевидно, что, хотя можно определить и присвоить все необходимые полномочия каждому отдельному пользователю, требуемые громадные усилия не оправдывают такой подход. Это является причиной того, почему полномочия могут группироваться вместе. Для поддержания всех наборов полномочий одновременно можно использовать роли. Более ранние версии Basis используют для этой цели профили полномочий; система R/3 продолжает использовать эти профили полномочий в качестве технического инструмента.

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

Эти профили затем автоматически генерируются во время обслуживания роли, как описано ниже. Это одновременно простейшая и наиболее рекомендуемая процедура. Однако в исключительных случаях, таких как пользовательские разработки, может понадобиться изменить существующие профили вручную или создать новые. Обслуживание профилей вручную возможно в ►User Maintenanceс помощью Environment • Profiles • Maintain profiles(в Basis Release 6.10 и более поздних выводится предупреждающее сообщение, указывающее, что для обслуживания полномочий необходимо использовать роли).

Профили в R/3 могут иметь разные состояния:

► Активный/неактивный

► Обслуженный (т. е. адаптированный к текущим условиям) или оставленный без изменений (стандартный)

Если система стандартная (немодифицированная), то все ее профили еще не обслужены. Создаваемые новые профили должны активизироваться (т. е. о них должна знать вся система — лишь после этого они будут ей доступны в системе).

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

Составные профили

Можно также создать новые профили путем слияния определенных заказчиком или стандартных полномочий или профилей полномочий. Эти профили называют составными профилями. Чтобы вручную присвоить полученные профили пользователю, используйте при создании пользователя вкладку Profiles.На рис. 8.6 показаны профили, присвоенные пользователю SAP*. Ему присвоен профиль SAP_ALL, охватывающий все возможные операции в системе R/3.

Рис. 8.6. Профиль полномочий пользователя SAP*

Рис. 8.7. Иерархическая организация полномочий и профилей

Поля полномочий

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