Concept for in-house developments
Testing Permission
When creating the permission concept, a naming convention is defined for PFCG roles. Every customer has his own preferences or specifications, which must be adhered to. According to our project experience, some naming conventions are particularly attractive. Naming conventions for PFCG roles can be very diverse. You will have noticed that even the roles provided by SAP do not correspond to a uniform naming convention. So there are roles whose names start with SAP_. There are also roles, such as for the SRM system, that start with the /SAPSRM/ namespace. In this tip we would like to give you some hints and criteria that you can use to help define a naming convention of PFCG roles.
If you want to set the table logger check for multiple tables, you should note that the principles for changing Dictionary objects apply, i.e. you will generate increased system loads in running systems. Therefore, you should make both the modification and the transport of the changes outside of business hours. The SAP system only provides customising tables for table logging by default; so you don't have to worry about performance. Tables that serve to customise typically contain relatively little data that is rarely changed. However, you should not turn on table logging for tables that are subject to mass changes, as there may be performance and disk space issues. This applies to tables with root or movement data. After all, if table logging is enabled, a log entry in the DBTABLOG table is generated for each change to the contents of a logged table.
Managed Services
If you only want to translate the description of the role, it is recommended to record the PFCG transaction and to change the source language of the role using the Z_ROLE_SET_MASTERLANG report before the LSMW script runs through. The report on how to change the source language can be found in SAP Note 854311. Similarly, you can use the SECATT (Extended Computer Aided Test Tool, eCATT) transaction to perform the translation instead of the LSMW transaction.
In general, you should note that not all relevant change documents of a system are present in the user and permission management. As a rule, authorisation administration takes place in the development system; Therefore, the relevant proof of amendment of the authorisation management is produced in the development systems. By contrast, you will find the relevant user administration change documents in the production systems; Therefore, you should note that when importing roles and profiles in the production systems, no change documents are written. Only transport logs are generated that indicate that changes have been made to the objects. For this reason, the supporting documents of the development systems' authorisation management are relevant for revision and should be secured accordingly.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
If the password is set by the administrator, it will get Initial status and must be set by the user at login again to get Productive status.
You can maintain these authorization objects in the PFCG role, which describes the user's workplace.