If you are interested in the Where-used list of SAP objects, you need the report SAPRSEUB. This one is able to create the "where used list" for all SAP objects as well.
Normally, the "where used list" for SAP objects is only very limited filled. So, it is typically, that only about 20% of the data is filled. Therefore, the results are not very helpful.

When you want to have a complete overview on cross refereces of the SAP tables and ABAPs, you need to run SAPRSEUB. You should keep in mind, that this needs about 10 GB space in the DB and takes about 2 days to complete.

But then, you really have a perfect tool in order to understand the SAP sources in detail ;-))

This SAP Tip courtesy of Raju at help-sap.blogspot

All of us know that R/3 system architecture consists of Presentation Server, Application Server and Database Server. Here I would like to share some details of Application Server.

Application Server basically consists of a DISPATCHER and multiple WORK PROCESSES.

SAP dispatcher is the control agent which manages the resources for the R/3 applications.

A work process is where individual dialog steps are actually processed and the work is done. Each work process handles one type of request.

Functions of dispatcher:

1. Equal distribution of transaction load to the work processes
2. Management of buffer areas in main memory
3. Integration of the presentation levels
4. Organization of communication activities

All requests that come in from presentation servers are directed first to the dispatcher. The dispatcher writes them first to the dispatcher QUEUE. The dispatcher pulls the requests from the queue on a first-in, first-out basis. Each request is then allocated to the first available work process. A work process handles one request at a time.

In order to do any processing for a user's request, work process needs two special memory areas: viz. User Context and Program Roll Area.

User Context is memory area that contains information about the USER.

Program Roll Area is memory area that contains information about the PROGRAMS execution

User Context holds the following information of the User needed by R/3:

1. The user's current settings
2. The user's authorizations
3. The names of the programs the user is currently running

When a user logs on, a User Context is allocated for that logon. When they log off, it is freed.

Roll Area holds the following information of the program:

1. The values of the variables
2. The dynamic memory allocations
3. The current program pointer

Every time a user starts a program, a roll area is created for that instance of the program. If three users run the same program at the same time, three roll areas will exist-one for each user. The roll area is freed when the program ends.

An ABAP/4 program occupies only one work process for one dialog step. At the beginning of the dialog step, the Roll Area and User Context are rolled in to the work process. At the end of the dialog step, they are 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.

When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out.

When the program terminates, the Roll Area is freed.

The User Context remains allocated until the user logs off.

In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.

Components of Work Process:

Each work process has the following components:

• A task handler
• An ABAP/4 interpreter
• A screen interpreter
• A database interface

Task Handler:

All requests pass through the task handler, which then distributes the request to the appropriate part of the work process.

Interpreter:

The interpreters interpret the ABAP/4 code. There are two interpreters: the ABAP/4 interpreter and the Screen interpreter. ABAP/4 Interpreter is data processing language and Screen Interpreter is very specialized screen processing language. Each is processed by its own interpreter.

Database Interface:

The database interface handles the job of communicating with the database.

Type of Work Processes:

There are seven types of work processes. Each handles specific type of request.

An update request can be divided into one primary (V1) and several Secondary update components (V2). Time-critical operations are placed in V1 component and those whose timing are less critical are placed in V2 components. If a V1 update fails, V2 components will not be processed.

Spool requests are generated during dialog or background processing and placed in the spool database with information about the printer and print format. The actual data is placed in the Tem Se (Temporary Sequential objects).

*****************************

Some Trivia

1. If there are three R/3 systems in your current system landscape, then there will be three databases.
2. If an R/3 system has two application servers, then it will have three instances. Two for the Application Servers and one for Database server
3. A new roll area is allocated whenever a program is executed, and it is de-allocated when the program terminates. The roll area contains the values of the variables for that program and the current program pointer.
4. A user context is allocated each time a user logs on, and de-allocated when he or she logs off. It contains information about the user, such as authorizations, profile settings, and TCP/IP address.
5. The roll-out occurs at the end of a dialog step. It frees the work process to ready it for other requests, so that the program will not use CPU while waiting for user input.