Dialogue program

Former Member · ‎03-25-2008

hi all,

I am new in ABAP.

can anyone explain me what is dialogue program ?

by ,

raghul

Former Member · ‎03-25-2008

Hi raghul kanna,

Try those link Out

http://www.sapdevelopment.co.uk/dialog/dialoghome.htm

http://help.sap.com/saphelp_webas630/helpdata/en/9f/db9cdc35c111d1829f0000e829fbfe/content.htm

http://www.sap-img.com/

http://help.sap.com/saphelp_46c/helpdata/en/08/bef2dadb5311d1ad10080009b0fb56/content.htm

http://www.sapgenie.com/links/abap.htm

http://help.sap.com/saphelp_nw04/helpdata/en/c9/5472fc787f11d194c90000e8353423/frameset.htm

http://www.sapdevelopment.co.uk/dialog/dialoghome.htm

http://help.sap.com

http://www.sapgenie.com/abap/example_code.htm

http://help.sap.com/saphelp_47x200/helpdata/en/52/670ba2439b11d1896f0000e8322d00/frameset.htm

http://www.allsaplinks.com/dialog_programming.html

http://www.sapbrain.com/TUTORIALS/default.html

http://www.sappoint.com/abap/spmp.pdf

Chk out below intro will get a clear idea abt DIALOG prog. it has simple program with step by step procedure.

MODULE POOL PROGRAMMING:

-

These are type M programs in SAP.

MPP programs should start with the naming convention SAPMZ or SAPMY.

MPP programs are used to create and assign a user-defined screen to the Transaction Code.

Each screen created in MPP is assigned a screen number. This screen number is assigned to a Tcode.

MPP programs cannot be executed directly. Tcodes are used to execute these programs.

EVENTS IN MPP:

-

PROCESS BEFORE OUTPUT (PBO)

PROCESS AFTER INPUT (PAI)

PROCESS ON VALUE REQUEST - To provide F4 functionality to MPP program screen i/p fields.

PROCESS ON HELP REQUEST - To provide F1 functionality to MPP program screen components.

Navigations to create a simple MPP program:

-

SE80 -> Select Program from drop-down list -> Specify program name starting with SAPMZ or SAPMY -> Press Enter -> Click on Yes to create object -> Create Top Include File by clicking on Continue icon in pop-up screens -> Save under a package -> Assign a request number -> MPP program with specified name is created with Top include File.

To create screen, Right click on program name -> Select Create -> Screen -> Opens Screen Description page -> Enter short description for screen -> Select screen type as NORMAL -> Click on LAYOUT pushbutton from application toolbar -> Opens Screen Painter -> Drag and drop two input fields from toolbar -> Likewise, create two pushbuttons -> Double click on each component -> Opens Attributes box -> Specify attributes for each screen component -> For pushbutton, specify FCT code -> Save the screen -> Click on Flowlogic pushbutton from application toolbar -> Opens Flow logic editor to create event functionalities for screen components -> Decomment PAI module -> Double click on PAI module name -> Click on Yes to create PAI module object -> Opens PAI module -> Specify the following code within module-endmodule statements:

CASE SY-UCOMM.

WHEN 'DISPLAY'.

LEAVE TO LIST-PROCESSING.

WRITE 😕 IO1, IO2.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

-> Save.

Now double click on 'Includes' Folder (TOP INCLUDE FILE) -> Declare variables for input fields as follows:

DATA : IO1(10), IO2(10).

Save -> Activate.

Now To create Transaction Code, right click on Main Program Name -> Create -> Transaction -> Opens an interface -> Enter Tcode name starting with Z or Y -> Enter short description -> Continue -> Opens interface -> Enter Main program name and Screen number to be called first -> Save under a package -> Assign a request number.

Activate all the objects of MPP program by right clicking on Main program Name -> Click on Activate -> Raises 'Objects Activated' message.

To execute the MPP program, specify Tcode name in the Command Prompt area -> Press Enter.

MPP SCREEN VALIDATIONS:

-

Eg. code to make field validations in MPP program:

-

Using screen painter, design a screen consisting of four input fields for client, username, password and language as we have in login screen of SAP.

Assign the first two input fields to one group called GR1, the third input field to a group GR2.

Create two pushbuttons and assign FCT codes.

In the TOP INCLUDE FILE, declare following variables:

PROGRAM SAPMYSCREENVALID.

