We all might have come across of many architectural information on various SAP component.
Work process is one of the main component of SAP WEB AS architecture and today I would like to share some information on work process…their architecture and dialog step.
Work Process Architecture: Work process architecture comprise 3 main components as shown in the figure below
- Dialog Interpreter
- ABAP Processor
- Database Interface
- Task Handler: It coordinates the activities within a work process. It manages the loading and unloading of the user session context at the beginning and end of each dialog step. It also communicates with the dispatcher and activates the Dynpro interpreter or the ABAP processor as required to perform its tasks.
- ABAP processor: Is in charge of executing the ABAP programs
- Dialog interpreter: (Also known as the Dynpro processor) is in charge of interpreting and executing the logic of R/3 screens.
- Database interface: It establishes and terminates connection between the work process and database. It also allows to Access to database tables, access to Repository objects , Controlling transactions (commit and rollback handling)
What is a Dialog Step:
- 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 variables
- The ABAP processor executes the coding of the “Process after Input” module (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. When the Dynpro Processor has finished its task, the taskhandler becomes active again
- 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
That’s all folks !!!!!
Please feel free to add/correct the information placed above. Thank you.