SAP R/3 ABAP Architecture (Logical View ):-
SAP R/3 ABAP Architecture ( Software View ):-
SAP R/3 ABAP Application Server Architecture :-
In short:
Application server also knows as ‘Instance’, Database Server known as ‘Central Instance’.
The architecture of application server defines as:
All the requests that come from the presentation servers are directed first to the dispatcher. The dispatcher writes them fist to the dispatcher queue. Te dispatcher pulls the request from the queue on first-in , first-out basis. Each request is then allocated to the first available work process.
To perform any processing for a user’s request a work process needs to address two special memory areas i.e. User Context and the program roll area. The user context is a memory area that contains information about the user and the roll area is a memory area that contains information about the user, and the roll area is a memory area that contains information about the program execution.
User Context is responsible for:
- User’s Current settings
- User Authorizations
- The name of the program the user currently is running
Roll Area is responsible for:
- The values of the variables
- The dynamic memory allocations
- The current program pointer
Each time a user starts a program, a roll area is created for that instance of the program. If two users run the same program at the same time, two roll areas will exist-one for each user. The roll area is freed when the program ends.
Roll Area and the user context play an important part in dialog step processing.
Roll-In / Roll-out processing in dialog step process. An ABAP/4 program only occupies a work process for one dialog step. At the beginning of the dialog step, the roll area and user context are rolled into the work process. At the end of the dialog step they rolled out.
During the roll in pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.
Components of work process:
Each work process composed of:
- A Task Handler
- An ABAP Interpreter
- A screen Interpreter
- A Database Interface
All requests pass through the task handler, which then funnels the request to the appropriate part of the work process.
The interpreters interpret the ABAP/4 code. Notice that there are two interpreters: the ABAP/4 interpreter and the screen interpreter. There are actually two dialects of ABAP/4. One is the full-blown ABAP/4 data processing language and the other is a very specialized screen processing language. Each is processed by its own interpreter. The database interface handles the job of communicating with the database.
There are seven types of work process each handles a separate type of requests.
WP Type Request Type
D (Dialog) Dialog requests
V (Update) Requests to update data in the database
B (Background) Background jobs
S (Spool) Print spool requests
E (Enqueue) Logical lock requests
M (Message) Routes messages between application servers within an R/3 system
G (Gateway) Funnels messages into and out of the R/3 system
Memory Structures of an ABAP Program
A user can open up to six R/3 windows in a single SAPgui session. Each of these windows corresponds to a session on the application sever with its own area of shared memory.
The first application program that you start in a session opens an internal session within the main session. The internal session has a memory area that contains the ABAP program and its associated data. When the program call external routines (methods, subroutines or functional module) in their main program and working data are also loaded in to the memory area of the internal session.
Only one internal session is ever active. If the application program calls a further application program the system opens another internal session. Here there are two possible cases: If the second program does not return control to the calling program when it has finished running, the called program replaces the calling program in the internal session. The Contents of the memory of the calling program are deleted. If the second program does return control to the calling program when it has finished running the session of the called program is not deleted. Instead it becomes inactive and its memory contents are placed on a stack.
The memory area of each session contains an area called ABAP memory. ABAP memory is available to all internal sessions.
All ABAP programs can also access the SAP memory. This is the area to which all sessions within a SAPGUI have access. One can use SAP memory either to pass data from one program to another within a session or to pass data from one session to another.
Application programs that use SAP memory must do so using SAP/GAP parameters (also known as SET/Get parameters).
SAP memory is the only connection between the different sessions within a SAPgui.