DATA : IO1(3), IO2(8), IO3(8), IO4(2).

DATA A TYPE I.

Save -> Activate.

In Flow logic editor, decomment PAI MODULE, double click on module name, and inside the module, write the following code:

module USER_COMMAND_0200 input.

case sy-ucomm.

WHEN 'LOGIN'.

CALL TRANSACTION 'SE38'.

WHEN 'EXIT'.

LEAVE PROGRAM.

ENDCASE.

endmodule. " USER_COMMAND_0200 INPUT

Save -> Activate.

In PBO module, write the following code to assign default input field attributes:

module STATUS_0200 output.

SET PF-STATUS 'xxxxxxxx'.

SET TITLEBAR 'xxx'.

IF A = 0.

MESSAGE S010(ZMSG).

LOOP AT SCREEN.

IF SCREEN-GROUP1 = 'GR1'.

SCREEN-REQUIRED = '1'.

ENDIF.

IF SCREEN-GROUP1 = 'GR2'.

SCREEN-INVISIBLE = '1'.

ENDIF.

MODIFY SCREEN.

ENDLOOP.

A = 1.

ENDIF.

endmodule. " STATUS_0200 OUTPUT

Save -> Activate.

Create a Transaction Code -> Execute the program.

ADDING USER-DEFIND MENUS TO THE INTERACTIVE REPORTS:

-

Menu Painter is a tool used to create user-defined menus, application toolbar and function keys.

SET PF-STATUS '<menu_name>' is the syntax used in reports to access Menu Painter directly to create user-defined menus.

A menu bar consists of set of menus.

Menu contains set of menu items.

Each menu item may have its own sub menu items.

Another way of accessing Menu Painter is using SE41 Tcode.

Eg. code:

-

WRITE 😕 'SELECT ONE FROM THE MENU'.

SET PF-STATUS 'MYMENU'.

AT USER-COMMAND.

CASE SY-UCOMM.

WHEN 'SHABANA1'.

MESSAGE S000(ZSHABMSG).

WHEN 'SHABANA2'.

MESSAGE S001(ZSHABMSG).

WHEN 'SHABANA3'.

LEAVE PROGRAM.

WHEN 'SUBMENU11'.

CALL TRANSACTION 'SE38'.

WHEN 'SUBMENU12'.

CALL TRANSACTION 'SE37'.

ENDCASE.

-> Save -> Activate -> Execute.

Dialog prog is used to create screens with which the user acn interact.

We can create any number of screens for a program and we can call these screens very easily.

Hope this helps a bit ....

Reward if useful

Cheers

Kripa Rangachari.

ak_upadhyay · ‎03-25-2008

Hi raghul,

Check these links.....

http://sap.mis.cmich.edu/sap-abap/abap09/index.htm

http://help.sap.com/saphelp_nw04/helpdata/en/9f/db9cdc35c111d1829f0000e829fbfe/content.htm

Need Reward points if useful....

Regards

AK

Former Member · ‎03-25-2008

HI

The R/3 system is multi user system and many users access the same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record, and second user is trying to delete the same record. If the second user is successful in deleting the record then the first user will face problem for modifying the record that is already deleted. The avoid such situation, R/3 system has provided Logical Unit of Work, which is defined as a locking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e. foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as:

• Database transaction known as LUW. It can be defined as a period in which operation requested must be performed as a unit, i.e. all or nothing operation. At the end of LUW, either of the database changes are committed or rolled back.

• Update transaction or SAP LUW. One SAP LUW can have several databases LUW. So a set of a database is either committed or rolled back. The special ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.

• ABAP/4 transaction. Is made up of a set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes.

R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released.

To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table. SAP has provided one and only one way to update the database table, i.e. transaction. Though you can update database table by using open SQL statement through program, SAP usually doesn’t recommend this kind of updating. Many standard transactions are available to update standard table but if the need arises, the developer should be able to develop new transaction, which allows the updating of database tables. This can be achieved by using various components of screen painter.

Following are the few concepts and steps for creating entire new transaction.

DYNPRO concept

A dynpro refers to the screen + flow logic.

When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program.

• A module program is usual ABAP/4 program that consist of modules and data declaration.

• ABAP/4 is an event driven language. In module pool program too, events get triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic.

• Screen is the important component of dynpro and can be created, designed by screen painter.

Screen Painter

A screen painter can be started by

Development workbench  Screen Painter

Or

