ABAP Trial Version for Newbies Part 11: Getting More Familiar With the ABAP Dictionary
In this weblog of our series we will improve the program from the last ABAP Trial Version for Newbies Part 10: A First Little Business Program and show you some other useful features of ABAP and the development environment provided by the NetWeaver Application Server ABAP.
Quite obviously our program is not very flexible. In fact, what the program does appears more hard-wired than really program driven insofar as you always get the same result. In this weblog we will adapt the program so that you can choose the carrier on a so-called selection screen. Using this selection screen you can very easily create a UI to input the relevant parameter, but you should use this also (just as the list output) for test purposes only, as it is based on old technology. Still, with this limitation, the selection is the perfect means to create a user interface for input of test data in a quick hack. So we will create one to input the carrier.
Astonishingly enough, we will find that there is a value help for the input of the carrier, when we call this selection screen from the program. Apparently this is quite useful, as the user cannot be expected to know the carriers available, let alone the abbreviations of the carriers that are needed by the program. At this stage, we will take the existence of this value help for granted, but keep the question in mind: Where does the value help come from, if we have prepared nothing of this kind in the program code?
Moreover there lurks the problem that we do not know in advance for which searches we will get a non-empty result set. We cannot be sure if there are any flights in the result set for a particular carrier. To make matters worse, we also will not know, why the program does not show any flights, if this happens. You might suppose that there might be something wrong with the program’s presenting the values in the user interface if it does not show any flights.
We will tackle all the question addressed in the course of this weblog:
- First we show you how to navigate from the definition of a database table in the ABAP Dictionary (transaction SE11) to the Data Browser (transaction SE16) that enables you to look at the records in the respective table. This way, you can check beforehand whether the data you input will produce a non-empty result set.
- Having a closer look at the ABAP Dictionary and the way data types are defined there we will get a better understanding of how and why technical and semantic properties of a data type can be defined separately from each other: Semantic properties are defined in the Data Elements, while syntactic properties can be defined in the Domain.
- It is the Data Element that contains a reference to a Search Help. The so-called Search Help is also defined in the ABAP Dictionary and provides the value help we use when inputting our carrier as a parameter.
- In some of the next weblogs I will present you the standard solution to problems like this: Quite obviously, the standard approach to a problem like this, is to use the debugger. This is true for ABAP as for any other programming language. But with the SAP AS ABAP it is particularly easy start the debugger. You can diverge into the debugger from the normal state of the system. There is no need to start the system in a particular debugging mode in ABAP. Moreover you will find, that the ABAP debugger offers all the functionality you expect from a state-of-the-art debugger. But this is something that should only raise your interest in the weblogs to come. Explaining the ABAP debugger will not be part of this weblog.
PARAMETERS and the Selection Screen
We start by copying the program from weblog 10 to another program. To do this, we navigate to the program in the object tree of the SE80, right click it and choose Copy. A dialog window opens:
We enter the name of the target program as shown and press the Copy button. Next we switch to the Change mode (by selecting the respective button).
So what do we want to achieve? We are not content with the SELECT statement as it is:
SELECT FROM sflight INTO TABLE itab_flight
WHERE carrid = ‘LH’ AND seatsmax < 250 .
Instead of always choosing the carrier Lufthansa, we want to enable the user to input other carriers and look what flights they offer.
In ABAP this is quite easy to achieve. We declare a variable of the relevant type as an input parameter of the program:
parameters: p_carrid type s_carr_id .
This simple line of code serves two purposes:
- First, it is the declaration of the variable as we need it. (Later in the weblog you will understand why we use the data type s_carr_id ).
- Secondly the parameters-command in ABAP creates a so-called selection screen at run time, that is a screen to input the respective variable(s) declared in this command.
In order to make our parameter do some work we adapt the select statement:
SELECT FROM sflight INTO TABLE itab_flight
WHERE carrid = p_carrid AND seatsmax < 250 .
We save, activate and run the program. As I have told you, we get to a so-called selection-screen.
Since we are not familiar with the carriers in the database we need a value help and press the F4 Button. Surely, you remember: This is the button to trigger the value help in ABAP, if there is a value help supplied. Obviously, there is a value help though we have not done anything to provide one:
We choose BA for British Airways, confirm and press the Copy button (with the checkmark icon). Noting happens.
And this is the situation I have mentioned at the beginning of this weblog. Obviously, we do not really know, if there is something wrong with our program or if there are no flights of British Airways with the specified capacity.
From the ABAP Dictionary to the Data Browser
As a first approach to solve this problem we try to find some other way to check if there are any flights in the table that match our SELECT criteria: We double click the name of the database table sflight in the data declaration of the program. The ABAP Dictionary opens. The Fields tab shows the name of each column plus its data type, as we have already shown in weblog 10. At the moment we use the ABAP Dictionary only to pass through to another transaction that provides us a view on the content of the database table. To get there, we choose the menu Utilities – Table Contents – Display. We reach the selection screen of the Data Browser (SE16):
First we enter BA in the field CARRID. A message in the status line tells us: “No table entry found for specified key”.
In order do get an overview of all the entries in the table, we delete the input BA, select the Execute button, and get a list with the entries:
A view at the relevant section of the table shows that there are no entries for BA at all. So we have one part of the answer to the question of why our program showed no result list. Still you might wonder why the program does not even show an empty list. Let me add a particular feature of the report-logic to answer the question completely: If there is no list output the program returns to the selection screen. (But be careful: In case you ever want to use this feature in test programs, you should know that the selection screen is opened in an new internal mode. That means the global variables of the program are reset to their initial values.)
Now it is time to have a look at the question of where the value help came from. You surely remember that in weblog 10 I told you that the flight model is part of all delivered SAP systems. This means the respective tables and the relevant data elements are available in the system. That was why we could use the table sflight with all its components though we have not stirred a finger to create it. The same is true for the value help as I will show in the next section.
Data Element, Domain, and the Way They Interact
We navigate back to the ABAP Dictionary, where we see the definition of the database table sflight. We want to have a closer look at the type of the component CARRID since we have a value help for a parameter of this type. So we double click the data type S_CARR_ID
We get to the data element S_CARR_ID:
Still we find that the syntactic properties of the type are not defined in here, but defined in a Domain. So we drill down to the domain by double clicking its name:
To make a long story short, the ABAP Dictionary provides two levels to define a data type: The data element determines the semantic properties of a type, while you can assign a domain to the data element, and it is this domain that defines the syntactic of technical properties. What is this two-level-structure good for? Apparently it is a good idea to reuse the technical properties of a data type. For instance, a character field of length three, can be used for all kinds of IDs, not only for carriers. They all share the syntactic properties, but need, for example, different labels.
Probably you remember the last weblog: When we output the internal table with the display method of the class cl_salv_table all the columns had header information on the screen. You might have asked yourself: Where did this information about the header text come from? It is now that we are in the right position to answer this question: The text used for headers is defined in the Data Element under the tab Field Label:
On the level of the Data Elements (1) you define the semantic properties, and, the syntactic properties are defined in the Domain (2).
Of course, this two-level-structure is optional: If you want you want you can define also the syntactic properties in the Data Element.
At Last : The Source of Our Search Help
The Data Element is also the place where search help for a data element is defined. Under the tab Further Characteristics you see the name of a search help: S_CARRIER_ID:
By double clicking the name of the search help we could go into the details of the search help. I do not want to do this here, but it should suffice to state: A search help is a particular kind of object that is created and edited with the ABAP Dictionary. It provides a value help with the with the list of possible input data by drawing the data from a table that serves as the data source.
The fact that the search help is a property of the data type has a big advantage: A a search help defined in the ABAP Dictionary, is also available in Web Dynpro ABAP applications if the fields on the screen are typed with the right Dictionary types that supply such a help. We navigate back to our program by using the Back button and take some breath and sum up what we have learned so far about the ABAP Dictionary and the Parameters command.
- The ABAP Dictionary (SE11) defines the technical properties of a database table such as the name and the data type of each column. It is possible to define the syntactic and the semantic properties of a data type separately from each other, the semantic properties in the Data Element, the syntactic properties in the Domain.
- Typical semantic properties are the field labels and the reference to a Search Help. So we know by now where the value help that seemed to appear by magic is defined: In the Data Element of S_CARR_ID. A Search Help defined there can also be used in a Web Dynpro ABAP application.
- The Data Browser (SE16) is the place where we can get an overview of all the entries of a database table. We can navigate there via the ABAP Dictionary as we have seen, but we might, of course, also open another session, input SE16 as an ok code and enter the name of the relevant database table there.
- The Parameters command is very simple to use and still a powerful means to create a UI for user input. But nowadays you should use it for test purposes only because it is based on classic technology.
With the knowledge we have acquired, we can now check if the WHERE-condition of our SELECT should lead to a list output. In order to make sure that nothing else goes wrong, you should be able to use the debugger. As I have already mentioned in the introduction of this weblog, I will soon introduce this powerful tool. You will find it particularly useful, since you can just jump into the debugger without making any time consuming preparations.