After you complete this chapter, you should be able to
In this day and age, with the emergence of the World Wide Web and all that it entails, program code must be capable of interacting and communicating with the end user. This is done in ABAP/4 using events that are invoked by the users' actions.
Processing blocks are defined by event keywords and are thus executed on the invocation of certain relevant events.
By default, the event start-of-selection is attached to all events in ABAP/4. In your programs you can define a processing block and attach this block to an event keyword.
For generally easy-to-read code, it is good practice to define sequential processing blocks in the order by which they will most likely be triggered during selection screen execution. It is also good practice to utilize the most important events for selection screen programming. These events are as follows:
The following code shows the syntax for the initialization event:
report ywhatyr. tables: marc, mvke. .. data: p_year for sy-datum. initialization. if sy-datum ge '01012000' p_year = '2000'. else. p_year = 'Yesteryear'. endif.
In this example, when the program executes for which a selection screen is defined, this initialization processing block is executed, setting the parameter field p_year equal to a value depending on the system date at the moment of execution. It is this block in which you specify the initial default values of your selection screen based on whatever criteria is necessary to maintain data integrity of user input. Some examples include setting title bars, assigning text elements to graphical user interface (GUI) elements, and function code status.
You have seen how the initialization event works, so now it's time to take a closer look at some uses of the at selection-screen and at user-command events.
The at selection-screen event is processed after user input on the active selection screen. This can occur when the user presses a function key or clicks a pushbutton, as well as a host of other elements that can be interacted on by the user. In addition to data validation checks, warning messages, GUI status change, or even pop-up windows can be called using the at selection-screen event. You will look at more examples of these later in the chapter when you look at formatting selection screens and the events involved with screen formatting elements. For now, however, let's take a look at a pushbutton on a selection screen and how the events at selection-screen and at user-command are used with this next example.
Pushbuttons, as well as many other event-driven selection screen options, can be very useful in maintaining user interaction and validating user input. In this next section, you will explore how to use pushbuttons to invoke the at user-command event and look at an example of how pushbuttons can be used to process user input.
The following code shows the syntax for the selection-screen pushbutton event:
selection-screen pushbutton example1 user-command 1234.
This statement, when used together with the at selection-screen command, is a great way to interact with the user as he enters data. The syntax is similar to that of a selection-screen comment except that data is passed when the user presses the button. Pushing the button triggers sccrfields-ucomm in the at selection-screen event and the input fields are imported. This data can then be validated and the user issued a message depending on the purpose of the button. This is an example of how you can use two pushbuttons to determine which language to report selected data in.
The following code shows the syntax for two pushbuttons that are used to choose a language:
selection-screen pushbutton 10(20) text-003 user-command engl.
selection-screen pushbutton 50(20) text-004 user-command germ.
at selection-screen.
at user-command.
case sy-ucomm.
when 'engl'.
lang-english = 'Y'.
when 'germ'.
lang-german = 'Y'.
endcase.
In this example, you can check which of the two pushbuttons were pressed by the user by using a case statement (see Figure 21.1). When the user triggers the at user-command event, the field sy-ucomm holds the unique four-byte name of the item that the user selected. In this way, you can code various data validations or command user input based on the combination of data entered and the items, in this case pushbuttons, selected by the user.
Figure 21.1 : A printout of the pushbuttons.
| NOTE |
You can also create up to five pushbuttons on the Application toolbar. These buttons on the Selection Screen toolbar are associated to specific function keys and are restricted to function keys 1 through 5. |
Now that you have learned a little about data validation using events in ABAP/4, it is time to look at some data validation techniques that are more system maintained and defined. You will first look at foreign keys. A foreign key is one or more fields that represent the primary key of a second table.
The SAP environment's relational data model can contain many tables, views, structures, and linked tables. Foreign keys, it can be said, define these relationships between multiple tables. The functions that foreign keys perform include providing help data and creating dictionary objects, but the one that you will focus on will be in the data validation area. After all, maintaining data integrity is one of the main goals when defining selection screens and the most important use of foreign keys.
A foreign key field is, by definition, restricted to values that correspond to those of the primary key of the input field's check table. This is how the link between the two tables is made. One table, FORKEY1, can be thought of as the foreign key (or dependent) table mainly because it includes foreign key fields that are assigned to primary key fields in CHECK1, which is referred to as the check (or reference) table.
| NOTE |
The foreign key field and the primary key of a parent table must share the same domain and a value table for that domain must also be specified. This extends, in a way, the data integrity check usually provided by the value table alone. |
Some check tables can have multiple primary key fields. In such cases, assignments must be made for each field when initiating a foreign key relationship. Three options are as follows:
Basically, the way a foreign key works resembles that of a direct select statement against the check table of the field with the foreign key. More specifically, when a foreign key check field is populated, the select statement that was generated by the SAP system when it defined the foreign key is sent by the program. If the table returns a value from that selection, the entry is valid. If the record is not found, the field input is invalid.
The following code shows the syntax for a system-generated select statement:
){kind=link}
select * from table_1 where table_1-exam1 = fk_exam1
and table_1-exam2 = fk_exam2.
This bit of code shows an example of a system-generated select statement that is called when data is entered into the field with the foreign key definition. In this scenario, an entry in this screen field is permitted only if the select statement produces valid data from the check table using the data entries made in fields fk_exam1 and fk_exam2 as keys.
| NOTE |
One thing that you must keep in mind while creating foreign key relation-ships is the cardinality. The cardinality of a foreign key, together with its type, is referred to as the semantic attributes of the foreign key. Each cardinality of a foreign key of these entries is optional. The cardinality should not be overlooked, however, because the entry is good practice and becomes necessary when you want to create certain types of aggregates such as help views, for example. |
Cardinality is a description of the relationship between one or more data elements to one or more of another data element. If a foreign key linking two tables has been defined, the record of the foreign key table refers to a record of the check table. This reference is constructed by assigning fields of one table, the foreign key table, to the primary key fields of the other table, the check table.
The relationship exists only if the foreign key fields are of the same data type and length as the corresponding primary key fields. A check or parent table is the table that is referenced by the foreign key itself. This is usually a value table, but it can also be a table consisting of a subset of the contents of a value table. A value table dictates the valid values that are assigned to the data element's domain.
In some cases, a constant foreign key might best suit your needs. This is the case when all valid entries in the input field contain a specific value in the key field of the cited check table. Upon the select statement's query, the constant field is checked against the primary key field that contains the fixed value.
| TIP |
It is good programming practice to utilize naming conventions that are descriptive and user friendly. In addition, SAP has agreed never to begin the name of a development object with the letters Z or Y. If you create all your objects with names that begin with one of these two letters, you will ensure that you will have no trouble with name conflicts when you upgrade your SAP system. |
Another useful way to maintain data integrity during user input is to use matchcodes. A matchcode is an object that is used to find data records in the SAP Data Dictionary. More specifically, matchcodes access data records in a way similar to an index in that all key fields are not necessary, but they differ from indexes in that matchcodes can contain more than one table in the selection range.
Here's how it works: First a matchcode object is defined with the pertinent primary and secondary tables and significant fields designated. This object then identifies all possible paths to the required data records. Next, matchcode IDs are created by mapping one path defined by the matchcode object. The only data fields that are allowable in this ID are based entirely on the matchcode object. At least one ID must be declared for each matchcode object. Matchcode objects are stored as a table pool, which is automatically generated for each matchcode ID that you declare.
A data pool is a logical pooled table that is used by SAP to internally store control data. This data, which is not pertinent externally, is mapped as a number of database tables to one SAP table.
A matchcode can be assembled in two different fashions:
In the following task, you will learn how to follow 12 easy steps to create and maintain matchcode objects. Start at the Data Dictionary screen shown in Figure 21.2 and complete the following steps:
Figure 21.2 : The initial screen of Data Dictionary.
| NOTE |
The Index sub-screen doesn't need to be maintained because these characteristics are merely for documentation purposes in the current version of the SAP system. Just leave this blank and ignore the subsequent warning that appears in the log of your object activation. |
In those 12 easy steps you created a matchcode that you can now use for maintaining data integrity. You learned how the primary keys help you check possible values of linked tables and the concept of a pool of data fields. Remember, the manner in which the matchcode data is arranged varies according to which update type is selected during initial creation. Here is a description of each of these five types:
The following is the syntax for using matchcodes for selection screen parameter input validation:
tables: saptab parameter: example like saptab-field matchcode object exam. select single field from saptab where field = example.
This example uses the matchcode object exam, which has already been defined with a matchcode ID, to validate the data input into the parameter field example. This object exam holds the relationship data necessary to maintain the integrity of the user input.
Now that you have explored some tools to validate input data in ABAP/4, let's take some time to learn more about designing effective selection screen formats. When defining input screens for the use of reporting on data, various selection elements can be combined to maintain data integrity and still be easy to use. These elements include standard input fields such as selection options and parameters, as well as others such as check boxes, radio buttons, and pushbuttons. The following section will take a look at each of these individually and give some examples of where they are best utilized. You will get a chance to combine them in Exercise 1 at the end of the chapter.
| NOTE |
Reports that have Logical Database attached to them are assigned pre-designed selection screens. These selection criteria can be modified to best suit your needs. Reports that do not have the screens pre-defined must be maintained by the programmer of the report. These custom user interfaces can take on any form and combine any elements that you, the programmer, want. |
Selection screen elements can be combined into cohesive units called blocks. These logical blocks are, in essence, a cosmetic screen feature that encapsulates a combination of screen input elements and can be created with a descriptive frame title. Logical blocks help to make the selection options easier to understand and use.
The following is the syntax for a selection-screen block with frame:
selection-screen begin of block block0 with frame title text-000.
In addition to the block statement, selection screens can be customized by utilizing formatting elements such as the following selection-screen statements:
Most of the elements included in the previous section were of the cosmetic variety; in the next section you will look at some of the selection screen elements that are more specific to processing data input.
The parameter statement on selection screens creates a data structure in the program that holds the input entered into the Parameter field by the user at runtime.
Parameters are best utilized when the field input required is a single value, as opposed to a range of values. The valid range of values can be determined by the user by clicking on the down arrow or by pressing F4 while the cursor is in the field generated by the parameter statement. This value table can be maintained by the programmer to include custom values for specific transactions or reports. The most straightforward way of setting up F4 help is by allocating a check table to the field domain in the ABAP/4 dictionary.
A domain describes the properties of the fields of a table. It defines the range of valid data values for a field and specific field characteristics.
| NOTE |
Domains determine attributes such as field type, length, and possible foreign key relationships. Modifying a domain will automatically change the attributes of all data elements attached to that domain. This is due to the fact that data elements in a domain inherit all properties of the domain that they are referenced to. |
To view or perform actions on a domain, start at the Data Dictionary screen (see Figure 21.14). Check the radio button corresponding to Domains and choose the button for the actions you want to invoke.
Figure 21.14: The Domains initial screen.
In this example, you have chosen display mode (see Figure 21.15). As you can see, the domain characteristics are displayed on the screen.
Figure 21.15: The Domains display screen.
With the parameter statement, you can include keywords that can restrict the input with certain options. These three keywords are as follows:
| TIP |
Text elements should be maintained for screen elements such as Parameters to provide the user with a good explanation of what the Selection Screen input field represents in the context of the program. These text elements are language independent and are displayed in the language of the user's logon. |
To maintain text elements for your selection screens, choose the menu path Goto->Text Elements from the ABAP/4 Editor. You can maintain all three text types for your program from here. We will now see an example of editing text symbols (see Figure 21.16).
Figure 21.16: The Text Symbols initial screen.
Figure 21.17 shows the screen that enables you to edit the text symbols that you created in your program. If you want to add more, enter a number and text and click the Save button. Also note the Where Used feature, which really comes in handy.
Figure 21.17: Maintaining text symbols.
Parameters can be created as data fields that contain only one input value and they can also be created as check boxes. When Parameters take the form of check boxes, they are declared as type C and hold the value of X when checked and space when unchecked. A good use of the checkbox parameter is to prompt the user to signal if they want certain components of a report to be displayed.
The following is the syntax for a parameter that appears as a checkbox:
parameters: testparm as checkbox default 'X'.
In this example, the initial value is set to checked, or X for the logical processing of the program. Check boxes, unlike radio buttons, are not mutually exclusive so the user can have as many boxes checked as are generated on the selection screen.
As you have learned, the parameter statement is best utilized when soliciting a single input value. If the input required is better represented in a range of values, the select-options statement is a more efficient field to use.
The select-options statement generates an internal selection table that contains the input for the attributed field entries.
The select-options statement is used similarly to the parameters statement in that it creates a selection criteria for a database field. The main difference between the two is that the select-options statement creates two input fields containing both a FROM and a TO field, as opposed to just a single field input.
The syntax for this statement is as follows:
select-options ex sele for table-field default 'VALUELOW' to 'VALUEHI'.
The select-options statement displays a line that usually has two fields for input data. This can be restricted to only one by using the no-intervals clause in the select-options syntax. For example, if your program does not require a TO field for entry in select-options statement line, but you still want to use the select-options statement, you would include this no-intervals clause. This clause, as well as the no-extension clause, will be further explored in the example at the end of this section. For now, however, we will turn to a discussion of the format of the select-options internal selection table.
This internal table is maintained with the following field format if the user clicks on the arrow to the right of the TO field of the select-options. Clicking on this arrow brings up a Multiple Selections input screen that fills the internal selection table. This table then holds the key attributes of the input data, including the SIGN, OPTION, LOW value, and HIGH value. These features of the select-options statement can have the following conditions:
| TIP |
This multiple select-option can be excluded by using the no-extension clause as stated earlier in this chapter. |
In addition to field parameters and select-options, the selection screen radiobutton statement is a great way to maintain data integrity while processing user input at run-time. In order to create Parameters as radio buttons, you must declare them using the radiobutton group clause.
The following is the syntax for a radiobutton parameter group:
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
selection-screen begin of block rad_blk with frame title text-000.
parameters: rad_ex1 radiobutton group one,
rad_ex2 radiobutton group one,
rad_ex3 radiobutton group one.
selection-screen end of block rad_blk.
This example generates a group of three parameters as radio buttons. As you can see, these radio buttons are grouped in one block on the screen. This is good programming practice as it helps the user to realize that they all belong to the same input request group. These parameters are best utilized to select a single value from a multiple option setting and must contain at least two buttons per group.
Only one of these three example buttons can be checked at runtime due to its inclusion in group one. Data integrity is maintained because this is a great way to solicit mutually exclusive input from the user. This will be further demonstrated in the following section where there is an example of a simple selection screen that utilizes many selection screen elements that you have learned about.
The following is example code for a selection screen consisting of most of the basic elements:
report YJACOBJX message-id Y6.
* Database Table Definitions
tables: mara.
selection-screen skip 1.
selection-screen begin of block block0 with frame title text-000.
selection-screen skip 1.
selection-screen begin of line.
selection-screen pushbutton 10(20) text-003 user-command engl.
selection-screen pushbutton 50(20) text-004 user-command germ.
selection-screen end of line.
selection-screen end of block block0.
* Selection parameters
selection-screen skip 2.
selection-screen begin of block block1 with frame title text-001
no intervals.
selection-screen begin of line.
parameters: p_ex1 radiobutton group rad1 .
selection-screen comment 5(30) text-ex1.
selection-screen end of line.
parameters: p_jdate1 type d default sy-datum.
selection-screen skip 1.
selection-screen begin of line.
parameters: p_ex2 radiobutton group rad1 .
selection-screen comment 5(30) text-ex2.
selection-screen end of line.
select-options: s_jdate2 for mara-laeda.
selection-screen skip 1.
selection-screen begin of line.
parameters: p_ex3 radiobutton group rad1.
selection-screen comment 5(20) text-ex3.
selection-screen end of line.
parameters: p_jdate3 like mara-laeda.
selection-screen skip 1.
selection-screen begin of line.
parameters: p_ex4 radiobutton group rad1 .
selection-screen comment 5(30) text-ex4.
selection-screen end of line.
select-options: s_jdate4 for mara-laeda no-extension no intervals.
selection-screen end of block block1.
selection-screen skip.
selection-screen begin of block block2 with frame title text-002
no intervals.
selection-screen begin of line.
parameters: P_ex5 as checkbox.
selection-screen comment 5(30) text-ex5.
selection-screen end of line.
selection-screen skip.
selection-screen begin of line.
parameters: P_ex6 as checkbox.
selection-screen comment 5(30) text-ex6.
selection-screen end of line.
selection-screen skip.
selection-screen begin of line.
parameters: P_ex7 as checkbox.
selection-screen comment 5(30) text-ex7.
selection-screen end of line.
selection-screen end of block block2.
* AT selection-screen.
AT selection-screen.
if ( p_ex1 = 'X' ) and
( ( p_jdate1 = 'IEQ?' ) or ( p_jdate1 is initial ) ).
message E017 with 'Selection Option with Default field has no value'.
elseif ( p_ex1 = 'X' ) and
not ( ( p_jdate1 = 'IEQ?' ) or ( p_jdate1 is initial ) ).
message I017 with 'We are now using Example 1'.
endif.
if ( p_ex2 = 'X' ) and
( ( s_jdate2 = 'IEQ?' ) or ( s_jdate2 is initial ) ).
message E017 with 'Selection Option using for field has no value'.
elseif ( p_ex2 = 'X' ) and
not ( ( s_jdate2 = 'IEQ?' ) or ( s_jdate2 is initial ) ).
message I017 with 'And now Example 2 is selected'.
endif.
if ( p_ex3 = 'X' ) and
( ( p_jdate3 = 'IEQ?' ) or ( p_jdate3 is initial ) ).
message E017 with 'Parameter w/ like statement field has no value'.
elseif ( p_ex3 = 'X' ) and
not ( ( p_jdate3 = 'IEQ?' ) or ( p_jdate3 is initial ) ).
message I017 with 'We are now using Example 3'.
endif.
if ( p_ex4 = 'X' ) and
( ( s_jdate4 = 'IEQ?' ) or ( s_jdate4 is initial ) ).
message E017 with 'Selection Option with no interval has no value'.
elseif ( p_ex4 = 'X' ) and
not ( ( s_jdate4 = 'IEQ?' ) or ( s_jdate4 is initial ) ).
message I017 with 'We are now using Example 4'.
endif.
if p_ex5 = 'X'.
perform get_price_data.
else.
message I017 with 'No Pricing Data selected'.
endif.
if p_ex6 = 'X'.
perform get_cost_data.
else.
message I017 with 'No Costing Data selected'.
endif.
if p_ex7 = 'X'.
perform get_revenue_data.
else.
message I017 with 'No Revenue Data selected'.
endif.
form get_cost_data.
...
endform.
form get_revenue_data.
...
endform.
form get_price_data.
...
endform.
Because radio buttons are mutually exclusive, it is a good idea to keep them all in the same processing block on the selection screen. Notice, in Figure 21.18, how each group of field elements has been isolated to contain only those fields that are relevant to that decision block.
Figure 21.18: Selection screen with relevant decision block.
As you can see in Figure 21.19, it is harder to follow the requested data fields when they are not grouped into selection screen blocks.
Figure 21.19: Selection screen without blocks.
Parameters that are defined with the like clause will appear with a down arrow, which can be clicked to view a list window of valid values (see Figure 21.20).
Figure 21.20: Parameters and the down-arrow request.
We can now click on our selection push the green check button. (see Figure 21.21). This will populate this parameter field with the value that you selected. This can be very helpful for helping a user become more familiar with your selection requirements.
Figure 21.21: Choose a valid value.
When you create a select-option without using the no-extension clause, you have the ability to enter multiple selections or a range of selections. To enter multiple selections or range of selections, simply click on the white arrow button (see Figure 21.22).
Figure 21.22: Selection options with Extension.
At this point, you can enter all of your selection criteria and click on the Copy button (see Figure 21.23).
Figure 21.23: Enter your selection requirements.
As you can see, the arrow changes color, and is now green (see Figure 21.24). This reflects the fact that you have selected multiple selections for this field and these inputs will populate a selection table at runtime.
Figure 21.24: Selection screen with green arrow enabled.
If you use the no-extensions and the no-intervals clauses in the select-options statement, you will get an input field that acts similar to a parameter field, complete with a down arrow key for viewing valid entries (see Figure 21.25).
Figure 21.25: Selection screen without extension or intervals.
Be careful using default values for select-option fields. As you can see in Figure 21.26, if you populate a select-option field with a default value, the field will not allow you to view valid entries.
Figure 21.26: select-option with default value.
The following screen shows an example of a data validation routine that utilizes an information message in the form of a pop-up window that is merely informative and just pauses the program. This is best used to communicate status of events in the processing of data (see Figure 21.27).
Figure 21.27: Pop-up message used for data validation.
You can also utilize the error type of a message text. This type of message will append the program and issue a text message to the status bar. This is used primarily to validate data upon initial entry (see Figure 21.28).
Figure 21.28: Error messages on status bar.
This example shows many elements of selection screens combined in an efficient and simple format. Please have a look at the code that created this selection screen in the paragraphs preceding this visual walkthrough.
| DO remember to utilize the selection screen elements for the tasks that best suit them.
DO design your selection screens to fit your data input requirements in a way that is easy to follow for the user. | DON'T forget to include well-thought-out data-validation routines that utilize ABAP/4's event capabilities. |
As mentioned in this last example, it is good practice to use message statements as input validation warnings at runtime.
Messages are maintained and stored in the T100 table and can be accessed from the ABAP Workbench. An effective programmer issues messages that are descriptive and help the user understand the nature of the program flow.
Each individual message statement can be assigned message types that have various effects on the outcome of the program.
You must specify a message-id report statement at the beginning of your program.
The following is the syntax for a message-id statement in a report:
report example line-count 65 line-size 132 message-id fs.
This two-character ID and a three-digit message number, together with the language, determine message classes. SAP has made including message statements in your program easy by using the insert statement command in the ABAP/4 editor.
Figure 21.29 is a quick by double-clicking on the message ID number in the ABAP/4 Editor.
Figure 21.29: Object Browser Initial Screen.
Let's start at the Object Browser and choose Other Objects at the bottom of the list (see Figure 21.30). You can skip to the Maintain Individual Messages screen by double-clicking on the message ID number in the ABAP/4 Editor.
Figure 21.30: Other Development Objects screen.
Next enter a message class and click on the icon for the action you want to perform. In this example, click on Create mode (see Figure 21.31).
Figure 21.31: Maintain Message Class screen.
Now you see the Maintain Message Class screen; it is here that you can enter the attributes of the message class that you are editing (see Figure 21.32). Click the Messages button to maintain individual messages.
Figure 21.32: Maintain Individual Messages screen.
You are now in editor mode, which corresponds to one item in a list of message text elements. After making necessary changes, click on the Save button and your message is ready to use.
| DO remember to use messages in a way that helps the user input data more efficiently.
DO make good use of the existing sys-tem message classes before creating your own. | DON'T forget to specify the correct message-id at the beginning of your report. |
| What happens if a primary key field is added to a check table after a foreign key has been defined? | |
| Additional fields that are added to the primary key of a foreign key check table are flagged as generic and therefore ignored by the system when validating data entered into the foreign key field. | |
| Is it possible to insert variables such as system error messages or return codes in a message text? | |
| Yes. If you place an ampersand in the place that you want the variable to appear in the message text and call the message passing the variable, similar to a perform statement. |
The Workshop provides you two ways to affirm what you've learned in this chapter. The Quiz section poses questions to help you solidify your understanding of the material covered and the Exercise section provides you with experience in using what you have learned. You can find answers to the quiz questions and exercises in Appendix B, "Answers to Quiz Questions and Exercises."
Create a selection screen report that lists all components of a bill of materials in multiple languages. Construct fields for selections from a range of material and plant combinations. Remember to utilize the elements that we have learned in this chapter for the tasks that best suit them.
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}