Maintain authorization objects more easily
Query the Data from an HCM Personnel Root Record
Permissions must be maintained in every SAP system - a task that becomes more difficult the more complex the system landscapes and the greater the number of users. Especially in growing system landscapes, once defined concepts no longer fit the current requirements or the processes in role and authorisation management become more and more complex and cumbersome over time.
Without generic table logging, certain changes in the system are not traceable. Learn how to turn on table logging in the system for a large set of tables. The SAP system writes change documents for most changes - but not all. Specifically, changes to tables in which the customising is performed are not recorded in the modification documents. This may lead to a lack of comprehensibility of changes. Avoid this by basically enabling table logging and then setting logging for specific additional tables. You should always enable table logging for all clients. However, during a release upgrade it may be necessary to temporarily disable table logging.
Criticality
After you have determined the data for the website, you must now generate the initial password and send it by e-mail and unlock the user if necessary. There are also different solutions - we describe a possible course of action. You can generate a password using the GENERATE_PWD import parameter of the BAPI BAPI_USER_CHANGE. The generated password is then set as the initial password and must be changed at the next login by the user. You must also set the PASSWORDX import parameter to display a password change. The generated password is returned using the export parameter GENERATED_PASSWORD. This is required if you want to call the BAPI BAPI_USER_CHANGE from a central system (e.g. from the ZBV) and send the relevant e-mail from that system. You should never save this password, but include it directly in your application in an email. Subsequently, you send this e-mail to the user whose e-mail address you can determine either directly in the SAP system (parameter ADDSMTP of BAPI_USER_GET_DETAIL) or within the scope of your web application (e.g. from the AD). Even if you find the email address in the AD, we advise you not to send the email from there. To avoid the password being unnecessarily transferred, it is better to initiate the despatch within your central SAPS system. In addition, we strongly advise you to send the emails encrypted with the initial passwords. To do this, the implementation of your self-service must set the encryption flag when creating the email. We describe details about the encryption of emails and an alternative sending of the initial password directly from the affected SAP system in Tip 98, "Encrypt emails".
The next step is to evaluate the usage data; here the monthly aggregates are typically sufficient. These include the user ID, function block, and number of calls. For an overview of the usage data already stored in the system, see the SWNC_COLLECTOR_GET_DIRECTORY function block (GET_DIR_FROM_CLUSTER = X input parameter). The actual downloading of the usage data is then performed using the function block SWNC_COLLECTOR_GET_AGGREGATES.
Authorizations can also be assigned via "Shortcut for SAP systems".
The password of the user can be set and synchronised via the transaction SWU3.
In all of these cases, you must standardise or translate the texts of the authorisation roles.