In Jerry’s previous photo post, I mentioned a blog post on the SAP community:

Proof of Concept: Deploying ABAP in Kubernetes blogs.sap.com/2020/02/06/…

It describes an attempt by SAP Linux Lab engineers to container ABAP application server components and deploy them on Kubernetes.

After reading this blog, I would like to put it into Chinese to share with you, but to see the author in the blog to share this piece of architecture diagram, I think it’s necessary to separate first to use an article review the ABAP Netweaver server part of the preparation of ABAP container was discussed as a knowledge reserve, so there was this article.

This article briefly reviews the main components of the ABAP Netweaver application server. While not knowing this knowledge does not prevent ABAP developers from performing their daily tasks, many ABAP programming best practices are tied to this knowledge and can help you write more robust and efficient ABAP applications.

What is ABAP Netweaver application Server?

SAP Netweaver application server is SAP ABAP application development and operation platform, ABAP developers can focus on the development of specific business logic, where involves the underlying infrastructural-related tasks, such as request load balancing, process derived, synchronization and scheduling, memory management, Server multi – instance cache synchronization and so on, all by the Netweaver platform itself. In this way, an ABAP developer can develop SAP applications without in-depth knowledge of computer composition principles, operating systems, and computer networks.

ABAP Netweaver application server and SAP solution?

The SAP solutions discussed in this article are limited to those SAP products based on the ABAP technology stack.

Google search according to the keyword “SAP ABAP three layer”, you can find many SAP solutions based on ABAP technology three-layer classical architecture diagram:

Click on any open sheet to view:

The SAP client is located at the Presentation Layer on the top of the figure, and accesses the SAP system through the SAP GUI client software or browser.

SAP system software, installed on the ABAP Netweaver server, responds to user requests to complete the corresponding business logic. The ABAP Netweaver server is located in the application layer in the middle of the figure above.

At the bottom is the database layer. Many SAP products support different types of databases, such as SAP HANA, Oracle database, SQL Server, etc.

Some ABAP developers think that since we can directly use OPEN SQL in ABAP Netweaver to read and write database tables, then Netweaver application server itself contains the database layer. This is not correct. The OPEN SQL code we wrote in Netweaver SE38 will be converted into the native SQL statements related to the database provider through the internal database interface of Netweaver and executed in the database, and the data transmission between the lowest database layer and the ABAP program in the application layer. This is also done through the database interface.

The components of the ABAP Netweaver server discussed in this article are located in the application layer of the three-tier architecture.

ABAP Netweaver server instance

ABAP application servers running on physical machines can be divided into two instances according to their purpose: Application Server instances and ABAP SAP Central Services Instances (abbreviated ASCS Instances), which are represented by the two gray rectangles in the figure below.

A typical SAP system consists of one to multiple application server instances and one ASCS instance.

From the rectangular box on the left of the figure above, you can see that the main components of an ABAP application server instance are:

(1) Internet Communication Manager (ICM)

(2) ABAP dispatcher

(3) Work process

(4) RFC Gateway

(5) Start Service

Here is a brief overview of these components.

Internet Communication Manager (ICM)

ICM is a separate process in the Netweaver server, started and monitored by ABAP Dispatcher, responsible for SAP system and external network communication. Based on the resolution of the received request URL, ICM distributes the request to a specific handler for processing.

ICM uses HTTP, HTTPS, and SMTP to communicate with the Internet.

The following is an architecture diagram of ICM.

Thread Control: This Thread is responsible for receiving external requests, fetching idle worker threads from the ICM Thread pool and handing the context of the request to the worker Thread.

Worker thread: Responsible for the specific processing of the request and contains an I/O processor that can be used for network input and output operations. For requests of different protocol types, Thread Control schedules worker threads that contain the corresponding protocol plug-in.

Watchdog: If a worker thread is waiting for a response to time out while processing a task, the Watchdog releases the worker thread from waiting indefinitely so that it can serve other requests. Watchdog continues to wait for responses that have not yet arrived. Then, if the response arrives, the Watchdog notifies Thread Control, which proceeds to call a new worker Thread for processing.

Signal Handler: Processes signals from the operating system or other processes.

Connection Info: This table maintains state information for each Connection, including memory pipes, etc.

Memory Pipes: Memory Pipes are a memory-based communication data structure for transferring data contained in external requests received by ICM to the worker thread.

Internet Server Cache: A server-side Cache that speeds up the response to repeated requests.

ABAP Dispatcher and work processes

The relationship between the two is clear in the following figure, where ABAP application servers run many different types of Work processes that handle different types of requests.

