Monthly reporting / reviews
RETURN MODIFICATIONS TO SAP STANDARD
Another way to secure your gateway using the SAP standard is to encrypt communication using Secure Network Communication (SNC). In the case of unprotected data communication paths between different client and server components of the SAP system that use the SAP protocol RFC or DIAG, the data exchange takes place in plain text and there is a risk that this can be read. With the help of SNC, you can create end-to-end encryption (E2EE), which can be used to secure communication between two components, such as between the application server and SAP GUI. In addition, SNC encryption provides the basis for using SAP Single Sign-On (SSO) as a security solution, which significantly reduces the internal effort of password management.
With SAP Basis, SAP delivers the foundation of its software. Based on this foundation, SAP applications can be used independently of the operating system and database, interact with each other and be enriched with data. Based on a client/server architecture, SAP Basis includes configuration, a relational database management system, and a graphical user interface.
SAP BRFplus
SAP's client concept enables a SAP system to be split into several logical sub-systems - clients. These subsystems can be used independently and in isolation as separate systems. But how should non-client transactions be treated? How can you prevent one client from accessing the other and why should you want to prevent that? In this blog post, I will answer these questions and discuss some negative examples. Why is it important to consider independent transactions separately? Imagine that every one of your employees is allowed to create or change a client in the production system, or worse, both. Creating and modifying a client in the production system is authorised and documented - you wonder what could possibly go wrong? The risk in this case is a loss of integrity of system and data, loss of confidentiality: With each new client, Superuser SAP* lives up to its comprehensive, cross-client rights and the assigned standard password.
Using profile parameters, we can configure everything in the SAP system. Some parameters are dynamically modifiable, which means that they can be changed without restarting the system. However, these changes are not permanent, i.e. after a system restart, the pre-set profile parameters are used again. Other parameters, however, are static, i.e. only with a restart and only permanently modifiable. Most profile parameters for memory allocation are actually static. However, there is the possibility to adapt it dynamically with the report RSMEMORY. Read how to find out if a parameter is static or dynamic and how to use the RSMEMORY report to dynamically adjust the memory allocation parameters. RZ11 - Maintenance of profile parameters The transaction RZ10 gives us information about profiles, which in turn contain different profile parameters. In the transaction RZ11, however, it is possible to view information about individual parameters, provided that you know their name. As you can read in our Memory Parameter Post, the following 5 parameters are particularly important for memory management: abap/heap_area_total abap/heap_area_dia abap/heap_area_nondia ztta/roll_extension_dia ztta/roll_extension_nondia If you don't know exactly what a parameter might be called, it's worth using the F4 help here. For example, for the parameter abab/heap_area_dia, the RZ11 outputs: Description of the parameter abap/heap_area_dia in the RZ11 As you can see here, it is not a dynamic parameter. Now it is rather sorry if you want to test whether there is enough memory available to restart the system again and again. For this purpose, there is the RSMEMORY report. RSMEMORY - Test your memory allocation strategy Report RSMEMORY Report View No documentation or value help available here, but SAP documentation tells you how to use the report. This first distinguishes between dialogue and non-dialogue work processes. That is, in the first area you can set Extended Memory (Storage Class 1) and Heap Memory (Storage Class 2) for Dialogue Workprocesses, and in the second area you can set it for non-dialogue workprocesses.
For administrators, a useful product - "Shortcut for SAP Systems" - is available in the SAP basis area.
If you look at everything I've described up front in its entirety, it quickly becomes clear which direction things are headed: the SAP basis will increasingly move toward an SRE-centric environment over the next decade.
Both parameters are limited by the parameter abap/heap_area_total.