SUIM User information system
SCI Code Inspector
Migrations occur, for example, when a customer decides to host his systems at Rödl & Partner and the SAP systems therefore have to be migrated from in-house operation or from the original hosting provider to our data center. Also in the course of a conversion to S/4HANA, the data is migrated from the original database type to an SAP HANA database. This is also done with the tool "SUM" (Software Update Manager) via the so-called "DMO" (Database Migration Option).
Parameters in the SAP create a high degree of flexibility. Profiles can be used to configure the system for almost any purpose. But with such a large number of parameters one quickly loses an overview of the influence of each parameter. For storage management alone, there are 20 different parameters that can be changed at different points in the SAP system. This article brings order to the mess and explains the most important parameters. There are three types of memory in the SAP system for a work process: ・ Roll Area - Local Memory Area for a Work Process ・ Extended Memory - Global Memory Area for All Work Processes ・ Private Storage /Dynamic Memory (Private Memory/Heap Memory) - Private Memory Overview of SAP System Memory Regions Parameters for the Rolling Range When a user starts a programme, a role area is created for that programme instance through a workprocess. The user context is stored in this memory area. The size of the roll area for a work process is determined by the ztta/roll_first parameter. If the storage area is not sufficient, a portion of the Advanced Memory will be allocated for the user context, the size of which will be determined by ztta/roll_extension, ztta/roll_extension_dia, and ztta/roll_extension_nondia. The latter two override ztta/roll_extension if used and offer the possibility to set different quotas for dialogue and non-dialogue work processes.
Update & Upgrade
Every SAP system develops over many years. It grows and changes with the company. The more functions are mapped in it and the more data is stored, the greater the importance of and dependence on this central ERP system. There is no such thing as a standard SAP Basis solution. It is developed individually with reference to the company.
This makes the technical user the dialogue user and a login in the SAP system is unrestricted. So Johannes logs in with the known password of the RFC user in the production system. Thanks to very extensive permissions, it now has access to all sorts of critical tables, transactions, and programmes in production. With the identity of the RFC user Johannes starts with the technical compromise of the production system... RFC Security: All invented - or everyday threat? Whether a simple trim, altered biometric properties or an encapsulated technical user in the SAP system: the basis of the compromise is the same. A person uses a different identity to gain access and permissions to protected areas. Moreover, the evil in all three stories could have been prevented by pro-activity. When was the last time you thought about the security of your RFC interfaces? Can you say with certainty that all your technical RFC users only have the permissions they actually need? And do you know who exactly knows the passwords of these users? Can you 100% rule out that not now in this moment an SAP user with a false identity infiltrates your production systems? Change now: It's about pro activity! But before you start now and start looking for the "identity converter" (which I really do not recommend!), I suggest that you take root of evil and proactively strengthen your RFC security. So if you want to find out more, I have the following 3 tips for you: 1) Our e-book about SAP RFC interfaces 2) Clean up our free webinar about RFC interfaces 3) Blog post about our approach to optimising RFC interfaces As always, I look forward to your feedback and comments directly below these lines!
Tools such as "Shortcut for SAP Systems" are extremely useful in basic administration.
This data can consist of data tables, applications or system control tables.
Before SAP HANA was released, there was no SAP database - you had to install SAP ERP (or the application you were using) on a third-party database, such as Oracle or SQL Server.