SAP-ABAP supports two types of programs Report Program and Dialog Program.

. If your ABAP program demands user input , Dialog programming is used. A user dialog is any form of interaction between the user and the program and could be any of the following

Entering data Choosing a menu item Clicking a button Clicking or double clicking an entry

Dialog program is also used when we need to navigate back and forth between screens Dialog programs are created with type as M Module Pool. They cannot be executed independently and must be attached to at least one transaction code in which you specify an initial screen.

Difference between Report and Dialog Programs

Report Program: A report is a program that typically reads and analyzes data in database tables without changing the database. Dialog Program: A dialog program allows you to work interactively with the system and to change the contents of the database tables. Each dialog program has a certain sequence of screens that are processed by the system one after the other.

A Sample transaction processing in Dialog Programming

Components of Dialog Program

Unlike report which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on its own. Instead all objects are linked hierarchically to the main program and and are executed in a sequence dictated by the Dialog Main Program. The components of a dialog program are: Transaction code

The transaction code starts a screen sequence. You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93. A transaction code is linked to an ABAP program and an initial screen. You can start a screen sequence from any ABAP program using the CALL SCREEN statement.

Screens

Each dialog in an SAP system is controlled by one or more screens. You create screens using the Screen Painter in the ABAP Workbench through transaction SE51 Each screen belongs to an ABAP program. These screens consist of a screen mask or layout and its flow logic. The screen has a layout that determines the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. A flow logic determines the logical processing within screen.

GUI status

Each screen has a GUI status(es) which are independent components of a program.

This controls the menu bars, standard toolbar, application toolbar , with which the user can choose functions in the application. You create them in the ABAP Workbench using the Menu Painter.

ABAP Program

Each screen and GUI status in the R/3 System belongs to one ABAP program. The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user input from the GUI status. ABAP programs that use screens are also known as dialog programs. In a module pool (type M program); the first processing block to be called is always a dialog module. However, you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing block is then called differently; for example, by the runtime environment or a procedure call. The screen sequence is then started using the CALL SCREEN statement.

Screen Flow Logic Screen Flow logic is primarily divided into four components.

Process Before Output (PBO) event: which is processed before the screen is displayed Process After Input (PAI) event: which is processed after a user action on the screen Process on help request (POH): which is processed when F1 is pressed Process on value request (POV):which is processed when F4 is pressed

Dynpro

A screen together with its Flow logic is called a Dynpro (Dynamic Program since the screen flow logic influences the program flow) Each dynpro controls exactly one step of your Dialog Program. The screens belonging to a program are numbered. The screen flow sequence can be either linear or cyclic. From within a screen chain, you can even call another screen chain and, after processing it, return to the original chain. You can also override the statically-defined next screen from within the dialog modules of the ABAP program.

ABAP Module Pool

On a PBO or PAI event a Dynpro calls an ABAP dialog program. Collection of such programs is called the ABAP module pool. For example modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.

All dynpros to be called from within one transaction refer to a common module pool.

Structure of a Dialog Program

Process Flow for a Dialog Program

Sub screens: at a Dialog Program is

Subscreens

A subscreen is an independent screen that is displayed in an area of another (main) screen. Subscreens allow you to embed one screen within another at runtime. You can include multiple sub-screens on main screen. The term subscreen applies both to the screen that you embed, and the area on the main screen in which you place it. This tutorial is about subscreen areas. The actual screens created through SE51 transaction, are called subscreen screens if defined in screen attributes. When you use a subscreen, the flow logic of the embedded screen is also embedded in the flow logic of the main screen.Hence, Using subscreens on screens is like using includes in ABAP programs.

To use a subscreen, you must follow three simple steps 1. Define the subscreen area(s) on a screen 2. Define suitable subscreen screens 3. Include the subscreen screen in the subscreen area. Also, you need to adjust the frame of sub-screen and main screen. You need to name it in the field name field. Further, you also need to adjust the fields within the subscreen to make them appear in main screen. In case the sub-screen is defined to be larger than the available area in the main screen, only the part of subscreen will be visible that fits in the the area available. The area is always measured from the top left corner of screen. Hence you should take adequate care while defining sub-screen areas and creating sub-screens. EXAMPLE For instance here we have defined two sub-screen areas on main screen and have attached two different Sub-screen to corresponding areas. Whenever main screen is called, the PBO of main screen is called. But before display, the PBOs of each screen attached with sub-screen areas on main screen are also called.

