SAP Technical Architecture

Hello everyone,

Welcome back to my blog. In this topic, we are going to discuss the Architecture of an SAP ABAP system.

High-level architecture:

On a high level, you can divide the architecture of an SAP system into three layers.

Presentation layer – where the users use channels like SAP Logon Pad, SAP Business Client, SAP FIORI, Web browser or Mobile Apps to access an SAP system.

Application layer – This is where the ABAP or JAVA application server of an SAP system is located. The application server is the foundation of any SAP system. It is the engine that receives and processes all the requests and interacts with the Database to retrieve the required information and send it back to the presentation layer.

Database layer – This is where the Database of a system is located.

All software applications that follow the client-server model have these three layers as their basic architectural principle and SAP systems are no exceptions here.

Now let us get into the details of the Components of an ABAP system:

An ABAP system consists of an ABAP Server Central Services instance which in short is known as ASCS and an Application Server instance.

An instance is an administrative unit that contains various components. For example, ASCS is an instance and the application server is another instance.

An ABAP system has only one ASCS instance but it can have multiple Application server instances depending on the expected load on the system. The ASCS and application server instance can be installed on the same host or they can be installed on separate hosts for high availability purposes. An ABAP system has a system identifier, also known as SID and separate instance numbers. SIDs are usually three-letter combinations of alphanumeric characters and instances are two-letter numeric.

For example, the SID of an SAP system can be something like PE0 and the instance number of ASCS can be 00 whereas the instance number of the application server can be 01, 02, or 03 depending on how many application servers are there. The SIDs and instance numbers are assigned during the installation of an SAP system.

Now let us take a look at the Components of SAP ABAP Server Central Services:

ASCS consists of a separate start service, a message server and an enqueue server. The start service within the ASCS interacts with the start service that is located in the application servers in order to keep track of the status of the application server within a particular SAP system. For example, let’s assume an SAP system has 3 application servers. Each application server, when it is started, logs on to the ASCS to advise its runtime state. So that the ASCS knows how many of the application servers are on-state and how many of them are off-state.

Additionally, the ASCS contains a message server. The message server enables communication between individual application servers. It also distributes the load if there are multiple application servers available so that not all the requests are handled by just one application server.

Then, Enqueue server is responsible for managing locks. It ensures, that no two transactions or users are trying to update the same field in the same table at the same time. Thus avoiding synchronisation issues. So if I am editing a program that will update a table, the enqueue server will lock that table and releases it back to others once I have finished updating it.

So, in a nutshell, the ASCS doesn’t process any dialogue requests. That means it doesn’t do any calculations or retrieve data from the database or anything like that. But it acts as an administrative unit within the SAP system and manages the application servers beneath it.

Now let us talk about the components of an Application server:

An Application Server consists of components like an ABAP dispatcher, Gateway, Internet Communication Manager, Start service and work processes.

Let’s take a look at these components one by one.

• ABAP dispatcher – The ABAP dispatcher distributes the work to the work processes depending on the type of request that comes through.
• Gateway – The Gateway enables the SAP system to communicate with other SAP and non-SAP systems with the help of RFC (Remote Function Call) functionality by using TCP/IP protocol.
• ICM – ICM is known as Internet Communication Manager which handles HTTPS and SMTP-type requests from the internet. So, depending on the type of request, it is handled by either the ABAP dispatcher or the gateway or the ICM. For example, if the system receives requests from the SAP logon pad then the ABAP dispatcher handles it. If the request comes from a different SAP system through an RFC connection, then it will be handled by the Gateway and if the request comes from webdynpro application or a web browser, then it will be handled by the Internet Communication Manager.
• Work Processes – Work processes are a bunch of programs that process the different types of requests that come to the SAP system via the ABAP dispatcher. Different types of work processes are Dialog, Update, Batch, Print and Enqueue. For example, if the request is a dialog request then the ABAP dispatcher sends it to dialog work process and so on and so forth.
• Let’s take a look at the five different work processes in detail
• Dialog – The Dialog work process deals with all requests that are executed by an active user or program or RFC and HTTP requests. Basically, dialog work processes are involved whenever a request is processed in the front end by the SAP system. For each application server, you need at least to configure two dialog work processes. But you can configure more if required.
• Update – The update work process is used to update the database. For example, you make a calculation and you need to update the database table with the result. The update work process takes care of updating a particular field in a table in the database. You need to have at least one update work process in an application server
• Batch – Programs that can be executed in the background without user interaction are known as batch jobs. Time-consuming and resource-intensive calculations are sometimes configured to be run in the background so that it doesn’t interrupt the real-time activities of the users in the front end. You need at least 2 batch work processes in an ABAP system but you can configure more depending on the requirement. For example, if your company need to run a lot of batch programs, then you might need more work processes for Batch.
• Print – This work process processes and manages all the print requests. For example, the printing of work orders or purchase orders, etc.
• Enqueue – This work process handles the locks and unlocks of objects. As discussed before in the ASCS component, Locks are an important part of an SAP system that ensures a table or an entry is not updated by two users at the same time. So if someone or a program is executing a transaction, then enqueue work process will lock that particular table so that only one person or program can update it at any given time. This will avoid data inconsistencies in an SAP system. The lock mechanism is widely used by pretty much all the applications that have a need to update the databases, not just SAP applications. And you need this work process in the application server only if you don’t have an ASCS instance. Otherwise, the enqueue server in the ASCS instance will take care of the enqueue processes.

So, on a high level, this is the architecture of an SAP ABAP system.

Hope it was useful. If you have any questions, please leave a comment on the YouTube video and I will reply.

If you like this blog or the YouTube video, please share it with your friends who might find it helpful.

P.S. Check out my course on Udemy – “Introduction to SAP – The Complete Package for Beginners“