Analyzing the Architecture of a RAP Application

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.

Note

Not included in the figure are additional fields that the RAP runtime needs in order to manage concurrency control. We will look at these a little later on.

Let's see how to define a database table.

We have just defined a database table to hold our data, but the app that we are going to create needs more objects than just this table. We can generate these objects using a wizard in ADT.

The generated objects contain all of the information that is necessary to provide a working app with create, read, update, and delete capability. Later on, we will also adjust and extend some of these objects to change the appearance of the user interface and to implement some checks and calculations.

Watch this video to learn how to generate additional objects.

Using your database table and the object generator, you can generate all of the objects that you need to get a working Fiori Elements app. The only manual step is to publish the service.

You must publish the service before you can test the app. To do so, open the service binding and choose Publish. Once you have done this, the entity that you created (in this case, Connection) appears in the list of entities. Mark it and choose Preview to test the app.

When you choose Preview, a browser window opens and you can create a new flight connection. However, the app does not implement any checks other than type checks (for example, only digits are allowed in the Flight Number field).