You can include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of the main screen.

To include a subscreen screen in the subscreen area of the main screen and call its PBO flow logic, use the following statement in the PBO event of the main screen: PROCESS BEFORE OUTPUT. CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>. This statement assigns the subscreen screen with number <dynp> to the subscreen area called <area>. You can also specify the program in which the subscreen screen is defined (optional). If you do not specify the program explicitly, the system looks for the subscreen screen in the same ABAP program as the main program. If it does not find a corresponding subscreen screen, a runtime error occurs. The PBO flow logic of the subscreen screen is also included at the same point. This can call PBO modules of the ABAP program in which the subscreen screen is defined. At the end of the subscreen PBO, the global fields from the program are passed to any identically-named screen fields in the subscreen screen. The PBO flow logic of the subscreen screen can itself include further subscreens. The name <area> of the subscreen area must be entered directly without inverted commas. You can specify the names <prog> and <dynp> either as literals or variables. If you use variables, you must declare and fill identically-named variables in the ABAP program. The screen number <dynp> must be 4 characters long. If you do not assign a subscreen screen to an area, it remains empty. To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow logic of the main screen: PROCESS AFTER INPUT. CALL SUBSCREEN <area>. This statement includes the PAI flow logic of the subscreen screen included in the subscreen area <area> in the PBO event. This can call PAI modules of the ABAP program in which the subscreen screen is defined. Data is transported between identically-named fields in the subscreen screen and the ABAP program either when the PAI event is triggered, or at the corresponding FIELD statements in the PAI flow logic of the subscreen screen. Points to Remember

Names of elements of sub-screens within a screen should be unique You should not have OK_CODE or FCODE attached with sub-screen. The OK_CODE of main screen itself is OK_CODE of sub-screen Sub-screens cannot have any dialog modules containing SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN or LEAVE TO SCREEN. This will cause runtime error.

You need to call it in the flow logic (both PBO and PAI) of the main screen. CALL SUBSCREEN is not allowed in CHAIN..ENDCHAIN and LOOP ENDLOOP statements Can not have an AT EXIT-COMMAND module The fields that you use are the global fields. They must be declared in the top include If using subscreens from another dialog program the data transfer will not happen unless you add specific code.

This component though is not attached to the screen painter, plays important role in transaction. Normally, for reports, on line executable programs are written but for transaction, Module Pool Programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements.

System divides the module pool program into several include program. These are global field, PBO modules, and PAI modules. It is entirely users decision whether to use these modules or write directly into main program.

Creation of Module Pool Program You can create module pool program either through Object browser System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules. Or ABAP/4 editor It is similar to normal program creation. Type of program should be given M and is not created by system. Communication between Dynpro and Module Program For each screen, the system executes the flow logic, which contains corresponding events. The control is passed to Module Pool Program. Module Pool Program handles the code for these events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case, the control remains with flow logic. The switching of control between flow logic and

module pool program and back is common process when user executes transaction.

Creation of a Complete Transaction Steps involved to create a complete transaction Create module pool program. From screen painter create screens. Write flow logic for each screen. Write code for all the events in module pool program. Check for any error in screen and flow logic. Generate each and every component of screen i.e. flow logic and screen. Single screen can be tested using Screen Painter. Create transaction code through object browser. Generate the transaction code. User can execute the transaction by entering the transaction code in the command field. Handling Function Code The function code or OKCODE is the last field of Field list. Function code can be handled as follows: During the Designing of the screen, a function code is assigned to pushbutton. In field list, developer needs to specify OKCODE as last field. In module program it is a global field and can be evaluated in the PAI event. A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element. When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user). Module pool program to handle this particular screen is as follows: Program YVTEST7. TABLES: SFLIGHT. DATA: OKCODE (4). MODULE INPUT1 INPUT, CASE OKCODE. WHEN DISP. SELECT * FROM SFLIGHT WHERE CARRID = SFLIGHT CARRID AND CONNID = SFLIGHT CONNID. ENDSELECT.