SE51 transaction code.

Using Screen Painter

The process of creating a dynpro includes the creation and definition of all the needed screen components.

The steps involved in creating the dynpro are as follows:

• Create screen and attributes by using screen attribute screen.

• Select and place the needed fields within the screen by using dict/program fields.

• Establish the field attributes to which the screen belongs by using field list.

• Define the flow logic respect to the transaction to which it belongs by using flow logic.

Creating a new Screen

Steps involved are as follows:

• Enter the name of program and number of the screen

• Click on Create

• On “screen attribute” screen enter short description

• Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen.

• Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.

Designing of Screen

Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.

From screen attribute screen

By pressing full screen editor pushbutton

Or

From initial screen of screen painter.

There are two modes available with full screen editor.

• Graphical mode. The graphical mode works similarly to typical window application.

• Alphanumeric mode (rarely used).

Elements of screen

• Text – Standard text or field labels.

• Entry - display field.

• Radiobutton – All radiobutton must be associated with one group.

• Checkbox – Normally used for YES/NO operations.

• Pushbutton – Used for activating particular function.

• Boxes – grouping together many screen elements.

• Subscreens – This is a screen area in which you can display another screen.

• Table controls – This area of screen is similar to table but should be treated as a loop.

• Status - Display output fields containing icon.

All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.

Selecting Screen Fields

Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows:

Click the pushbutton Dict/program fields on the full screen editor

Or

Goto  dict/prog fields.

• Enter table name.

• Click Get from dictionary.

• Select fields.

• Click copy pushbutton.

• Position the cursor where you want those fields to be placed.

To adjust various screen elements, you can use drag and drop facility for screen elements.

Attributes of Screen Elements

The entire element of a screen has some attributes, which determines their behavior.

• General – These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen.

• Dictionary – These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key.

• Program.

• Display – Behavior of the element with respect to their display feature.

Attribute dialog box can be displayed by

• Clicking on the ATTRIBUTE push button on the application tool bar.

• Double clicking on the element.

Field List

This list displays a list of all screen elements together with their screen attributes. One important element of Field list is OKCODE. Any pushbutton is associated with function code as in menu item in menu painter. When the user clicks the pushbutton this code is stored in OKCODE. This OKCODE is created by system without a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible, hence user needs to give the name OKCODE. It is not mandatory to give the name OKCODE; developer can give any name to this field.

Screen Flow Logic

You can go to this screen either by

Initial screen of Screen painter  Flow logic

Or

From Screen attribute screen  Flow logic

When transaction is executed, the screen is displayed, user enters few fields, selects few functions. Later the screen is processed and processing of screen is done by flow logic. The events that are associated with screen are as follows:

• Process before Output (PBO)

• Process after input (PAI)

• Process on value request (POV)

• Process on help request (POH)

The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO

PBO event

This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields.

PAI event

This event is responsible for processing of screen after the user enters the data and clicks the pushbutton. The processing of screen can include displaying another screen, or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation.

POV event

Process on value request is triggered when the user clicks F4 key. You can handle this event when the user presses F4 key by writing code for the same in module pool program. Normally when the user presses F4, list of possible values is displayed. The standard list produced by system is adequate for applications you develop yourself. However, you can also have the option of setting up your own documentation and lists of possible values that are more detailed.

POH event

Normally when the user places the cursor on the field and presses F1 function key, the system displays its own Help for that particular field. You can add your own functionality to the Help button by writing code for the same in the POH event.

Module Pool Programming

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 user’s 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 EXIT-COMMAND 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 sflight-carrid. 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 don’t 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.

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.

If sy-subrc ne 0.

Message e001.

Endif.

In this case, field sflight-carrid is checked in the table for its existence.

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.

Former Member · ‎03-25-2008

Hi

transaction is nothing but module pool programming or dialog programming.

the main task of the transaction is to update the database.the database is not updated until the transaction is completed.

module pool program<----~~screen flow logic<~~--screen

when the transaction is executed screen places a call to flow logic and flow logic make a call to main program that is module pool program.

se38 for module pool program

se51 screen painter to design screens

se93 to create our own transaction code

the processing of screen is done by flow logic.it ontains the following events.

PBO:it is triggered before the screen is displayed.

PAI:this is triggered after the screen is displayed.

POV:it is for f4 help.

POV:it is to f1 help.

Former Member · ‎03-25-2008

Hi,

