1.

R/3 System Logon Steps:

R/3 system Logon steps When a SAPGUI process is started on the front end, a command line parameter is sent, indicating one of the following: -A specific dispatcher can be accessed directly -The logon must first be sent to the message server for purposes of logon load balancing

When using logon load balancing, the message server returns the IP address and

instance number of a specific dispatcher. The number of dispatchers available for a particular logon is configured in the system. Logon load balancing is useful if certain user groups are assigned to work on specific servers.

The message server returns the IP address of one of these assigned dispatchers,

which has for example shown the best response time during the last five minutes. Response times are stored in the collected Workload data.

The frontend process then connects to the assigned dispatcher, which selects a

free dialog work process to compare the logon user data with the user data stored in the database.

If the logon user data does not agree with the stored user data, no logon is

allowed. If the logon is successful, this dispatcher and its work processes are used for the duration of the session. If a user logs off and then logs on again to the system, logon load balancing may cause the message server to select another dispatcher for the user to work with.

2.when you retrive a data from database the actual work process inside the SAP system

System Dialog Step Once you have established a connection with a dispatcher through the SAPGUI, and a session is started for you in the system, the following steps are executed for each request: Data is passed from the SAPGUI to the dispatcher using the SAPGUI protocol based on TCP/IP

The dispatcher classifies the request and places it in the appropriate request queue The request is passed in order of receipt to a free dialog work process The subprocess taskhandler restores the user context in a step known as roll

in. The user context contains mainly data from currently running transactions called by this user and its authorizations

The taskhandler calls the dynpro processor to convert the screen data to ABAP The ABAP processor executes the coding of the Process after Input module

variables

(PAI module) from the preceding screen, along with the Process before Output module

(PBO module) of the following screen.It also communicates, if necessary, with the database

The dynpro processor then converts the ABAP variables again to screen fields. The current user context is stored by the taskhandler in shared memory (roll out) Resulting data is returned through the dispatcher to the front end

When the dynpro processor has finished its task, the taskhandler becomes active again