GeneXus for SAP Systems Working with Attributes and Domains

Official Content
This documentation is valid for:

Now let's understand Attributes and Domains that are key for modeling.

We will create a transaction to record tourist attractions.

This transaction will be called: “Attraction”.


For each tourist attraction, we have been asked to enter:

  • Its name
  • The country where it is located
  • A photo
  • and a category that describes if it is a monument, a museum, a show, and so on.


The key attribute of this transaction will be called “AttractionId”. We should always remember to type a dot so that GeneXus suggests a prefix and we can avoid typing mistakes.


We complete the key attribute name and set its type as numeric of 4 digits, just like we did with the Customer identifier: CustomerId.

As we will probably need to create more identifiers, it would be a good idea to create a common data type for all identifiers; for instance, a type that we may call "Id" and is a numeric value of 4 digits.

The data type created by us is called Domain.


For example, once we’ve created the Id domain, we can set several attributes to Id type... and they will all be 4-digit numeric values.  

One advantage it provides is that, if later on we need identifiers to be “Numeric” of length 6 instead of “Numeric” of 4, changing the “Domain” definition will be enough to update all the attributes based on that “Domain” in a single step.

To create it, we press the Tab key and in the Type column we write: Id=N (it is autocompleted with Numeric) 


We leave the 4-digit value suggested by default.

After pressing Enter, we can see that the AttractionId attribute has now been set as Id type.


Let’s take a look at the properties of the AttractionId attribute.

If we are positioned on the AttractionId attribute and press F4, this window will display several settings made for this attribute and will allow us to change them.


We can see that it is "Based on" the Id domain and for this reason, it is a 4-digit numeric value.

Note that properties can be sorted alphabetically


Here we can see the Autonumber property. This property is set to False by default and if we change it to True, all the new attractions entered will be automatically numbered in sequence.

That is to say, every time that a new attraction is added, the AttractionId attribute will be automatically assigned a new number that's bigger than the last existing number.

So, we're setting the Autonumber property specifically for this AttractionId identifier attribute.


Another option could be to set the same property for the Id domain that we’ve created...


... so that when we create more transaction identifier attributes, we can assign them the Id domain. In this way, they would inherit all the domain definitions (such as the data type and all the properties configured).

To see the domains created, we edit the Domains window.


Here we can create and edit domains, in a similar way to how we create attributes.  


We click on the Id domain and the properties window is refreshed to show this domain’s properties.

Here we can see again the Properties categorized view instead of the alphabetical view: 


We find the Autonumber property and set it to True... this will cause all Id type attributes to be automatically autonumbered in sequence.


We go back to the structure window of the Attraction transaction and start to create its second attribute. We add the AttractionName attribute. We also create the Name domain of Character type, length 50…. And set the Name type for the AttractionName attribute.


Now we need an attribute to record the country of the tourist attraction. 

We could create an attribute called AttractionCountry as Character(50) and enter the country name when adding details...


What happens if we want to enter two tourist attractions from the same country?

We should enter the same country name twice... and be careful to type it exactly the same! Later on, we might need to search for all the attractions in a certain country... and to get them, the country must have been typed the same every time.

Let’s take a look at this case...


Suppose that we’ve entered several attractions with their corresponding countries.

For example, we have an attraction with identifier 1, called Louvre, located in France, an attraction with identifier 2, called the Great Wall and located in China…and another attraction with Id=3, the Eiffel Tower, which is also in France. 

We know that the Louvre is located in France and that the Eiffel Tower is also in France... but due to a typing or spelling mistake, we type the country name differently. 


Here we typed France with two Ns!!... so, for the system, this country is not the same as this other one!  


For this reason, this solution can't be used...


It seems more reasonable to enter the country only once, in a single location, and then for each attraction make reference to the corresponding country. 

That is to say, we should define something like this: 


One location where countries are stored... and in attractions we make reference to the corresponding country identifiers.


The Louvre is in France

Country 2… 

The Great Wall is in China


And the Eiffel Tower is in France... Also 2.

To do this in GeneXus we will create a transaction to record the countries... and then we will see how to assign a country to each transaction.

Meanwhile, we save the Attraction structure that we haven't completed.