Example Data Model
The data model in this example is very simple - there is a single database table that contains details of flight connections - an airline, flight number, details of the departure airport and the destination.
NoteNot included in the figure are additional fields that the runtime needs in order to manage concurrency control. We will look at these a little later on.
Creating a Database Table
First, let's see how to create a database table.
Defining Basic Table Attributes
We will now see how to define basic table attributes.
Adding Table Definition
The following video show how to add table definition.
If you do not use a built-in ABAP Dictionary type to specify the type of a table column, use a data element instead. Data elements are ABAP Dictionary objects that define the type of a single field such as UUID, or airline code. Data elements contain not only a technical type description but also semantic information such as field labels. If you use data elements to define the types of the table columns, the system can use the field labels automatically on the generated user interface.
The data element in the Data Element figure describes the airline field. It is a character field with length 3; the system will use the field labels automatically on the generated UI.
To create a new data element, choose File → New → Other, then type data element into the Filter Text field. Enter a package name and the name of the data element, then choose Next. Select a transport request and choose Finish.
You must then specify a data type for the data element. This should be a domain - the example re-uses the existing domain /DMO/CITY. Note that both data elements use the same domain. This means that if someone subsequently changes the length of the domain, the change applies to all data elements that use it.
Finally, you enter short, medium, and long field labels, and a label that is used for column headings. Later on, when you generate the Fiori Elements app, the system will use these texts automatically.
Each table that you define must have a primary key. This is a sequence of fields at the beginning of the table description that identifies each entry in the table uniquely.
The first field in the table (and therefore also the first field in the key definition) must be the client field, and this must have the data type abap.clnt. Furthermore, it is convenient for our example to use a UUID for the unique key. If you use the data element sysuuid_x16 to specify the type of this field, you can let the runtime assign the UUID automatically when you create a new record.
For traceability reasons it is recommended to store some administrative information with the data, like, for example, the user that created or changed the data and timestamps for the creation and the last change. The database table that you create should contain the fields displayed in the figure.
NoteThese fields are mandatory for the generator we are going to use later. For that generator to work properly the fields also have be defined with the data types listed here.
Especially fieldslocal_last_changed_at and last_changed_at are not only administrative fields. In the ABAP RESTful application programming model they are also used for concurrency control.
Because RESTful applications are stateless, data consistency cannot be ensured by exclusive locks alone. The ABAP RESTful application programming model uses a mixture of exclusive locks and ETags to avoid data inconsistencies. An ETag is a field that changes its value whenever a data set is updated. By comparing the value of the ETag field, the framework can ensure that a data set has not been changed since it was read the last time. Timestamps of the last change make perfect ETag fields.
When you activate a database table in ADT, the system creates the corresponding physical table in the database. Once you have done this, you will be able to generate the additional objects that you need for your app automatically.