LEAVE TO SCREEN 200. WHEN EXIT. LEAVE TO SCREEN 0. ENDCASE. ENDMODULE. INPUT1 INPUT MODULE USER_COMMAND_0200 INPUT. CASE OKCODE. WHEN BACK. LEAVE TO SCREEN 100. ENDCASE. ENDMODULE. USER_COMMAND_0200 INPUT When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen. Flow logic for screen 100 is as follows: PROCESS AFTER INPUT. MODULE INPUT. Flow logic for screen 200 PROCESS AFTER INPUT. USER_COMMAND_0200. MODULES: Modules are handled in module pool program. You need to write flow logic for screen 200 and design screen 200. In case of transaction transfer of data from program to screen is automatic i.e. you need not transfer the data from program to screen explicitly. The fields, which you define in the screen receives the data from program and displays the same. The Field Checks As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered in the database table should be valid and correct. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows: Automatic field checks Checks performed in the flow logic Checks performed in the ABAP/4 module pool program

Automatic Field Checks These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data

for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows: Required input While designing the screen, for particular screen field if you click the Req. Entry checkbox, the field becomes mandatory. When the transaction is executed if user leaves this particular field blank, the system displays error message. User cannot proceed until the user enters some data. Proper Data Format Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date, which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays the error message. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed. Valid Value for the Field In data dictionary two tables are related by Primary key-Foreign key relationship. Whenever the user enters the data, the system checks for the check table values. Also in Domain, if you have fixed values, then the system checks for these values. Automatic field checks are repeated each time the user enters the data. About at Exit Command Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly the same way as Cancel works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields, user can click the Cancel button. Same functionality can be incorporated in the user-defined transaction by using AT EXIT-COMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event. Code for AT EXITCOMMAND in flow logic and in module pool program can be written as follows: In Flow Logic Process After Input. Module exit AT EXIT-COMMAND. In module pool program. Module exit. Case okcode. When Exit. Leave to screen 0. To achieve this kind of functionality a pushbutton or menu item should be assigned a function type E. It tells the system to process this particular module before carrying out any field checks.

Flow Logic Validations Consider the case where you want user to enter only LH and SQ for sflightcarrid. In this case, you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence there is a need of additional validation. It can be done in flow logic by using following statement: Field Values Syntax PAI. Field sflight-carrid values (LH). For multiple values PAI. Field sflight-carrid values (LH SQ). Field sflight-price values (between 1000 and 2000). In this case when the user enters the value, PAI is triggered and field is checked for that particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If you have multiple Field statements in your flow logic, it is sequential execution. Consider the following case: PAI. Module assign. Field sflight-carrid values (LH SQ). In ABAP/4 Module assign. Data: carrid1 like sflight-carrid. Carrid1 = sflight-carrid. Endmodule. In this case, Sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e., field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it

executes the field statement. Field statement transfers the values to the program and is done only once. If you dont have Field statement in your flow logic, transfer of values takes place in PAI event.

Consider one more case where you have multiple field statement PAI. Field Sflight-carrid values (LH). Field Sflight-connid values (0400 0500). In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the fields are disabled for user to input. Many times if the user enters wrong value for one field, then you might want to give option to user to enter all the fields, which is not possible by using Field statement only. This functionality can be achieved by CHAIN ENDCHAIN. Syntax Chain. Field sflight-carrid value (LH). Field sflight-connid values (between 200 and 500). Endchain. Field sflight-price values (100 1000). In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid are enabled as they are grouped together in the Chain statement. The field price will be disabled for input. Usually, logically related fields are grouped together with Chain-Endchain statement. Module Pool Program Validations Checking fields ABAP/4 program includes Field statement in flow logic. Module statement in ABAP/4 module pool Program.

