The document summarizes topics that will be covered in an ABAP workshop on dialog programming. The topics include: program types in ABAP; dialog programs and DYNPRO screens; program flow and events; differences between DYNPRO and ABAP data elements; FIELD and CHAIN commands; TAB controls; fields, data elements, and domains; input and field help; menu controls; and the title bar. Hands-on practice sessions will provide opportunities to work through examples and practice the concepts discussed.

1. ABAP Workshop
2009 - Part1

2. Topics
• Program Types
• Dialog Program and DYNPROs
• Program Flow and Flow Events
• DYNPRO data elements Vs. ABAP data elements
• FIELD Command and Conditional Module Calls
• CHAIN Command
• TAB controls
• Field, Data Element and Domains
• Input Help (List of Values) –demo/coding
• Field Help (F1 Help) –demo/coding
• Understanding Menu Bar, Application Toolbar and Function keys
• Menu Control and Function Keys
• Context Menu
• Title Bar
• Demo
• Hands-on Practice
2

3. Program Types
Program type First statement in Processing blocks Can this have or
program (After the supported support its own
include statements are DYNPROS
resolved)
Executable (1) REPORT (or All - except function Yes
PROGRAM) modules
Class pool (K) CLASS-POOL Methods only No
Function group (or FUNCTION-POOL All except event Yes
function pool) (F) blocks for reporting
events
Interface pool (J) INTERFACE-POOL None No
Module pool (M) PROGRAM Event block LOAD-OF- Yes
PROGRAM,
subroutines, methods
Subroutine pool (S) PROGRAM Event block LOAD-OF- No
PROGRAM,
subroutines, methods
Type group or Type TYPE-POOL None No
pool (T)
Includes (I) N/A All except event blocks No 3
for reporting events

4. Dialog Programs and DYNPRO
• DYNPRO is a basic component (screen and flow logic) of Dialog programs
• DYNPRO (DYNamic PROgram’s) are also called Transactions
• Sometimes the terms DYNPRO and Dialog Program are used
interchangingly
• The procedure for creating dialog programs is different to that for reports
• A Dialog Program consists of one or more screens
• Screen consists of a Layout (buttons, frames, labels, edit fields etc) and its
Flow Logic – code to handle user events
• Collectively, a screen, its layout and flow logic is called a DYNPRO
• When a dialog program is run, screens are the objects called, not programs
or subroutines
• In Dialog programs the system displays a screen for the user to enter or
request information and it responds to user input or request by 1) Branching
to next screen 2) Displaying an output 3) Running a report 4) Updating the
database
4

5. Passing Control Between Layers
•
Database Layer
5

6. Explain Dialog Programming
• In Dialog programming, control of the program is continually passed
backwards and forwards between the presentation layer (SAP GUI)
and application layer (application Server)
• When we start the screen is ready for input (presentation layer is
active and application layer is not active)
• Once the user has entered data on the screen, program control
passes back to the application layer
• Now, the presentation layer is inactive (the SAP GUI is still visible,
but it cannot accept user input)
• The SAP GUI does not become active again until the application
program has called a new screen and sent it to the presentation
server.
• Basically, in Dialog programming we divide programs into dialog
steps, with each of these steps comprising of the programming logic
between two successive screens.
6

7. Flow Events
• PROCESS BEFORE OUTPUT (PBO)
– Fires before a screen is displayed. Can be used to
initialize fields
• PROCESS AFTER INPUT (PAI)
– Fires on an user action (menu/buttons/function-keys)
• PROCESS ON VALUE REQUEST (POV)
– Fires when a set of possible values is requested (F4)
• PROCESS ON HELP REQUEST (POH)
– Fires when general help is requested (F1)
7

8. Program Flow
8

9. Dialog Processor
• Dialog processor controls the display of the
screen and execution of the ABAP program. The
Dialog processor processes screen after the
screen, thereby triggering the appropriate flow
events of each screen
• After each screen is displayed, it waits for the
appropriate user input and then executes the
flow logic
• The controls passes from screen flow logic to
ABAP code and back along with the values of
the program elements
9

