303 Exercise 17: Creating an Interface
Exercise Duration: 40 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
• Implement the GUI title and GUI status for the screens of your program
Business Example
The title and status are to be implemented for the screens (list and screen) of your program ZBC400_##_DYNPRO_1.
System Data
System: Will be assigned Client: Will be assigned User ID: Will be assigned Password: Will be assigned
Set up instructions: No special instructions when using a standard training
system
Task 1:
Implementing the GUI status (and title) for the list
1. Extend your program ZBC400_##_DYNPRO_1 or copy the template SAPBC400UDS_DYNPRO_3 to the new name ZBC400_##_DYNPRO_4 for further processing.
2. Create the status (type: Dialog Status) using forward navigation:
Use the appropriate processing block of your program for assigning the status to the list. Implement the corresponding assignment and create the status using forward navigation.
The status you are creating must correspond to the standard list status. Hence, load this to your status as a template. Change the name of the first menu from List to Bookings.
3. Add the function code SAVE. Users should be able to trigger this by choosing the Save pushbutton in the standard toolbar. Users should also be able to choose Save from an item in the Bookings menu. In this status, however, the function code should be inactive.
Activate the status and the program.
4. Optional: GUI title for the list
Continued on next page
Define and set a title for the basic list using forward navigation.
Task 2:
Implementing the GUI status (and title) for the screen
1. Create the status for your screen (type: Dialog Status) using forward navigation:
Use the appropriate part of your program for assigning the status to the screen. Implement the corresponding assignment and create the status using forward navigation.
2. Reference to the previously create list status. Activate the function codes
BACK and SAVE in the current status
3. Optional: GUI title for the screen
Define and set a title to the screen using forward navigation.
Solution 17: Creating an Interface
Task 1:
Implementing the GUI status (and title) for the list
1. Extend your program ZBC400_##_DYNPRO_1 or copy the template SAPBC400UDS_DYNPRO_3 to the new name ZBC400_##_DYNPRO_4 for further processing.
a) Carry out this step as usual.
2. Create the status (type: Dialog Status) using forward navigation:
Use the appropriate processing block of your program for assigning the status to the list. Implement the corresponding assignment and create the status using forward navigation.
The status you are creating must correspond to the standard list status. Hence, load this to your status as a template. Change the name of the first menu from List to Bookings.
a) In the program source code, add the SET PF-STATUS ’LIST’.
statement to the START-OF-SELECTION event.
Caution: Text between the two apostrophes must be in upper
case.
b) Double-click the status name in the SET PF-STATUS ’LIST’.
statement.
c) The system displays a dialog box containing the words “The GUI
interface status ‘LIST’ does not exist. Do you want to create it?” Choose Yes to confirm.
d) Enter the short text.
e) Choose the status type Dialog status.
f) In the Menu Painter, choose the menu Extras → Adjust Template to load the standard list status as a template.
g) Change the List name for the first menu to Bookings and confirm this in the dialog box that appears.
3. Add the function code SAVE. Users should be able to trigger this by choosing the Save pushbutton in the standard toolbar. Users should also be able to choose Save from an item in the Bookings menu. In this status, however, the function code should be inactive.
Continued on next page
Activate the status and the program.
a) In the standard toolbar, enter the function code SAVE above the Save
icon and choose Enter.
b) Double-click to open the Bookings menu, enter SAVE as a function code, and assign the text “Save bookings”.
c) Choose Active <-> Inactive to deactivate SAVE for this status. d) Activate the whole status and the program.
4. Optional: GUI title for the list
Define and set a title for the basic list using forward navigation.
a) In the START-OF-SELECTION processing block, add the SET TITLEBAR ’LIST’. statement.
b) Create the title using forward navigation and enter the title text in the dialog box.
c) Activate your program and the interface.
Task 2:
Implementing the GUI status (and title) for the screen
1. Create the status for your screen (type: Dialog Status) using forward navigation:
Use the appropriate part of your program for assigning the status to the screen. Implement the corresponding assignment and create the status using forward navigation.
a) Navigate to the change mode of screen 100. In the PBO block of the flow logic, add the statement MODULE STATUS_0100. .
b) Create the module by means of forward navigation: double-click on itsname; choose Yes to confirm the settings in the dialog box. In the next dialog box, choose Main Program and add the following source code (or uncomment it):
SET PF-STATUS ’DYNPRO’.
c) Create the status using forward navigation. (Double-click the status name ’DYNPRO’)
Choose Yes to confirm the dialog box that appears.
In the next dialog box that appears, enter a short text and choose Dialog
Status as the status type.
Continued on next page
2. Reference to the previously create list status. Activate the function codes
BACK and SAVE in the current status
a) Click on the reference icon (or F4 button) for the menu bar. Create the reference to the existing menu bar by double-clicking.
b) Click on the reference icon (or F4 button) for the function keys.
Create the reference to the existing function key assignment by
double-clicking.
c) Activate the two functions SAVE and BACK by placing the cursor on the function code in the menu or on the function key assignment and choosing the Active <-> Inactive pushbutton.
d) Activate the status, the screen, and your program.
3. Optional: GUI title for the screen
Define and set a title to the screen using forward navigation.
a) In module STATUS_0100, add the SET TITLEBAR ’DYNPRO’.
statement
b) Create the title using forward navigation and enter the title text in the dialog box.
c) Activate your program and the interface.
Result
Source code extract SAPBC400UDS_DYNPRO_4:
REPORT sapbc400uds_dynpro_4.
...
START-OF-SELECTION.
SET PF-STATUS ’LIST’.
SET TITLEBAR ’LIST’. "optional
SELECT carrid connid fldate bookid
FROM sbook
INTO CORRESPONDING FIELDS OF wa_sbook
WHERE agencynum = pa_anum.
...
AT LINE-SELECTION.
...
Continued on next page
*&--------------------------------------------------------------*
*& Module STATUS_0100 OUTPUT *
*&--------------------------------------------------------------*
* text *
*---------------------------------------------------------------* MODULE STATUS_0100 OUTPUT.
SET PF-STATUS ’DYNPRO’.
SET TITLEBAR ’DYNPRO’. "optional
ENDMODULE. " STATUS_0100 OUTPUT
*&--------------------------------------------------------------*
*& Module CLEAR_OK_CODE OUTPUT *
*&--------------------------------------------------------------*
*& text *
*---------------------------------------------------------------* MODULE clear_ok_code OUTPUT.
CLEAR ok_code.
ENDMODULE. " CLEAR_OK_CODE OUTPUT
*&--------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT *
*&--------------------------------------------------------------*
*& text *
*&--------------------------------------------------------------* MODULE user_command_0100 INPUT.
CASE ok_code.
WHEN ’BACK’.
SET SCREEN 0. WHEN ’SAVE’.
MOVE-CORRESPONDING sdyn_book TO wa_sbook.
MESSAGE i060(bc400). SET SCREEN 0.
ENDCASE.
ENDMODULE. " USER_COMMAND_0100 INPUT
Flow logic for screen 100:
PROCESS BEFORE OUTPUT.
MODULE status_0100.
MODULE clear_ok_code.
Continued on next page
PROCESS AFTER INPUT.
MODULE user_command_0100.
Lesson Summary
You should now be able to:
• Implement a GUI title
• Implement a GUI status (menu bar, symbol toolbar and application toolbar)
for the list and screen
• Maintain the function key assignment of the screen
Unit Summary
You should now be able to:
• Describe the attributes and benefits of ABAP lists
• Implement list and column headers
• Implement multi-level lists
• Implement interactive lists
• List the properties and benefits of selection screens
• Implement the options for restricting selections on the selection screen
• Implement the input and authorization check with an error dialog using the selection screen
• List attributes and benefits of screens
• Implement a simple screen with input and output fields as well as pushbuttons and call it from your program
• Explain and implement the program-internal processing for screen calls
• Implement a GUI title
• Implement a GUI status (menu bar, symbol toolbar and application toolbar)
for the list and screen
• Maintain the function key assignment of the screen
Related Information
... Refer to the article “Screens” in the online documentation and to the keyword documentation for the relevant ABAP statement.
Unit 10
313 Reuse Components
See the introductory instructors’ notes in the lessons
Unit Overview
Refer to the lesson objectives for an overview of this unit.
Unit Objectives
After completing this unit, you will be able to:
• Search for function modules
• Acquire information on the functionality and use of function modules
• Call a function module in your program
• Execute the basic steps in object-oriented ABAP programming (instantiation and method calls) to use the classes and methods shipped in the SAP standard system.
• Use the SAP Grid Control (ALV List Viewer) to display an internal table on a screen
• Search for suitable BAPIs
• Call BAPIs in your program
Unit Contents
Lesson: Working with Function Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
Exercise 18: Using Function Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355
Lesson: Working with Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .361
Procedure: Displaying an Internal Table in ALV Grid Control on a
Screen . . . ... ... .. ... ... ... .. ... ... ... .. ... ... .. ... ... ... .. ... ... ... .. ... ... ..370
Exercise 19: Using Methods ... ... .. ... ... .. ... ... ... .. ... ... ... .. ... ... ..375
Lesson: Working with BAPIs . ... ... ... .. ... ... .. ... ... ... .. ... ... ... .. ... ... ..380
Lesson:
314
Working with Function Modules
Lesson Duration: 80 Minutes
Lesson Overview
In this lesson, you will learn how to search for and use function modules. As an example, you will call a function module for the encapsulation of a standard dialog and one for a database change in your program.
After completing this lesson, you will be able to:
• Search for function modules
• Acquire information on the functionality and use of function modules
• Call a function module in your program
Use the following procedure for the system demonstration:
Use the search strategy displayed in figure “Seaching for Function Modules” to find the obsolete function module in a standard transaction (for example, FD01.) When discussing the function module documentation, you can identify and then discuss the subsequent function module.
Due to time restrictions, we will only demonstrate the searching for and calling up of function modules, so that we can at least teach the participants how to reuse
the function modules stored in the Function Library. More details are provided in course BC402.
Business Example
In your program, you need a function that might already be available in the form of a function module and you want to use this in your program, if possible.
Working with Function Modules
Figure 194: Function group
A function module is a subroutine with the corresponding function that is centrally stored in the Function Library of the SAP system. Each function module has an interface for importing or exporting parameters. The main purpose of function modules is their reusability. Hence, they belong to the reuse components.
Function modules are organized into function groups. Each function group is a collection of function modules with similar functions and/or which operate on the same data.
A function group can contain the same components as an executable program. These include:
Data objects
These are global in relation to the function group, that is, they are visible to and changeable by all function modules within the group.
Subroutines
These can be called from all function modules in the group.
Screens
These can be called from all function modules in the group.
The properties of a function module include, amongst other things, the short description and the function group it belongs to.
As is the case with subroutines, a function module can contain local type and data object definitions. These can only be seen within the function module.
The interface of a function module can contain the following elements:
• Import parameter: They can receive the values or variables of the calling program when the function module is called up. The optional parameters do not have to be supplied with data during the call.
• Export parameter: The calling program accepts the output of the function module via the assignment of a “receiving variable.” Export parameters
are always optional.
• Changing parameters: It is possible to transfer the variables of the calling program that are changed by the function module to the changing parameters.
• Exceptions: They can be triggered by the function module in certain error situations and provide information on the respective processing error in the function module. Exceptions should be treated by the calling program.
In general, the interface parameters are assigned to types from the ABAP Dictionary.
If a program calls a function module, then the entire corresponding function group is loaded and the function module is executed. The function group remains loaded in the working memory until the calling program is closed. Calling another function module of this group is thus processed without repeat loading and with the same global data of the function group.
Thus, if a function module that writes values to the global data of the function group is called, other function modules in the same function group can access this data when they are called in the same program run.
Apart from the global data of its function group a function module can also access its own, locally defined data objects as well as its interface parameters. The latter are used to accept data or return it to the calling program.
The graphic above illustrates different search scenarios:
• The application-related search via the Application Hierarchy should be used when you want to search for function modules within one/several application components.
• You use the free search via the Repository Information System if you search for function modules independent of application components.
• The program-related search is to be used if the function module you search for is called within an existing program.
Once you find a function module, you should first find out whether it has been released (attributes of the function modules), because you only have the right to support and upward compatibility when you use released function modules. We recommend only using released function modules.
You can use the documentation of the function module to find out about its functionality and obtain further information.
In many ABAP programs, a confirmation screen is sent after you choose Cancel. On this screen the standard text “Data will be lost” is displayed together with a variable text (see graphic above). The user can choose either Yes or No.
Figure 199: Example of a Function Module with User Dialog (II)
This dialog is encapsulated in a function module that you can also use in your programs.
If you call this function module, the system can pass the additional title texts to the function module using the corresponding import parameters. The function module passes a screen of its function group that displays the text lines and the title and contains the Yes and No buttons. The export parameter ANSWER then tells the calling program which button the user has chosen.
Figure 200: Interface of a Function Module
The interface of the function module consists of the import, export, changing parameters, and the exceptions.
Non-optional parameters must to be supplied with data when the function module is called. To find out which additional parameters are to be transferred and when, refer to the documentation of the function module and interface parameters.
You can test function modules using the test environment. An input template allows you to specify values for the import and changing parameters. You can also switch to debugging mode. The values in the export and changing parameters are listed after execution.
If the function module triggers an exception due to an error situation, it is displayed with its message text, if applicable.
The runtime is also displayed. These values are subject to the same restrictions as the Runtime analysis. You should therefore repeat the tests several times using
the same data.
Furthermore, you can store test data in a test data directory and create test sequences.
You call function modules using the ABAP statement CALL FUNCTION. The name of the function module follows in capital letters enclosed in single quotation marks.
In the EXPORTING block, the system passes values to the import parameters of the function module.
In the IMPORTING block of the call, the export parameters are assigned
receiving variables with which you can receive the results of the call.
From the perspective of the calling program, values can be exported to the import parameters of the function module and values can be imported for the receiving variables, which are assigned to the export parameters of the function module.
In the call syntax, you always have to specify the name of the interface parameter (formal parameter) on the left side of the parameter assignment and the data object or the value of the calling program (actual parameter) on the right side.
In order to avoid spelling errors, use the Pattern pushbutton to generate the call when you implement a call in the source code. Alternatively, you can display the function group in the navigation area and then generate the function module call in the source code using "drag-and-drop" into the editor area.
This generates the entire call syntax. That means all interface parameters as well as exceptions are listed. Optional information is commented out in the call.
Afterwards, you must fill in the current parameters and, if necessary, implement exception handling.
If processing errors occur when a function module is executed (for example, the data record to be read does not exist), then the function module triggers the corresponding exception. This has the effect that the processing of the function module is canceled and the system returns to the calling program. If the exception is listed (handled) in the EXCEPTIONS block of the call, then the return code specified is entered in the sy-subrc system field of the calling program. By checking this field after the call, you can thus determine if and, if applicable, which exception was triggered so you can react accordingly. If no exception was triggered by the function module, the sy-subrc of the calling program is set to zero.
You also have the option of setting a return for some of the possible exceptions and setting a different return code for all non-mentioned exceptions. To do so, list the formal exception OTHERS with the desired (random) return code.
In your call, you should catch all exceptions and react to them in the program. If an exception is triggered that is not caught, a runtime error occurs.
325 Exercise 18: Using Function Modules
Exercise Duration: 40 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
• Search for function modules
• Call a function module in your program
Business Example
When you choose the Cancel function on the screen of your program, a confirmation dialog is processed. Additionally, when you choose Save, the data record is updated in the database table.
Both requirements are implemented using function module calls.
System Data
System: Will be assigned Client: Will be assigned User ID: Will be assigned Password: Will be assigned
Set up instructions: No special instructions when using a standard training system
Task 1:
Implement the standard confirmation dialog for the Cancel function:
1. Extend your program ZBC400_##_DYNPRO_1 or copy the template SAPBC400UDS_DYNPRO_4 to the new program ZBC400_##_DYNPRO_5.
2. The confirmation dialog for the Cancel function is triggered by function module POPUP_TO_CONFIRM. Find out about the function module interface, read the documentation, and test the function module in the test environment.
3. In the GUI status of the screen, activate the Cancel function (function code
'RW'.)
4. Extend the USER_COMMAND_0100 module to evaluate the function code for the Cancel function. Then implement the call for function module POPUP_TO_CONFIRM by using the Pattern pushbutton. React to the user answer returned by the function module as follows:
Continued on next page
- If the user wants to cancel, set the next screen to 0 dynamically.
- Otherwise, go to screen 100.
Task 2:
Update the database table according to the user entries:
1. Change the treatment of function code SAVE so that the function module
BC400_UPDATE_BOOK is called to update the database.
2. Transfer the user input to the function module in a type-related manner and deal with the exceptions of the function module.
3. If the database was updated successfully, return to the basic list with message
148 of message class BC400 (suitable message type: 'S').
Otherwise, display error message 149 of message class BC400 (message type: 'E').
Solution 18: Using Function Modules
Task 1:
Implement the standard confirmation dialog for the Cancel function:
1. Extend your program ZBC400_##_DYNPRO_1 or copy the template SAPBC400UDS_DYNPRO_4 to the new program ZBC400_##_DYNPRO_5.
a) Carry out this step as usual.
2. The confirmation dialog for the Cancel function is triggered by function module POPUP_TO_CONFIRM. Find out about the function module interface, read the documentation, and test the function module in the test environment.
a) Carry out this step as described in the training material.
Mandatory import parameters:
TEXT_QUESTION (max. 80 characters): question in the dialog box.
Optional import parameters:
TITLEBAR (max. 40 characters): title of the dialog box.
DIAGNOSE_OBJECT(SE61 type DT): additional diagnosis text that appears above the question in the dialog box.
TEXT_BUTTON_1 (max. 8 characters): text on the first pushbutton.
ICON_BUTTON_1 (max. 30 characters): name of the icon on the first pushbutton (table ICON.)
TEXT_BUTTON_2 (max. 8 characters): text on the second pushbutton.
ICON_BUTTON_2 (max. 30 characters): name of the icon on the second pushbutton (table ICON.)
DEFAULT_BUTTON ('1', '2' or 'A'): preassigned pushbutton.
DISPLAY_CANCEL_BUTTON ('X'. ' '): displays the Cancel
pushbutton.
USERDEFINED_F1_HELP (SE61 type DT): user-defined Help documentation, displayed via an additional pushbutton.
START_COLUMN (type SY-CUCOL): start column of the dialog window.
START_ROW (type SY-CUROW): start row of the dialog window.
Continued on next page
POPUP_TYPE (type ICON-NAME): icon that appears next to the question text in the dialog box.
IV_QUICKINFO_BUTTON_1 (max. 132 characters): quick info for the first pushbutton.
IV_QUICKINFO_BUTTON_2 (max. 132 characters): quick info for the second pushbutton.
Export parameter (always optional):
ANSWER (Value: '1', '2', 'A'): answer chosen by the user.
Optional table parameters:
PARAMETER (line type SPAR): transfer table for parameters in the diagnosis and question texts.
Exceptions:
TEXT_NOT_FOUND: no diagnosis text was found.
3. In the GUI status of the screen, activate the Cancel function (function code
'RW'.)
a) Carry out this step as usual.
4. Extend the USER_COMMAND_0100 module to evaluate the function code for the Cancel function. Then implement the call for function module POPUP_TO_CONFIRM by using the Pattern pushbutton. React to the user answer returned by the function module as follows:
- If the user wants to cancel, set the next screen to 0 dynamically.
- Otherwise, go to screen 100.
a) See the source code excerpt in the model solution.
Task 2:
Update the database table according to the user entries:
1. Change the treatment of function code SAVE so that the function module
BC400_UPDATE_BOOK is called to update the database. a) See the source code excerpt in the model solution.
2. Transfer the user input to the function module in a type-related manner and deal with the exceptions of the function module.
a) See the source code excerpt in the model solution.
3. If the database was updated successfully, return to the basic list with message
148 of message class BC400 (suitable message type: 'S').
Continued on next page
Otherwise, display error message 149 of message class BC400 (message type: 'E').
a) See the source code excerpt in the model solution.
Result
Source code extract SAPBC400UDS_DYNPRO_5:
MODULE user_command_0100 INPUT.
CASE ok_code.
WHEN ’BACK’.
SET SCREEN 0.