Dialog-driven programs, or any program started using a transaction code, are known as SAP transactions, or just transactions. The term "transaction" is used in several different contexts in the IT world. In OLTP (Online Transaction Processing), where several users are working in one system in dialog mode, the term "transaction" stands for a user request. In conjunction with database updates, it means a change in state in the database.

Programs with type M can only be started using a transaction code, in which an initial screen is defined. Programs with type 1 can be started either using a transaction code, or by entering the program name in one of the transactions SE38 or SA38. Screens call dialog modules in the associated ABAP program from their flow logic. Type M programs serve principally as containers for dialog modules, and are therefore known as module pools. Type 1 programs, or function modules can also switch to dialog mode by calling screens using the CALL SCREEN statement. The program code of the corresponding executable program or function pool must then contain the corresponding dialog modules.

Programs that are partially or wholly dialog-driven cannot be executed in the background. They are therefore sometimes referred to as dialog programs.

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. As well as using a transaction code, 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. These screens consist of a screen mask and its flow logic. Since the flow logic influences the program flow, screens are sometimes referred to as "dynamic programs". You create screens using the Screen Painter in the ABAP Workbench. Each screen belongs to an ABAP program.

The screen has a layout that determines the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. The flow logic consists of two parts:

Process Before Output (PBO). This defines the processing that takes place before the screen is displayed.

Process After Input (PAI). This defines the processing that takes place after the user has chosen a function on the screen.

All of the screens that you call within an ABAP program must belong to that program. The screens belonging to a program are numbered. For each screen, the system stores the number of the screen which is normally displayed next. This screen 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.

GUI status

Each screen has a GUI status. This controls the menu bars, standard toolbar, and application toolbar, with which the user can choose functions in the application. Like screens, GUI statuses are independent components of an ABAP program. 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.

Dialog modules are split into PBO modules and PAI modules. Dialog modules called in the PBO event are used to prepare the screen, for example by setting context-specific field contents or by suppressing fields from the display that are not needed. Dialog modules called in the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.

Passing Data Between ABAP Programs and Screens

How are fields from ABAP programs displayed on the screen? And how is user input on the screen passed back to the ABAP program? Unlike in list programming, you cannot write field data to the screen using the WRITE statement. Instead, the system transfers the data by comparing the names of screen fields with the names of the ABAP fields in the program. If it finds a pair of matching names, the data is transferred between the screen and the ABAP program. This happens immediately before and immediately after displaying the screen.

Field Attributes

For all screen fields of a dialog screen, field attributes are defined in the Screen Painter. If a field name in the screen corresponds to the name of an ABAP Dictionary field, the system automatically establishes a reference between these two fields. Thus, a large number of field attributes for the screen are automatically copied from the ABAP Dictionary. The field attributes together with data element and domain of the assigned Dictionary field form the basis for the standard functions the screen executes in a dialog (automatic format check for screen fields, automatic value range check, online help, and so on).

Error Dialogs

Another task of the screen processor is to conduct error dialogs. Checking the input data is carried out either automatically using check tables of the ABAP Dictionary or by the ABAP program itself. The screen processor includes the error message into the received screen and returns the screen to the user. The message may be context-sensitive, that is, the system replaces placeholders in the message text with current field contents. In addition, only fields whose contents is related to the error and for which a correction may solve the error can accept input. See also Messages on Screens.

Data Consistency

To keep data consistent within complex applications, ABAP offers techniques for optimizing database updates that operate independent of the underlying database and correspond to the special requests of dialog programming. See also Programming Database Updates.

Module pools are directly created using the ABAP Editor and are introduced with the PROGRAM statement. With the exception of reporting event blocks and function modules, module pools can contain all processing blocks supported in ABAP and as many local classes as required. While they are executed, all events of the ABAP runtime environment may be triggered.

The most important technical attribute of a module pool is that it can only be controlled using screen flow logic. You must start them using a transaction code, which is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the initial screen can be a selection screen).

When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:

· return control to the screen, after which the processing passes to a subsequent screen. Each screen has a following screen, set either statically or dynamically. Screens and their subsequent screens are components of freely definable screen sequences.

· call other screen sequences, selection screens or lists, from which further processing blocks in the ABAP program are started.

· call other processing blocks itself, either internally or externally.

· call other application programs using CALL TRANSACTION or SUBMIT.

It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow of screen sequences.

with regards,

sowjanyagosala