SWDD Workflow Builder
This SAP training covers the introduction/basics of SAP administration. You will learn the basic functions of the SAP system. You will learn the most important administrative tasks, such as user administration and roles, the SAP data transport system, security in the SAP environment, administrative background tasks and system monitoring.
The Advanced Memory thus contains mainly user contexts of different work processes, if these cannot be loaded completely into the roll area. Since the storage area is accessible for all work processes, the work processes can also access external user contexts that lie here. In addition, the Advanced Memory contains a global area where data can be stored independently of user contexts. The extended memory size is determined by the values of em/initial_size_MB and em/global_area_MB. The first parameter determines the size of the storage area in which user contexts can be stored, and the second determines the size of the global area. Parameters for Private Storage Last but not least, there is the private storage, which is only used when the user context of a work process has used up all the other storage areas available to it, i.e. its share of the extended memory and its rolling area. In this case, the workprocess goes into PRIV mode. A workprocess in private mode is bound to its current user context and will not become free for other tasks until the current request is completed. If it has used up all the private memory allocated to it, the workprocess will then be restarted and the memory released. This behaviour is controlled with the abap/heaplimit parameter. At times, the user context may exceed the value of abap/heaplimit. The parameters abap/heap_area_total, abap/heap_area_dia and abap/heap_area_nondia define an upper limit for private storage. The abap/heap_area_total parameter defines how much private storage all workprocesses can use in total. The parameters abap/heap_area_dia and abap/heap_area_nondia, on the other hand, determine how much private storage a single (non-)dialogue workprocess can use.
SCI Code Inspector
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.
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.
"Shortcut for SAP Systems" simplifies tasks in the area of the SAP basis and complements missing functions of the standard.
For assistance in building and expanding SAP Basis, SAP Basis consultants can help.
The position of SAP Basis consultant is often combined with the position of SAP Basis administrator.