SAP Basis Technical and non-technical skills - SAP Corner

Direkt zum Seiteninhalt
Technical and non-technical skills
Performance optimization
It should be mentioned here that it only makes sense to access the tables by reading the SELECT statement to get a quick view of the results. Using the DBACOCKPIT, it is not possible to create entire table structures using Create Table. For such applications, SAP provides other, better options. Another important point is that once a user has the necessary permissions to use the transaction DBACOCKPIT, it can potentially (with appropriate permissions on the tables) access the entire SAP system. For example, a query can be used to read the entire user table. Therefore, the transaction should always be treated with caution and only awarded to administrators. DBACOCKPIT handles the call control permissions similar to the SE16 / SE16N transaction. When the table is called, the S_TABU_DIS or S_TABU_NAM permission object is checked with a specific activity. This means that only the tables or table permission groups for which the corresponding values in the aforementioned permission objects are assigned can be accessed. You can read more about assigning permissions to individual tables here. In addition, you can save SQL statements that you run once, and run them again at any time to recognise changes in the result set without having to reformulate the SQL statement each time. The editor also allows you to start the query for SQL statements in the background. The result is obtained by calling the transaction SM37, in which the result is output in a spool file.

Many companies are struggling with the introduction and use of secinfo and reginfo files to secure SAP RFC gateways. We have developed a generator that supports the creation of the files. This blog post lists two SAP best practices for creating the secinfo and reginfo files to enhance the security of your SAP gateway and how the generator helps you do this. secinfo and reginfo Request generator Option 1: Restrictive procedure In the case of the restrictive solution approach, only in-system programmes are allowed. Therefore, external programmes cannot be used. However, since this is desired, the access control lists must be gradually expanded to include each programme required. Although this procedure is very restrictive, which speaks for safety, it has the very great disadvantage that, in the creation phase, links which are actually desired are always blocked. In addition, the permanent manual activation of individual connections represents a continuous effort. For large system landscapes, this procedure is very complex. Option 2: Logging-based approach An alternative to the restrictive procedure is the logging-based approach. To do this, all connections must be allowed first by the secinfo file containing the content USER=* HOST=* TP=* and the reginfo file contains the content TP=*. During the activation of all connections, a recording of all external programme calls and system registrations is made with the gateway logging. The generated log files can then be evaluated and the access control lists created. However, there is also a great deal of work involved here. Especially with large system landscapes, many external programmes are registered and executed, which can result in very large log files. Revising them and creating access control lists can be an unmanageable task. However, this process does not block any intentional connections during the compilation phase, which ensures the system will run non-disruptively.
Fiori Permissions for tile groups in PFCG
But when it comes to the intricacies of large SAP environments, Ansible quickly reaches its limits. If you want to use Ansible to implement simple automations - for example, starting and stopping SAP environments - you have to put up with a lot of manual effort and complicated scripts.

In the following dialogue, select a TADIR service and the programme ID "R3TR" and the object type "IWSG". Now you can select the OData service stored on the front-end gateway. Then switch to the Permissions tab to generate the current profile of the permission objects with the new Fiori permission. Once you have performed these steps, the treated role has the necessary permissions on the front-end side. Fiori Permission to call the OData service on the backend server Now go to the role maintenance in the PFCG on the backend server. Open the appropriate role in Change Mode. Now you can repeat the steps for the frontend as explained above. However, when selecting the TADIR service as the permission proposal, you now select the object type "IWSV". Here you can select the OData service of the specific Fiori application stored in the backend.

Some missing SAP basic functions in the standard are supplied by the PC application "Shortcut for SAP Systems".

They have the opportunity to clarify individual issues and to determine the focus of the security check.

Some useful tips about SAP basis can be found on www.sap-corner.de.


A user can then read all data assigned to him (via role or his own settings) at once.
SAP Corner
Zurück zum Seiteninhalt