Installing and executing ABAP source code via RFC
User Information System SUIM
Make sure that the client-independent tables for logging are always logged when the parameters are not set to OFF. In addition to the parameters listed here, the table itself must also have the table logging hook set; This is usually done with the help of the transaction SE13. The settings are made in development and then transported to the other systems. The SAP standard already provides some tables for logging; For an overview of these tables, see SAP Note 112388 (tables requiring logging). You can evaluate the logging settings of the tables using the RDDPRCHK report or the RDDPRCHK_AUDIT transaction in the SAP system. The selection is made in the start image of the report, e.g. via the table name or the selection of options for logging.
Since developer authorizations correspond to full authorization, they should only be assigned restrictively. This applies above all to the authorization for "debugging with replace" (see "Law-critical authorizations"). The risk of incorrectly assigned developer authorizations has also increased due to the elimination of additional protection via developer and object keys in S/4 HANA systems (see, among other things, SAP Note 2309060). Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications. If developer keys are still relevant in the existing SAP release, the existing developer keys in table DEVACCESS should first be checked and compared with the users intended for development.
Evaluation of the authorization check SU53
Now maintain the permissions and organisation levels. If possible, use organisational level values in the note, which you can find well in other numbers later on, i.e. about 9999 or 1234. After generating and saving the role, you will be returned to eCATT. There you will be asked if you want to accept the data and confirm with Yes. You have now successfully recorded the blueprint. Now the slightly trickier part follows: The identification of the values to be changed at mass execution. In the editor of your test configuration, the record you created is located at the bottom of the text box. We can now execute the test script en masse with any input. We need a test configuration for this. In the example Z_ROLLOUT_STAMMDATEN, enter a corresponding name and click the Create Object button. On the Attribute tab, specify a general description and component. On the Configuration tab, select the test script you created earlier in the corresponding field. Then click the Variants tab. The variants are the input in our script. Since we do not know the format in which eCATT needs the input values, it is helpful to download it first. To do this, select External Variants/Path and click Download Variants. A text file is now created under the appropriate path, containing the desired format with the input parameters. Open the data with Microsoft Excel and set your target value list. To do so, delete the line *ECATTDEFAULT. In the VARIANT column, you can simply use a sequential numbering. Save the file in text format, not in any Excel format.
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
If you want to know more about SAP authorizations, visit the website "www.sap-corner.de".
Here you can check whether there are parameter or variant transactions for a given table, or for a particular view, for which you can set up permissions, instead of allowing access to the table through generic table access tools.