10. Program Flow Design
10

11. Dynpro (screen) Logic
11

12. ABAP code (include file)
12

13. Function Definition
13

14. Dynpro data elements Vs. ABAP data
elements and Data Transport
14

15. FIELD Command and Conditional
Module Calls
• FIELD NAME
– Value Transported
• FIELD NAME MODULE ChangesDetectModule
on REQUEST.
– Value changed
• FIELD NAME MODULE ChangesDetectModule
on INPUT.
– Non blank value
• FIELD NAME MODULE ChangesDetectModule.
– Custom check for format, etc
15

16. CHAIN Command
CHAIN
FIELD: Name1, Name2
MODULE ChangesDetectModule on
CHAIN-REQUEST. "Value changed?
ENDCHAIN.
16

17. TAB controls
1) Scrolling at application server
Only one subscreen area with two subscreens. (see
program 5)
2) Scrolling at Local SAPGUI
Two subscreens areas/Two subscreens. (see
program 5A)
17

18. Data Element & Domains of Fields
• Domain depicts the technical attributes of a
Domain field
– its data type, field length, no. of decimal places,
appearance on the screen
• Data Element denotes the semantic attributes
– short description, label names for a field that
Data Element Data Element uses this.
• Data Elements are directly attached to the
Fields
• Data Element has an underlying Domain
(optional)
Field Field
• Domains are not directly attached to the fields
• A single Domain can be under many Data
Elements.
• Within Domain - value range of a field can be
described. Whereas within the Data Element
parameter id and search help for a particular
field can be assigned.
18

19. Input Help (List of Values)
1) Fixed Value (DOMAIN LEVEL) - Hard coded list in Data Dictionary
– Using domain (of the Data Element) of the field
2) Check Tables (FIELD LEVEL)
– Specifying the Check table on the Field level
3) Assigning the "Search Help" repository object (DATA ELEMENT
LEVEL)
– Create a "Search Help" Object [as an independent step] and then
assign it to data element of the field.
4) Assigning the "Search Help" repository object (SCREEN ELEMENT
LEVEL)
– Create a "Search Help" Object [as an independent step] and then
assign it to dynpro screen element in screen painter.
5) Self defined Dropdown List Boxes (SCREEN ELEMENT LEVEL)
– Most flexible but requires simple SQL to populate the list.
19

20. (1) Fixed Value (Domain Level)
Domain of the Data Element
Data Element of a Field
20

21. (2) Check Tables (Field Level)
Click on the
Foreign Keys Icon
21

22. (3 & 4) Search Help (Object)
Create
‘Srch Helps’
Object(s)
And attach to
the Data Element
Or attach
directly to
the Dynpro
field
LPos:
Field Order
SPos:
Search Order
22

23. Search Help Field Order
LPos: Field Order
SPos: Search Order
23

24. (5) Self defined Dropdown
MODULE create_dropdown_box INPUT.
dynpro_utilities1=>value_help( ).
ENDMODULE.
… DATA city_list TYPE STANDARD TABLE OF city_line.
SELECT distinct ZCITY ZCITYDESCR from ZCITY_TBL into corresponding fields of
table city_list where ZCITY like '%O%' order by ZCITY. Select Listbox
CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST' or
EXPORTING
retfield = 'ZCITY' Listbox
value_org = 'S'
TABLES with key
value_tab = city_list
EXCEPTIONS
…
24

25. Field Help (F1 Help)
1) Documentation - (only one) can be attached to the
Data Element of the Field needing help documentation.
2) Additional Documentation - (multiple can be attached
to the Data Element of the Field needing help ‘additional
documentation’), Dynpro screen field can call just one -
the one relevant to its context using ‘PROCESS ON HELP-
REQUEST’ Flow Logic.
• PROCESS ON HELP-REQUEST. (assuming 0001 and 0002 are ‘additional
documentation’ help is entered/exists)
– FIELD ZBC400_S_HDR_CURR-CITYTO WITH '0001'.
» Or
– FIELD ZBC400_S_HDR_CURR-CITYTO WITH '0002'. etc
3) Uses the Process on Help Request (POH) event.
25