Syntax PAI. Field sflight-carrid module <name>. This module can be handled in the main program i.e. module pool program. In ABAP/4 program Module Check. Select single * from sflight where carrid = sflight-carrid. If sy-subrc ne 0.

Message e001. Endif. In this case, field sflight-carrid is checked in the table for its existence. Dynamically Calling the Screens About Displaying Next Screen Transaction is a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in next Screen attributes. These are static attributes of the screen. By default, if nothing is specified in the program, the system branches out to the screen number, which is specified in the attribute screen. In this case, if user selects MARA pushbutton, then fields from Mara table are displayed. When the user clicks on the MARD, then the fields from MARD table are displayed. Depending upon users selection, the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program. The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this: SET SCREEM CALL SCREEN LEAVE TO SCREEN <NUMBER> All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed. Set Screen Syntax Set screen <number>. In module pool program Case okcode. When DISP. Set screen 200. When LIST. Set screen 300. Endcase.

In this case, the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen, LEAVE SCREEN should be used along with the SET SCREEN. For Example: Case okcode.. When DISP. Set screen 200. Leave Screen. When LIST. Set screen 300. Leave Screen. Endcase. When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same. Call Screen Usually used for pop up screens. Many times, there is a need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. CALL SCREEN achieves this functionality. Syntax Call Screen 200. Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking BACK button. To call screen as pop up screen the syntax is Call screen starting at <col.no.> <line no> Ending at <col no> <line no>. In this case window will be popped as window and user can close it by using BACK button. Leave to screen To SET a new screen without processing current screen, you need to use the following two statements together:

SET SCREEN 200. LEAVE SCREEN. Or a Single statement

LEAVE TO SCREEN 200. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

REPORT ZBHMOD1 . DATA:OKCODE1 LIKE SY-UCOMM, OKCODE2 LIKE SY-UCOMM. DATA:N1(10) TYPE N,N2(10) TYPE N,RES(12) TYPE N. MODULE USER_COMMAND_1000 INPUT. CASE OKCODE1. WHEN 'NEXT'. RES = N1 + N2. SET SCREEN 1001. WHEN 'CLEA'. CLEAR:N1,N2. WHEN 'BACK'. SET SCREEN '0'. ENDCASE. ENDMODULE. " USER_COMMAND_1000 INPUT MODULE STATUS_1000 OUTPUT. * SET PF-STATUS 'xxxxxxxx'. SET TITLEBAR 'TIT1'. ENDMODULE. " STATUS_1000 OUTPUT MODULE USER_COMMAND_1001 INPUT. CASE OKCODE2. WHEN 'BACK'. SET SCREEN 1000. ENDCASE. ENDMODULE. " USER_COMMAND_1001 INPUT MODULE STATUS_1001 OUTPUT. * SET PF-STATUS 'xxxxxxxx'. SET TITLEBAR 'TIT2'.

ENDMODULE. " STATUS_1001 OUTPUT

FLOW LOGIC:

PROCESS BEFORE OUTPUT. MODULE STATUS_1000. * PROCESS AFTER INPUT. MODULE USER_COMMAND_1000.

PROCESS BEFORE OUTPUT. MODULE STATUS_1001. * PROCESS AFTER INPUT. MODULE USER_COMMAND_1001.

*********************************************************************** *** *********************************************************************** * 2)

REPORT ZBHMOD2. DATA: OKCODE1 TYPE SY-UCOMM, OKCODE2 TYPE SY-UCOMM, ENAME(10) TYPE C, DNAME(10) TYPE C. MODULE STATUS_1000 OUTPUT. * SET PF-STATUS 'xxxxxxxx'. SET TITLEBAR 'TIT1'. ENDMODULE. " STATUS_1000 OUTPUT MODULE STATUS_1001 OUTPUT. * SET PF-STATUS 'xxxxxxxx'. SET TITLEBAR 'TIT2'.

