Defining Domains and Data Elements

Play the video to learn about database tables in the ABAP Dictionary.

This is a database table definition in the ABAP Dictionary. You can see the name of the DB table after the key word define table, and the names of the table fields on the left of the colons (:). You find the field types on the right of the colons.

In this example, the first field (field client) is typed with a predefined type directly (type abap.clnt). This is possible in general, but you should only use it for purely technical fields like the client field. For all other fields, it is recommended that you reference a data element so that the fields are linked to semantic information, too.

A data element specifies the technical and semantic properties of a table field. When you display a data element, you find the technical type definition on the left, and semantic information (field labels) on the right.

In this example, the technical type is defined through a reference to a domain. This is the recommended approach. The basic data type CHAR and the length 3 are not stored in the data element itself, but come from the referenced domain. They are displayed here for reference, and to save you the trouble of navigating into the domain.

The field labels become relevant when fields based on this data element are visible on the user interface (UI). This is true for classical ABAP UI technologies like Screens (also known as Dynpros) and Web Dynpro, as well as for modern programming techniques like the ABAP RESTful application programming model. The main difference between the four field labels on the right is their respective maximum length.

The main purpose of a domain is to specify the technical properties of a table field. The domain in this example uses technical type CHAR and sets the length to 3.

Other settings allow you to restrict the value range of fields. We will discuss this in detail in the next section.

Play the video to learn how to create a new domain, data element, or any other dictionary object.

When creating a domain, you have to choose one of various predefined dictionary types. Some of these types are meant for general use, others come with a special purpose and semantic.

General

Some dictionary types for general use are CHAR, INT4, FLTP, and DEC, which correspond directly to ABAP built-in types C, I, F, and P.

Char-like with special semantics

Fields with dictionary types NUMC, CLNT, and LANG are char-like on the DB but have a special semantics.

• Fields of type NUMC can only contain digits, and some ABAP frameworks will automatically insert leading zeros.

• A key field of type CLNT in a database table is automatically treated as client field. By default, any access to this table is restricted to the logon client of the current user.
• A key field of type LANG in a database table is identified as a language key. Language keys are important in tables that contain translatable text (so-called text tables).

Currency and Quantity

The ABAP dictionary knows dedicated types for amount fields and quantities. Technically, predefined types CURR and QUAN are identical to type DEC, and like DEC, they are mapped to ABAP type P. But as you will see later, you have to link any table field of type CURR to a currency code field. Similarly, a field of type QUAN requires a link to a field with a unit of measure.

Predefined types CUKY and UNIT are used to identify a field as currency code field or unit of measure field. Technically, they are just character fields with fixed length 5 for currency codes and length of 2 or 3 for unit of measure fields.

Date and Time

In ABAP, date and time information is processed as a sequence of 8 digits (date) and 6 digits (time). For a long time, the dictionary only knew predefined types DATS and TIMS. With these types, the fields in the database are character-like, with the same format as in ABAP. With the newer types DATN and TIMN, the framework can create the fields on the database with optimized database-specific formats. Note that this has no impact on the ABAP code. Old and new dictionary types are mapped to the same predefined ABAP types.

When you define a domain with either of the types DEC, QUAN, and CURR, you have to specify a length and the number of decimals. This is similar to the use of type P in ABAP. But there is one big difference.

In ABAP, the number n in TYPE P LENGTH n is the number of bytes. From there, the number of digits is derived with the formula: 2 * n - 1. In the ABAP dictionary, you directly specify the number of digits.

In ABAP, a data object of type P always occupies a whole number of bytes. This always results in an odd number of digits. If dictionary type uses DEC, QUAN, or CURR with an even number for length, the ABAP data objects will be 'upgraded' to the next whole number of bytes.

Let's have a look at an example. Data Element /DMO/FLIGHT_PRICE is of type CURR with length = 16. To store the 16 digits and a sign, 8 ½ bytes are required. ABAP variable price is typed with data element /DMO/FLIGHT_PRICE. As you can see from the debugger display, its ABAP length is 9, because it is not possible to occupy 8 ½ bytes. This leads to the result that it is technically possible to assign PRICE values with 17 digits.

Play the video to learn about defining the technical type of a data element.

There are two places where you maintain texts in a data element: Three labels and a heading on the Field Labels section, and a description on the Properties view, usually displayed in the tabstrip below the editor.

The labels and the heading come with maximum lengths. When you create a new data element, the editor presets these lengths to suggested values. It is recommended to keep the suggested lengths. Various frameworks, mostly UI techniques, use the labels and the heading to provide semantic metadata for fields.

Like all other ABAP development objects, data elements also have a description. Note that this description is not meant for the end user in the first place. It is there to provide additional semantic information to developers who analyze existing code or consider reusing the data element.

When you maintain the texts of a data element, it is important that your logon language is the same as the original language of the object. You will find the original language on the Properties view. When you create a new data element, the original language is automatically set to your logon language.