The aim of the process described below is the creation of a role. Roles are a description of the activities for a work center and consist of one or more applications (transactions, Web Dynpro applications, and so on). The fundamental elements of the role are the menu and the associated authorizations.
The role's menu is created by an administrator and contains all applications that the user requires for his or her activities. The role menu is an element of the user menu that is displayed for the use rin SAP GUI, for example, in the SAP Easy Access menu or in the SAP NetWeaver Business Client.
Authorizations of the Role
The administrator assigns corresponding authorizations for the applications contained in the role menu. To do this, the adminsitrator needs to answer the question of which authorizations are required for a particular application and must therefore be included in the role. SAP developers deliver this knowledge with the program. It defines which authorization objects are required in an application. It defines default data and specifies the authorization objects for which the user requires an authorization to execute this application. Developers maintain this default data for each application in transaction SU22, and delivers it.
The Profile Generator combines the default data defined by developers for each application in the role menu with the not-yet-fully-specified role authorizations. These authorizations might still contain empty fields.
In SAP development systems (profile parameter transport/systemtype='SAP'), the Profile Generator copies the authorization default data from the SU22 tables. In customer systems (profile parameter transport/systemtype='CUSTOMER'), the customers copy the data delivered by SAP developers into the customer-specific tables (SU24 data). Customers can adjust the delivered default data to their requirements in these tables. In customer systems, the authorizations for the role are based on the default data in the customer tables (SU24 data).
The process below describes the steps with which SAP determines the authorizations and default values and delivers them, and how you can change and assign them.
1. Steps for SAP Developmers
SAP developers use, for example, ABAP Workbench to implement an application with authorization checks programmed in.
Developers fully test this application.
Developers define, in transaction SU22, which authorization objects are required for their application. The authorization trace supports them by permanently logging authorization checks that occur in an application in development and test systems. More information: Maintaining Authorization Fields Using Trace Evaluation in Transaction SU22.
Transaction SU22 displays a list of authorization objects that the trace has logged for the selected application. Developers need to classify these objects by assigning the authorization default status.
By setting this authorization default status, developmers inform administrators that a user does not rqeuire an authorization for this object to execute the core functionality of this application. Do not confuse this with the check indicator for transactions with which the check is deactivated. For more information about check indicators, refer to Editing Check Indicators for Objects in Editing Authorization Default Data (Development System).
If the administrator adds the application to a role, the Proifile Generator does not place an authorization for this object in the role.
By setting this default status, developers inform administrators that the user requires an authorization for this object in order to execute the core functionality of the application. If the administrator adds the application to a role, the Proifile Generator adds an authorization for this object in the role. The consequence is that the Profile Generator includes an authorization for this authorization object in the role authorizations using the delivered authorization default values.
The fields of the authorizations are predefined with the proposed values. If you do not specify any values, you can specify Yes, Without Values. Deliver default values for the fields of the authorization object for which you know which values will be checked in customers' systems. Leave fields with customer-specific content empty.
Yes, Without Values
By setting this default status, developers inform administrators that the user requires an authorization for this object in order to execute the core functionality of the application. However, the developers cannot specify any values, since these are only determined in the customer system.
If the administrator adds the application to a role, the Proifile Generator places an empty authorization for this object in the role.
More information: Editing Authorization Default Data.
Developers can deliver an SAP example role. An SAP example role is used to map a function or activity description. That is, the menu contains the applications (transactions, Web Dynpro applications, and so on) that are required for this activity. The Profile Generator then generates authorization for this role from the SU22 default data. Developers maintain open fields - as far as possible and necessary for this function. Developers leave fields empty that can only be maintained by the customer.
2. Steps for Authorization Administrators in the Customer System
The customer's authorization administrators use transaction SU25 to transfer the authorization data from the SAP tables (SU22 data) to the customer tables (SU24 data).
For more information, refer to point 3 in Procedure Before First Installation.
The authorization administrators edit the SAP authorization data in the customer tables to adjust or extend them in accordance with the customer's needs.
The authorization administrator creates a role. He or she has the following options when doing so:
He or she can copy a delivered SAP role (example role) into the customer namespace and then perform the merge process to transfer the updated customer-specific SU24 data.
He or she can create a new role from the delivered authorization data based on the SU24 data. To do this, he or she includes applications in the role menu and completely specifies the authorizations of the role by completely filling the fields of the authorization objects.
The role allows the end users access to the system objects required for their activities. The authorization administrator completely specifies all fields of the role so that there are no longer any empty fields.
The authorization administrator assigns the role to the user.
3. Steps for the User
The user can execute all of the applications in his or her role menu.