ENDMODULE. " STATUS_1001 OUTPUT MODULE USER_COMMAND_1000 INPUT. CASE OKCODE1. WHEN 'BACK'. SET SCREEN '0'. WHEN 'NEXT'. DNAME = ENAME. SET SCREEN '1001'. ENDCASE. ENDMODULE. " USER_COMMAND_1000 INPUT MODULE USER_COMMAND_1001 INPUT. CASE OKCODE2. WHEN 'BACK'. SET SCREEN '1000'. ENDCASE. ENDMODULE. " USER_COMMAND_1001 INPUT

FORM ON_CTMENU_FORM USING ZDEMO1 TYPE REF TO CL_CTMENU. CALL METHOD ZDEMO1->LOAD_GUI_STATUS EXPORTING PROGRAM = 'ZDEMO1' STATUS = 'ZDEMO1' MENU = ZDEMO1. ENDFORM. " ON_CTMENU_FORM

FLOW LOGIC:

PROCESS BEFORE OUTPUT. MODULE STATUS_1000. * PROCESS AFTER INPUT. MODULE USER_COMMAND_1000.

PROCESS BEFORE OUTPUT. MODULE STATUS_1001. *

PROCESS AFTER INPUT. MODULE USER_COMMAND_1001.

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

Every Screen has a pbo and a pai. Screen elements are the textbox, buttons, radio buttons and check boxes ..... If we want to pass data from a abap program to a screen element, we have to create a variable with the name we have given in the screen.So whatever the value is present in that variable is reflected on to the screen element. Here is an example : Using subscreens and some of the screen elements

REPORT demo_dynpro_subscreens. DATA: ok_code TYPE sy-ucomm, save_ok TYPE sy-ucomm. DATA: number1(4) TYPE n VALUE '0110', number2(4) TYPE n VALUE '0130', field(10) TYPE c, field1(10) TYPE c, field2(10) TYPE c. CALL SCREEN 100. MODULE status_100 OUTPUT. SET PF-STATUS 'SCREEN_100'. ENDMODULE. MODULE fill_0110 OUTPUT. field = 'Eingabe 1'(001). ENDMODULE. MODULE fill_0120 OUTPUT. field = field1. ENDMODULE. MODULE fill_0130 OUTPUT. field = 'Eingabe 2'(002). ENDMODULE. MODULE fill_0140 OUTPUT. field = field2.

ENDMODULE. MODULE cancel INPUT. LEAVE PROGRAM. ENDMODULE. MODULE save_ok INPUT. save_ok = ok_code. CLEAR ok_code. ENDMODULE. MODULE user_command_0110 INPUT. IF save_ok = 'OK1'. number1 = '0120'. field1 = field. CLEAR field. ENDIF. ENDMODULE. MODULE user_command_0130 INPUT. IF save_ok = 'OK2'. number2 = '0140'. field2 = field. CLEAR field. ENDIF. ENDMODULE. MODULE user_command_100 INPUT. CASE save_ok. WHEN 'SUB1'. number1 = '0110'. WHEN 'SUB2'. number1 = '0120'. CLEAR field1. WHEN 'SUB3'. number2 = '0130'. WHEN 'SUB4'. number2 = '0140'. CLEAR field2. ENDCASE. ENDMODULE. * flow logic for screen 100 PROCESS BEFORE OUTPUT. MODULE STATUS_100. CALL SUBSCREEN: AREA1 INCLUDING SY-REPID NUMBER1, AREA2 INCLUDING SY-REPID NUMBER2. PROCESS AFTER INPUT. MODULE CANCEL AT EXIT-COMMAND. MODULE SAVE_OK. CALL SUBSCREEN: AREA1, AREA2. MODULE USER_COMMAND_100. * flow logic for screen 110

PROCESS BEFORE OUTPUT. MODULE FILL_0110. PROCESS AFTER INPUT. MODULE USER_COMMAND_0110. * flow logic for screen 120 PROCESS BEFORE OUTPUT. MODULE FILL_0120. PROCESS AFTER INPUT. * flow logic for screen 130 PROCESS BEFORE OUTPUT. MODULE FILL_0130. PROCESS AFTER INPUT. MODULE USER_COMMAND_0130. * flow logic for screen 140 PROCESS BEFORE OUTPUT. MODULE FILL_0140. PROCESS AFTER INPUT.