Recertification made easy with EasyReCert
SM02 Create system message
You would like to know more about what is happening on your SAP systems - then I recommend that you take a closer look at the Solution Manager Usage Procedure Logging (UPL) functionality. What code is often executed? Which database tables are accessed regularly? What unused developments exist? - The UPL provides answers to these questions. You can implement the functionality into your existing SAP landscape without additional licence costs and with moderate effort. What information does the UPL provide? Usage Procedure Logging is used to log and record user behaviour data roughly comparable to the ST03N workload statistics. UPL is able to record the call and execution of the following ABAP objects: Reports Functional Blocks Classes Methods Subroutines SQL Calls In addition, UPL is able to detect dynamic programme calls and generate transparency about the modifications used. All usage data is recorded in detail and automated and, if desired, made available centrally in the SAP Solution Manager. Benefits 1) Hardly measurable Performance Impact 2) Central collection of data of all systems in the SAP Solution Manager's BW 3) No complex setup 4) Once activated, the collector and extractor jobs run regularly and without further manual activities Possible usage scenario If you have Solution Manager 7.2 in use, you can use UPL within the framework of "Custom Code Lifecycle Management" (in German: management of customer developments). After one activation of the BW content and some standard jobs, you select one or more systems for which you want to activate UPL. If you already have the SP05 installed, there is a separate "Guided Procedure" for configuring the UPL in SOLMAN_SETUP.
If you want to skip the backgrounds and prefer a direct step-by-step guide, you can jump directly into the last section. Preparation For this workaround, you need access to both the source system and the BW system. In addition, they shall have the possibility to access the SE37 and execute functional modules there. Especially in production systems this is a very critical justification. So assume that you may need a Firefighter user for this action. Working in the BW system Now that the preparations have been completed, you have to call a FuBa on the BW system and on the source system, which solves the connection on the respective page. Beginning on the BW system, go into the transaction SE37 and call the function block "RSAR_LOGICAL_SYSTEM_DELETE": RSAR_LOGICAL_SYSTEM_DELETE Enter the required values here. The following table helps you fill in: Field Description I_LOGSYS The logical name of the source system. The name of the source system, as found in RSA1, will be entered here. In addition, this name can also be found in the DB table TBDLT. I_FORCE_DELETE Boolean, X = Delete despite error messages I_NO_TRANSPORT Boolean, X = This change should not be transported to subsequent systems I_NO_AUTHORITY Boolean, X = Ignore Permission Checks Work in the source system In the source system, go to transaction SE37 and call the function block "RSAP_BIW_DISCONNECT" : The descriptions of the fields are as follows. These can be found in the RSBASIDOC source system connection table Field Description I_BIW_LOGSYS The logical name of the BW system. In the RSBASIDOC table, find the correct value in the column "RLOGSYS". I_OLTP_LOGSYS The logical name of the source system. The column ‘SLOGSYS’ in the table RSBASIDOC. I_FORCE_DELETE The logical name of the BW system. In the RSBASIDOC table, find the correct value in the column "RLOGSYS". Completion In the end, you have to call the respective function block in the BW and source system, fill in the parameters and execute the function block.
SCCL Client copy - local
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.
A first important step was the introduction of playbooks to professionalize our work. Back then, SAP installation manuals were real tomes with hundreds of pages that often went around in circles and were anything but easy to understand....
"Shortcut for SAP Systems" is a PC application that simplifies or even facilitates many activities in the SAP basis.
In the administration interface, the launchpad can be customised, so this permission should only be released to a few users for administration.
To store all the information on the subject of SAP - and others - in a knowledge database, Scribble Papers is suitable.
Due to the variety of tasks and the high level of complexity, I find my job extremely exciting.