26. Field Help - Documentation
Click here in Change Mode
to modify (display mode shown)
Data Element
26

27. Field Help - Additional Documentation
Data Element
Click here.
Add as many
as you wish
Call any one
Additional help
PROCESS ON HELP-REQUEST.
FIELD field1 WITH '0001'.
Or
FIELD field1 WITH '0002'.
27

28. Menu Control
• Create GUI Status object (Interface Component)
• Command: SET PF-STATUS 'ZTEST1'.
• Each screen can have same or different menu
(set this in PROCESS BEFORE OUTPUT)
• Various menus are: Menu Bar, Standard Tool
Bar, Application Toolbar
• Function Keys are generally related to Menu
• Context Menu is inherited from Function Keys,so
is same for all fields on screen by default, but…
• Context Menu – each field can be made different
(program 10 and 10A)
28

29. Bars in the SAP GUI
Menu Bar
Standard Tool Bar
Title Bar
Related Item
Application Toolbar
Function Keys F1, F2…
29

30. Menu Painter
30

31. Menu Painter
Screen 1/2
•
Screen 2/2
GUI Status -> ZTEST1
Note: Standard tool bar is
shown at the top of the
Function Keys Setup!
31

32. Function Keys
The following Function Keys are reserved and are
handled at run time
• F1 (field help),
• F4 (Input Help)
• F10 (positions the cursor in the (top) menu bar)
Double Click automatically gets the functionality of
whatever F2 is setup to do – applies to all fields
by default. (see subsequent slides)
F2 or Double Click can be setup so that different
logic can be mapped to individual fields (see
program 10C & subsequent slides)
32

33. Double Click (all fields)
• When we map a/any functionality to F2, the same
functionality is automatically executed when we
Double Click the object.
• Example: If we set the F2 to say “BACK1” (also the
Function code), the F2 as well as the Double Click get
the functionality from the usual ABAP CASE statement
logic.
….
CASE ok_code.
When 'BACK' or
'BACK1'.
SET SCREEN
100.
….
33

34. Double Click (individual fields)
• The Function Code for F2 is set to CS (CURSOR-
SELECTION) and TYPE to S (System Function). In PAI
use the FIELD statement to call a module.
• …
PROCESS AFTER INPUT.
FIELD Field1 MODULE C1 AT CURSOR-SELECTION.
FIELD Field2 MODULE C2 AT CURSOR-SELECTION.
Actual module defn:
MODULE C1 INPUT.
CALL TRANSACTION
'SE13'.
ENDMODULE.
34

35. Context Menu
The Context Menu for a SCREEN is
‘automatically’ defaulted from the
‘function keys’ MENU setup done using
menu designer – i.e., GUI STATUS
The Context Menu for individual fields is
done using the ON_CTMENU_ field as
explained in the subsequent slide.
35

36. Context Menu (of field)
Using the ON_CTMENU_ field of
screen Elements
FORM on_ctmenu_my_input2 USING
l_menu TYPE REF TO cl_ctmenu.
CALL METHOD l_menu->add_function
EXPORTING fcode = 'MY_CONTEXT_MENU7’
text = 'My Context Menu 7'.
…
CASE save_ok.
…
WHEN 'MY_CONTEXT_MENU7'.
CALL TRANSACTION 'SE92'.
…
ENDCASE.
36

37. Title Bar
• THE GUI TITLE is Interface Component
• SET TITLEBAR title. >> Command
Create Here
Use/Call Here
37

38. Upcoming Topics
• Character Sets/Unicode Format [UTF-8,etc]
• Data Clusters
• File Access
• Authorization Checks
• Lock Concept and Enqueue
38