Usually as a developer in a language like C or C++ you need not care so much about the server. It might only matter to you if your program should run on a server in the end. When you are developing in ABAP things are different in this regard. In this weblog I will explain why the server concerns you from the very outset and why, consequently, you need to have some knowledge about the SAP NetWeaver Application Server ABAP. And this is what I want to provide you with in this weblog: some basic information on the SAP NW Application Server ABAP.
Developing on the Server
For those experienced with other programming languages like C, Java, or Visual Basic working with ABAP offers some features they might not be accustomed to. The structure of the development environment for ABAP is different from probably everything that you might have encountered so far: In ABAP, you program on the server from the outset. You do not develop the programs locally on your PC, nor do you store the sources in a versioning system or deploy the programs on the server at a later stage.
In order to program with ABAP, you therefore require access to and developer authorization for the SAP NW Application Server ABAP. You write your programs using the ABAP Editor of the ABAP Workbench and the tools integrated there, which are also part of the server. However, the SAP NW Application Server ABAP not only contains the programming environment with its tools and utilities for supporting the software lifecycle. Developing with ABAP is closely connected to the server in another respect: Once you activate your source code, platform-independent byte code is generated, which the runtime environment interprets for the program execution. And this byte code generated from your ABAP program runs on the SAP NW AS ABAP. Usually many developers are working on the same server.
This way, a problem known to all developers in large projects does not even arise: No quality manager needs to care about providing a system on which to deploy the programs from different developers and where to test the interaction of the programs from different developers in a project. Everything to accomplish this, is already done, and you as a developer already have your programs in the right place: As soon as your source code is activated the respective development object is visible on the central system. So the principle in ABAP is: Development on a central server.
You need also not care about checking in and out your sources in a content management system. The whole persistence and administration of different versions of your sources also happens transparently to the users. Pushing the Save-button in the ABAP Workbench stores your program in the database. You retrieve it by the program name: There is no fumbling with program files in ABAP. Again the server does it all for you.
By the way, this is a typical experience when working with the SAP NW AS ABAP: Many things you need for business programming are provided by the system. The ABAP server does a lot of services for you in the background that developers or quality manager usually have to care about.
The explanation for these conveniences is the fact that the organization and structure of and the technology behind the development process in ABAP is different. Some these features need getting used to, but after a while you will like them because thanks to them you can concentrate on what your job really is about: developing business logic.
It is for this reason that you must take into account the architecture of the environment in which ABAP programs run when designing and developing these programs. For this purpose, you first require some information about this architecture.
The Three-Layer Architecture
The SAP NW Application Server ABAP consists of three layers: presentation, application, and database. The database layer of a system is made up of a central database with a database management system and the database itself. It not only contains the user data, but also the entire program code of the SAP NW AS and application programs, all administrative data, and Customizing settings. That is, the programs you develop are stored in the database of the system.
The application layer lies between the database layer and the presentation layer. It consists of one or more application servers (more than 100 servers possible) and a single message server, which is responsible for communication and load distribution within this layer. The programs that process the business logic of an application and all the development tools such as the ABAP Workbench run in this layer.
Work Processes in Some Detail
Technically, the actual processing takes place in work processes, which represent processes of the operating system. A fixed database connection is assigned to each work process. For you as a developer this means: You always have a database connection at hand. No need to get a database manager, to open,
handle and close the database connection. The whole database handling is done for you in the background by the server.
There is no fixed assignment of users to work processes. A lengthy user session can utilize different work processes sequentially, and one work process is used by different users consecutively. Still the state of your program is kept. The context of your work process is rolled in as soon as your program is processed and once the work process returns a result, your context is rolled out. It is this so-called roll area that contains all the data and programs that are currently processed by a user.
This architecture makes for robustness and scalability. It is robust because every user has a work process of his own, for the time his program is processed. All that can happen in the worst case only concerns the work process your program currently occupies. There is no such thing like crashing the whole engine in ABAP by a severe syntax error in your program.
The way user requests are distributed to work processes combines the advantages of stateful and stateless communication. On the one hand, a user does not occupy a process for a long period while he might not be doing anything. On the other hand, the Dispatcher (within the server) knows and remembers the identity of a user over time: This way each time a user session gets processed its context is known.
To give you a better understanding of this mechanism I will present you an example of how a user of a particular application is assigned to different work processes at different points in time when performing different steps in a application. To avoid one possible misunderstanding from the outset: In general, one request is processed within a single work process though it is possible to write programs in ABAP that distribute different costly tasks on several work processes (such as, for example, several large selects on the database if they do not depend on each other).
Let us suppose a loan officer, let us call him Jones works with an application in the office: First retrieves the table of debtors in a particular region. His request is processed by work process 1 (picture 1). But, of course, he might get any other work process that is currently free.
If the request is processed the result is sent back to the user. The roll area that keeps the state and data of user 1 is rolled out and the work process is freed for requests of other users (picture 2). As long as user Jones does not interact with the application he does not occupy any work process. By the way, the other users in our pictures are assigned to other free work processes in the same way as user Jones is. But this is not shown in the picture, as I want to keep the focus on the way user Jones is assigned to work processes.
Next our loan officer wants to get the details of a particular customer. He gets assigned to work process 3 and his roll area in the state he has left it is rolled into this work process (if there is not much traffic on a server, you will stay in general in the same work process, because the server tries to minimize the cost for rolling-in and -out, but this is a matter of optimization details, and I am interested here in the general mechanism).
Again the work process is freed after the request is processed (picture 2). Next the loan officer sets a new credit limit for Smith and saves it. Again he gets another work process. His roll area is rolled in, the request is processed and the data is saved on the database.
This way a user does only occupy a work process when the application he uses actually sends a request. Due to this mechanism it is possible to have far more users than work processes on an AS ABAP. So a typical SAP ERP System running on an AS ABAP server might have 50 work processes and 500 users currently logged on (This is, of course, only an example to show the ratio, the actual number of work processes on a server depends on many technical details such as the CPU power of the servers, the RAM that is available, what kind of applications the users typically are running, how many users are logged on simultaneously etc.. The number of work processes for a system is determined in the profile by the system administrator)
The Three Layer Architecture Continued
The kernel and the Basis services make up the part of the application layer that is specific to both the operating system and the database. They are responsible for user and process management, database access, communication with other systems, as well as system monitoring and administration. The software processes or virtual machines, that interpret the platform-independent byte code as operating system-specific machine language commands, run in the kernel.
The presentation layer represents the interface with the user and is responsible for the screen display. This layer receives user entries - that is, mouse-clicks and keyboard input - and passes them on to the application layer. Furthermore, it receives data from the application layer and displays it to the user. When writing a business application you should use Web Dynpro ABAP as a state-of-the-art user interface. A Web Dynpro ABAP component may run on the same server as the underlying business logic. A ABAP Web Dynpro application is displayed in the Browser or the Business Client.
The ABAP workbench and all the other tools you need for developing use the Dynpro technology (Dynpros are the classical user interfaces of most ABAP-based SAP programs and run in the SAP GUI). In our demo programs in this series, we will sometimes use classical Dynpros to input and output data as a handy device just as you use the output to the console in Java Tutorial. It saves you time if you want to test a backend program and the real user interface written in Web Dynpro ABAP is not yet available or you want to test the business logic apart from the presentation logic. The real user interface of your programs should always be developed with Web Dynpro ABAP.
The purpose of this division in three layers is high performance and scalability. The layer division is purely logical. It does not imply over how many machines the system is distributed. In fact, all three layers can actually run on a single computer. For demonstration purposes, such as you have just done it in the case of this demo system, it is possible to install all three layers on a single PC. However, in the case of large, production applications of customers, this is more of a theoretical possibility, since it would counteract the scalability of the three-level architecture.
Summary
Now you should have understood that you always work on the server when developing in ABAP. It is for this reason that I have explained to you the basics of the three-level architecture of the server and the way users are assigned to work processes. In the next weblog I will explain the impact of development on a central server on the developing process. Again I will focus on an example that is intended to illustrate a basic mechanism. This time you will lean some details about what happens when you activate your program.
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
