A domain defines the properties of a data element within ABAP. The properties include the data element type, it's length if required and any restrictions on the values that may be entered into that variable. By defining a domain you can automate and greatly reduce the amount of work required when handling amongst other things user input parameters. Domains also standardise your programs. By using a domain rather than individually defining the variables within your program, any changes to the domains characteristics are automatically passed on to any programs that use that domain
Creating a domain
Domains are created using transaction SE11, the ABAP Dictionary maintenance transaction. When you start SE11, you will see a screen like so:
Select the 'Domain' radio button, enter a domain name that is relevant to the type of data that the domain specifies and click the 'Create' button.
The first thing to do is to define the domain characteristics. In this case, as I am creating a list of books that I can choose from my book shelf I'm going to define a string of 30 characters long.
The fields on this screen are:
- Short Text.
The short text is a description of this domain.
The data type is what it says - the type of data the domain will be holding. This is a basic data type such as CHAR or DATS. You can select the relevant data type from the drop down list provided.
This is the length of the data field without such niceties as the grouping characters that appear in large numbers (so 1,234,5678.9 would actually have a length of 9 characters). Any character that is not actually a valid part of the data and is put in for the users convenience should not be counted.
The number of decimal places that the data should display. Obviously of little use for character fields, dates, times and integers.......
This is the maximum length that the data can be when displayed on the screen or on a report. In the example cited above for No. Characters, the output length would be 12.
This is the Conversion Routine that the domain should use. This field is not mandatory and is not limited to the conversion routines supplied by SAP, however, before you can enter a Conversion Exit name in this field, both the input and output routines must exist and have been activated.
This field applies only to domains that are of type DEC, FLTP, QUAN and CURR. If a negative number is valid for the data in this domain then this check box should be checked. This causes SAP to reserve the first character of the output for a negative sign or a blank space.
This check box applies only to character based fields. If a string containing lowercase (as opposed to UPPERCASE) letters is valid for this domain, then this field should be checked. If the field is left unchecked, then any entries will be converted to uppercase. Note that should your input field be a key field into a table it would be wise to make sure that it's all upper case as 'this' is different to 'This' and is different again to 'tHiS' which could lead to some very confused users.....
So, having defined the basic properties of your domain, what next ?
Well, a domain can be used to restrict the entries that a user can make into an input parameter field whilst also supplying a drop down list from which the user can select the required entry if they wish.
These values are entered in the 'Value Range' tab shown below and can take three forms.
The first type of restriction is fixed values.
Fixed values are just that. They are fixed, cannot be changed unless the domain is changed and can contain a sensible desc ription of the value.
The two items that are require are the fixed value itself and a description of the fixed value. For example, you could have a boolean value of -1 for true and 0 for false. The fixed values would be -1 and the short text could be 'Yes' for example. When a user enters data into this type of field, the only entries that would be acceptable would be 'Yes' or 'No'. If they used the F4 key to display a pick list, they would also see the descriptions 'Yes' or 'No' rather than the more confusing values of -1 and 0. This then allows you to specify a series of short codes for a value whilst also providing the user with a sensible description.
So, my fixed values would end up looking like so:
(These by the way are recommended reading.)
The second type of restriction is again fixed values and defined within the domain definition. These are value ranges and allow the specification of a range of values as an upper and lower limit rather than having to enter a zillion single entries.
The last way user input can be restricted is by specifying a value table in the domain. This is only used when a Foreign key is defined and can be used as a dynamic way of restricting a users input whilst allowing the values to be updated of modified by perhaps an overnight batch job.
Don't forget to document your domain. What it is, why it's there and it's intended use.
How Are These Used
The next step up from Domains are Data Elements And this is where the domains start to do their job.