ABAP Platform – Part 3 – what’s new for the basis administrators
This is the third part of the 4 blog posts regarding what is new on the ABAP Platform:
- ABAP Platform – Part 1 – Evolution from SAP Netweaver
- ABAP Platform – Part 2 – New programming models
- ABAP Platform – Part 3 – What’s new for the system administrators
- ABAP Platform – Part 4 – what’s new in ABAP Platform 2020 (New – Update 23.11.2020)
In the previous blog posts, I have been talking about the evolution of the SAP Netweaver platform towards the ABAP platform and how the ABAP programming language has been updated and modernized with the introduction of new programming models.
Now, in the Part 3 of my blog series, I would like to focus on the basis area and describe some of (in my opinion) most interesting features introduced by ABAP Platform for the basis administrators.
As I mentioned before, ABAP platform replaces SAP Netweaver as the technology stack for S/4HANA and also breaks the backward compatibility with previous SAP Netweaver versions.
After many years, it was time to clean obsolete functionality that is not used anymore and to adopt new technologies and a new programming model necessary to build and run SAP software on the cloud. These innovations required profound technology changes in the technology stack, changes that were not possible if you need to maintain combability with the old SAP Netweaver stack.
So let’s see what are the main changes…
No support for legacy operating systems
I was a huge fan of the Solaris operating system, I still have some Sun Microsystems servers at home as part of my personal collection, and I have been using HP-UX for a long time… but in 2020, in the era of the hyperscalers, these operating systems cannot compete with Linux and Windows.
Starting with kernel 773 (ABAP Platform 1809 + HANA 2.0), support for some Operating Systems have been removed as per note “ 2620910 – SAP S/4HANA 1511, 1610, 1709, 1809 and SAP BW/4HANA 1.0, 2.0: Recommended and released Application Server Platforms”
The following table summarizes the main changes between Netweaver and ABAP Platform:
Based on the customer´s feedback we see most customers choosing Linux x86_64 as their preferred platform to run SAP systems, although Windows and AIX are still supported and are perfectly valid options.
Cleaning of obsolete SAP Profile parameters
If you have been working as SAP basis administrator for some time, you probably know that SAP introduce, change or remove profile parameters continuously. As the same SAP Kernel is used by a variety of SAP products and versions, these frequent changes in the parameters had to be as compatible as possible to avoid undesired collateral effects.
But SAP ABAP Platform 1809/Kernel 7.7x it’s different, it breaks the downwards compatibility with old kernels and SAP Netweaver versions. It’s the perfect opportunity for SAP to clean all these historical and obsoleted parameters that has been around for many years.
There are 2 main areas that has been cleaned and/or optimized:
- ABAP VMC
- ICM and SAP Web Dispatcher
The Virtual Machine Container (in short VM Container or VMC) was a component integrated into the SAP Web AS ABAP that enabled Java functions that complied with the Java Standard J2SE 1.4 to be executed in AS ABAP.
As per note SAP Note 2560708, Kernel for S/4 HANA does not support VMC since 1809. Therefore, there are a lot of VMC and JVM parameters that are not supported anymore and must be manually deleted from the SAP instance profiles.
There are also important changes in the ICM and SAP Web Dispatcher parameters, many depreciated and obsolete parameters have been removed too. You can find all the details in the SAP Note 2593926 – Incompatible ICM / SAP Web Dispatcher Parameter Changes in 773 – Deprecated, Obsolete and Changed Parameters.
The goal again, has been to remove obsolete parameters and simplify the administration of the ICM / Web Dispatcher components, which now with FIORI are critical components of the SAP systems.
New maintenance model and runlevels
This is, in my opinion, an interesting feature introduced for SAP S/4HANA Cloud but also available in SAP S/4HANA “Any-premise” versions as these SAP S/4HANA product share the same code.
There are 2 new concepts: runlevels and maintenance periods.
Transaction SMAINTENANCE allows you to define a maintenance period:
- Normal users will not be able to login, only system administrators with a special security profile will be able to connect (Transaction SECPOL)
- Only admin batch jobs will be executed (all other jobs will be on hold)
There are different runlevels, from runlevel 0 (system running in normal operation) up to runlevel 100 (System in maintenance) that allow a more flexible way to define what is the status of the SAP System and which actions are allowed or not depending the runlevel:
As you could imagine, this is a must-have feature for cloud products, as the maintenance of the systems must be as transparent as possible for the end users but it’s also very useful for on-premise administrators that want to simplify and automate their regular maintenance tasks.
When the maintenance mode is activated on the SAP S/4HANA on-premise systems, only the SAP system administrators (with the right security profile) will be able to connect:
New client copy tools
After many years without important changes, finally there is a new version of the tools to create, delete and manage the SAP clients.
The main changes can be summarized as:
- Up to 10 times faster as the tools use SAP HANA optimizations.
- Remote client copies up to 5 times faster
- No need for user SAP*for client copies, no system restart needed
- Runs in isolated environments, failed exits and tables stored in the log
- Table-based UI with additional information and better persistence; multiple tabs for different sections of the log
The following table, extracted from the official SAP help describe the new transactions and tasks lists available in ABAP Platform:
As an example, now you can estimate the size of one SAP client and get a detailed overview of which tables consume more space using the new SCC_CLIENT_SIZE transaction that replaces the old reports:
Memory quotas and soft dumps for Memory Consumption
When a process consumes all his memory quota (Extended Memory + HEAP memory) an ABAP Short Dump is generated (e.g. TSV__NEW_PAGE_ALLOC_FAILED) and the process is cancelled as a protection mechanism to avoid a complete system crash.
Up to now, it was impossible to get an “early warning” when a process was consuming too much memory. The only option available was a proactive monitoring, checking which processes were consuming more memory and trying to react before it was too late.
Starting with kernel 7.77, when a process consumes more than a user defined percentage of his memory quota is possible to generate a soft dump:
- The ABAP processor writes a “coreinfo” file
- Periodically there is a process that reads these coreinfo and save the dump info in ST22.
- Dump SESSIONMEM_QUOTA_WARNING info is visible in ST22
The main difference between the classic ABAP short dump and the new soft dump it’s that the process is not cancelled but systems administrator can react to the warning and decide what is the right action:
As you can see in the previous example, although the memory quota was ~6GB the session memory warning was configured at 3.6GB
Another interesting feature that I am sure will be very useful for systems administrators is the option to allow a more flexible configuration of the memory quotas.
The default memory quota applies to all users, by default nobody can consume more memory. However, with the quota extensions we can grant specific users (must be registered in transaction SMEM_USEREX) a different quota, allowing them to consume MORE or LESS)
Quota extensions and quota warning can be controlled with the following parameters:
Systems administrators must register users via transaction SMEM_USEREX in order to be allow them to use the new quota exemption mechanism:
ABAP Push channels and WebSockets
Another significant improvement belongs to the ABAP connectivity area and is the internet-enabling of RFC. The new WebSocket RFC allows RFC calls over HTTP/WebSocket and is always transferred via SSL to ensure security. VPN tunneling is no longer required for RFC connections across business networks.
WebSocket RFC uses standard HTTP infrastructure, reverse proxies, HTTP routers etc. instead of proprietary SAP router.
Most ABAP applications use polling techniques to achieve an event-driven communication. For pushing an event from an ABAP backend to a browser-based user agent like SAPUI5, Web Dynpro, Business Server Pages (BSP) or WebGUI, a polling in multi-seconds interval is frequently used. This is a quite system resource consuming technique. In SAPGUI usually the timer control is used to detect an event in the ABAP backend system. ABAP Channels technology targets to replace such inefficient eventing based on polling techniques through push notifications based on publish-subscribe infrastructure and WebSockets in ABAP.
ABAP Channels infrastructure was delivered with SAP NetWeaver AS ABAP 7.40 support package 2 (SP2) for simple tests and prototyping and released with 7.40 support package 5 (SP5).
The basic idea of the ABAP Channels (see Figure 1) is the native support of interactive and collaborative scenarios based on event-driven architecture. The scope of ABAP Channels consists of the following communication channels:
With WebSocket RFC, RFC are finally compatible with modern cloud and internet architectures:
- Use standard HTTP infrastructure: Reverse proxies, HTTP routers, etc… no more SAPRouter.
- VPN tunneling is no longer needed for RFC connection across business networks
- Support for standard HTTP authentication mechanisms, like SAML bearer tokens, Oauth,etc…
- Compatible with classic RFC (use the same ABAP statement CALL FUNCTION)
- RFC callbacks and call function modules that open SAP GUI-based user interfaces.
User Management – Technical Users vs Business Users
Up to now, “technical users” (e.g. system administrators, users for interfaces and batch jobs, etc…) and “business users” (people that executed the business processes inside SAP) were defined exactly in the same way, via transaction SU01 and their main difference were the SAP authorizations and login details.
Starting with SAP S/4HANA 1909, there is a new identity model for business users.
A business user is a natural person who is represented by a business partner and a link to a user in the system. This business user will interact with the software in the context of a business process (purchaser, a sales representative, etc…)
So now, in transaction SU01, there is a clear distinction between Technical users and Business Users:
- Technical users: Don’t have a BP associated, and don’t have “Address” TAB in the SU01.
- Business Users: the user id is linked with the corresponding BP and some details cannot be changed via SU01
For the business users, some business user data is integrated in the BP and can no longer be edited in SU01:
- personal data is derived from the corresponding business partner
- work center data is derived from the workplace address of the corresponding business partner
- communication data in SU01 is derived from the workplace address of the corresponding business partner
- ORGANIZATION_NAME and LOCATION in SU01 is derived from the company address of the corresponding BP
Call to Action!
If you have installed a new SAP S/4HANA 1909 or you already converted your SAP system, I really encourage you to have a look in detail to these new features. We really believe that these changes will help you to operate SAP more efficiently and will simplify your regular maintenance tasks.
We want to hear your comments and your feedback so we will be glad to read your comments and learn from your experiences.