In this series of articles I want to start out by covering the high-level architecture of an SAP system, including the technical architecture and platform independence. We will dig into the environment that our ABAP programs run in, which include the work processes and the basic structures of an ABAP program. Then we can focus on a running SAP system, discuss the business model overview, and begin looking at the ABAP workbench.
SAP System Architecture
First, the Technical Architecture of a typical SAP system will be discussed, before moving on to the Landscape Architecture, and a discussion of why the landscape should be broken into multiple systems.
This diagram shows the 3-tier Client/Server architecture of a typical SAP system:
At the top is the Presentation server, which is any input device that can be used to control an SAP system (the diagram shows the SAP GUI, but this could equally be a web browser, a mobile device, and so on). The Presentation layer communicates with the Application server, and the Application server is the ‘brains’ of an SAP system, where all the central processing takes place. The Application server is not just one system in itself, but can be made up of multiple instances of the processing system. The Application server, in turn, communicates with the Database layer.
The Database is kept on a separate server, mainly for performance reasons, but also for security, providing a separation between the different layers of the system.
Communication happens between each layer of the system, from the Presentation layer, to the Application server, to the Database, and then back up the chain, through the Application server again, for further processing, until finally reaching the Presentation layer.
A typical Landscape Architecture – Typical here is subjective, in practical terms there is not really any such thing as a standard, ‘typical’ landscape architecture which most companies use. However, it is common to find a Development system, a Testing system and a Production system:
The reason for this is fairly simple. All the initial development and testing is done on a Development system, which ensures other systems are not affected. Once developments are at a stage where they may be ready to be tested by an external source, or someone within the company whose role is to carry out testing, the developments are moved, using what is called a Transport System, to the next system (here, the Testing system).
Normally, no development at all is done on the testing system; it is just used for testing the developments from the development system. If everything passes through the Testing system, a Transport system is used again to move the developments into the Production environment. When code enters the Production environment, this is the stage at which it is turned on, and used within the business itself.
The landscape architecture is not separated just for development purposes; the company may have other reasons. This could be the quantity of data in the Production system, which may be too great to be used in the development environment (normally the Development and Testing systems are not as large as the Production system, only needing a subset of data to test on). Also, it could be for security reasons. More often than not, companies do not want developers to see live production data, for data security reasons (for example, the system could include employee data or sales data, which a company would not want people not employed in those areas to see). Normally, then, the Development and Testing systems would have their own set of data to work with.
The three systems described here, normally, are a minimum. It can increase to four systems, perhaps with the addition of a Training system, or perhaps multiple projects are running simultaneously, meaning there may be two separate Development systems, or Testing systems, even perhaps a Consolidation system before anything is passed to the Production environment. This is all, of course, dependent on the company, but commonly each system within the Landscape architecture will have its own Application server and its own Database server, ensuring platform independence.
Environment for Programs
Next, we have the environment which programs run in, the Work Processes, and the structure of an ABAP program.
Within an SAP system, or at least the example used here, there are two types of programs, Reports and Dynpro’s.
Reports, as the name would suggest, are programs which generate lists of data. They may involve a small amount of interactivity, but mainly they supply data to the front-end interfaces, the SAP GUI and so on. When a user runs a report, they typically get a selection screen. Once they enter their selection parameters and execute the report, they normally cannot intervene in the execution of the program. The program runs, and then displays the output.
Dynpro’s are slightly different. They are dynamic programs, and allow the user to intervene in the execution of the program, by processing a series of screens, called Dialogue screens. The user determines the flow of the program itself by choosing which buttons or fields to interact with on the screen. Their action then triggers different functions which have been coded within the flow logic of the program. While reports are being created, interfaces are also to be generated which are classed as Dynpro’s, for all the selection criteria.
Most of the work done by people involved with ABAP is done within Report programs, and even though these programs are labelled ‘Reports’, they do not always generate output. The Report programs are there to process the logic, reading and writing to the Database, in order to make the system work.
Every program that runs in an SAP system runs on what are called Work Processes, which run on the Application server. Work Processes themselves work independently of the computer’s operating system and the Database that it interacts with, giving the independence discussed earlier with regard to the Technical architecture. When an SAP system is initially set up, the basis consultants (who install the system, keep it running, manage all the memory and so on) configure SAP in such a way that it automatically sets the number of Work Processes programs use when they start, the equivalent of setting up a pre-defined number of channels or connections to the Database system itself, each of which tend to have their own set of properties and functions.
You might come across something referred to as the Dispatcher. The SAP system has no technical limits as to the number of users who can log on and use it, generally the number of users who can access an SAP system is much larger than the number of available Work Processes the system is configured for. This is because not everybody is sending instructions to the Application server at exactly the same time. Because of this, users cannot be assigned a certain number of processes while they are logged on.
The Dispatcher controls the distribution of the Work Processes to the system users. The Dispatcher keeps an eye on how many Work Processes are available, and when a user triggers a transaction, the Dispatcher’s job is to provide that user with a Work Process to use. The Dispatcher tries to optimise things as far as possible, so that the same Work Process receives the sequential Dialogue steps of an application. If this is not possible, for example because the user takes a long time between clicking different aspects of the screen, it will then select a different Work Process to continue the processing of the Dialogue program. It is the Work Process which executes an application, and it is the Work Process which has access to the memory areas that contain all of the data and objects an application uses. It also makes three very important elements available.
The first is the Dynpro processor. All Dynpro programs have flow and processing logic, and it is the Dynpro processor’s job to handle the flow logic. It responds to the user’s interactions, and controls the further flow of the program depending on these interactions. It is responsible for Dialogue control and the screen itself, but it is important to remember that it cannot perform calculations; it is purely there to manage the flow logic of a program.
The next important element is the ABAP processor, which is responsible for the processing logic of the programs. It receives screen entries from the Dynpro processor, and transmits the screen output to the program. It is the ABAP processor which can perform the logical operations and arithmetical calculations in the programs. It can check authorisations, and read and write to the Database, over the Database Interface.
The Database Interface
The Database Interface is the third important element. It is a set of ABAP statements that are Database independent. What this means is that a set of ABAP statements can be used that, in turn, can communicate with any type of Database that has been installed when the system was set up. Whether this is, for example, a Microsoft SQL server or an Oracle Database, you can use the same ABAP statements, called Open SQL, to control the entire Database reading and writing over the Database Interface. The great advantage of this is that the ABAP statements have encapsulation, meaning the programmers do not need to know which physical Database system the ABAP system they are using actually supports.
There are times when you may want to use a specific SQL statement native to the database which is installed. ABAP is designed in such a way that if this type of coding is necessary, this facility is available. It is possible to directly access the Database through the programs using native SQL statements, but this is not encouraged. Normally, when systems are set up, the system administrator will forbid these practices, due to the security and stability risks to the system which may be introduced. If you are going to be programming ABAP, make sure Open SQL is used, because then anyone subsequently looking at the programs will understand what is trying to be achieved.