Getting Started Newsletters Store

Products Services & Support About SCN Downloads

Industries Training & Education Partnership Developer Center
Lines of Business University Alliances Events & Webinars Innovation
Log On Join Us Hi, Guest Search the Community
Activity Communications Actions
Browse
thomas.weiss
Previous
post
Next
post
0 Tweet 0
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
ABAP Trial Version for Newbies: Part 3 - Why and
How the Server Matters to You as a Developer: Server
Architecture and Work Processes
Posted by Thomas Weiss in thomas.weiss on Mar 30, 2007 5:04:19 AM
Share 0 Like
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
Average User Rating
(1 rating)
My Rating:
0 Tweet 0
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.
2362 Views
Share 0 Like
7 Comments
Like (1)
Bharathwaj Ragothaman Mar 30, 2007 6:52 AM
This is awesome stuff.. Excellent clarity in content..
Am not an ABAPer..but I would love to understand the architecture.. without going through numerous
information sources..
Love it !
Looking forward for more.. !
Like (0)
Divya Vidyanandan Prabhu Feb 5, 2008 12:08 PM (in response to Bharathwaj Ragothaman)
agree with bharath.. excellent in clarity... thanks a lot, for a thourogh blog on architecture.
Like (0)
Abdul Hakim Mar 31, 2007 8:09 PM
Hi Thomas,
Very Nice Blog..Keep Up the gud work..
Regards,
Hakim
Like (0)
Alfredo Avendano Apr 20, 2007 8:41 AM
How can I see the Parts 1 and 2 ?
Like (0)
s s Apr 23, 2007 11:36 PM (in response to Alfredo Avendano)
Hi,
Following is the link of Part 2 :
ABAP Trial Version for Newbies: Part 2 ' Starting and Stopping the Application Server '
In this blog, in the first line you will be able to find a hyperlink for Part 1.
Hope it helps.
Like (0)
Gopi Kumaran Oct 26, 2007 2:09 AM
Good work guys.You are helping number of people with your expertise.Cheers
Santosh Raghavan Mar 26, 2009 12:16 PM
Hey Thomas,
Nice Blog! Very clear and informative to a non ABAP'er like me. Keep up the good work.
Santy
Follow SCN
Site Index Contact Us SAP Help Portal
Privacy Terms of Use Legal Disclosure Copyright
Like (0)