Transaction code SM50 can see the details of the working processes on the current application server. For example, the following figure shows that there are 30 Dialog processes used to process the user’s ordinary transaction requests, of which 29 are idle. The Update process is responsible for performing database updates. The Background process handles the Background jobs, while Spool handles the printing tasks. In ABAP, there are two levels of database Update (V1 and V2), which are performed by the following two types of work processes: Update and Update Task2.

Gateway

The Gateway system here is different from the Gateway system in SAP Fiori, which refers to the ABAP application server with the SAP_GWFND Software Component installed. The Gateway system we are about to discuss is one of the components in the ABAP application server.

SAP systems communicate with each other and with external systems through Remote Function Call (RFC) based on TCP/IP, and Gateway serves as the entrance of RFC Call distribution, as shown in the figure below:

It is worth noting that we can see CALL FUNCTION ‘XXX’ DESTINATION ‘NONE ‘written in SAP standard programs so that FUNCTION XXX is still executed internally on the application server instance calling it, rather than remotely on another server. So isn’t this writing superfluous?

The SAP website explains this usage: Destination “NONE” has the effect that the function module is started on the same application server as the calling program, however through the RFC interface and in its own RFC context.

That is, a function called in this way, even if it is in the same application server instance as the caller, will go through the RFC interface, the Gateway component, as if it were a remote call.

What is the payoff for this overhead of executing on the extra protocol stack? That starts with the different types of conversations in ABAP Netweaver. Every time we log in to the system with SAP GUI, a User Session is generated on the server. A new ABAP Session can be generated by entering/O on the command line in each User Session, and a new Internal Session can be generated by calling programs in each ABAP Session.

If the FUNCTION CALL FUNCTION ‘XXX’ is called directly, a new internal session is derived within the same ABAP session that initiated the FUNCTION CALL to execute the logic of the FUNCTION body. If the CALL FUNCTION ‘XXX’ DESTINATION ‘NONE’ is used, a new user session is derived, and this new user session is completely isolated from the original user session and does not share any data. Parameters are also passed through the RFC standard parameter transfer mode. In this way, asynchronous calls can be made between the called function and the original program, while program execution in the two user sessions is completely isolated from each other.

Transaction code SM04 sees all user sessions on the ABAP application server. Double-click a user session to view all ABAP sessions derived from the user session.

SAP Start Service

This service runs on a server where SAP application server instances are deployed. The implementation carrier is the Windows system service (sapStartsrv.exe) and the Unix Daemon process (sapStartsrv).

The SAP Start Service implements the following functions:

(1) Start and stop SAP application server instances, and monitor their running status. (2) Read and manage application server logs, tracking and configuration files

ABAP SAP Central Services Instances (ASCS)

This includes the Enqueue server and the message server.

Enqueue Server

Database level locks are managed by the database, while ABAP application level locks, such as locking an order, locking a material master data, are requested by the application and managed by Enqueue Server. The lock information management table of the Enqueue server is maintained in the memory of the Enqueue server and does not persist. Therefore, the Enqueue server becomes one of the single point of failure sources of the ABAP system. When the Enqueue server fails for various reasons and needs to be restarted, the data maintained in the lock information table in memory is lost.

Therefore, to ensure high availability of the Enqueue server, it is usually deployed on a separate physical host, or even multiple Enqueue servers that follow the Master/slave mechanism, and the lock information management table on the Master Enqueue server is synchronized to other Enqueue servers.

Transaction code SM12 Query the application lock held by a user:

Open any Lock object in SE11 and click Lock Modules to enter the automatically generated ABAP function to see how Lock requests are sent from the application server to the Enqueue server.

SAP Message Server

Each SAP system can contain only one message server, which is responsible for:

(1) as a central channel for communication between multiple application server instances within the SAP system (2) load distribution of login requests from clients via SAP GUI and SAP RFC

When an application server instance is started, its Dispatcher process contacts the message server to report the types of services it can provide.

The Message Server address of the SAP system can be queried in the Message Server field of the SAP GUI where the system login information is maintained.

Above, THE AG3 system I logged in has multiple application server instances. The instance NUMBER I logged in is 54. Using the transaction code SM53, I found that there are two other instances of the system, numbered 55 and 56.

Ignoring the fact that an SAP system can be composed of multiple application server instances, you can sometimes run into scenarios that don’t work as expected. For example, the database performance measurement tool ST05, if tracing is enabled on instance A and the business code is actually executed on instance B, the performance data cannot be seen after the application to analyze performance is executed and tracing is disabled on instance A. The safest thing to do in this case is to turn the trace on when you activate it by selecting “On all Instances.”

I hope you found the ABAP basics of this article useful. With this knowledge in mind, we can then look at how the engineers in SAP’s Linux lab containerized these components.

Thanks for reading.

For more of Jerry’s original articles, please follow the public account “Wang Zixi “: