What?

This blog is about the creation of a simple SAP UI5 application that allows you to manage your data (modification of a simple DB table).

Why?

If I can avoid wasting time doing technical plumbing but rather focus on the data model and the functional part of a project, then I don’t miss the opportunity. Thanks to the use of CDS views and annotations, we are exactly in this context of optimizing development time and quality. This example shows you how simple is it to create a standard UI5 application using only a (Abap) CDS view.

How?

Let’s see how it works and how implement a simple application that allows you to do CRUD operations (Create/Read/Update/Delete) on a database table. In this demonstration, my technical landscape will be limited to the functionalities of the SAP Netweaver version 7.5.

The example

I will re-use the example I imagined for the previous blog posts:

• Analytical Report – Part 01
• Analytical Report – Part 02

So let’s say that we are in the context of the implementation of an application that manages school related data. In this application, we need to handle characteristics of schools.

School attributes:

• Type: public or private school
• Orientation: artistic, technical, financial…
• Single gender: boys and girls be taught separately
• …

Implementation

This blog post follows the SAP standard guidelines defined by the “SAP – ABAP Programming Model for SAP Fiori“. To resume them in a simple picture:

The data persistence layer (db table)

Since the system is Netweaver 7.5, the definition of the table is done in the Abap dictionary (it cannot be generated by a CDS view definition). So let’s create the Data Persistence layer in form of a transparent table via transaction SE11:

Inside red frames: the important fields and their related data elements required for the business object (generated by the runtime thanks to the view definition (see BOPF framework)):

• DB Key (raw16=> UUID) and …
• the administration fields (predefined BOPF structure “/bobf/s_lib_admin_data”).

!!! Important point here for the next steps: you need to assign a group to the include structure “/bobf/s_lib_admin_data” !!!

The business object view

Let’s create our BO view:
First, let’s write some annotations to describe the object model possibilities and behavior:

Annotations are self-describing here…

Then, let’s add some associations for value helps:
Example of the value help I quickly defined for the “Maximum_Degree” field (based on domain table):

Finally, we can add some information required for the user interface:

Interesting point here: annotations used for “administrative data fields” (modification date, user…):

• @ObjectModel.readOnly : true
• @Semantics.systemDate.createdAt : true
• _School.crea_date_time ,
• => read only and semantic annotations

Remark: I mixed in the CDS view different elements/annotations… As the picture in the “implementation” section shows it: two distinct views should be used. In this example, the business object view and the consumption view are merge into one (CDS) view…
If I activate the CDS View, the runtime produces our business object:

Let’s test our business object (via transaction BOBT):

Cool, we can create now some records! …But hee, the administrative data are not managed! Indeed, we should see the creation date, time, user… !! Ok, we need to add the required business logic to managed that.

Business logic for administrative data

Where to implement this behavior?  well, considering the SAP definition of a determination, this seems the correct place to look in: “a determination is an entity of a business object node that is used to provide functions that are automatically executed as soon as a certain trigger condition is fulfilled”.
Let’s proceed:

This blog gives you the procedure…
Let’s resume the steps:

• we have the persistence layer (DB table)
• we have the business logic (CDS view + business object)
• we’ve mixed here the business object and consumption CDS views (object model and user interface annotations)

Next: let’s publish the view as a OData service and finally create the report to use the data.

Publishing the CDS view can be done via the annotation “publish” or via manual addition of the CDS view on a service via transaction SEGW.

Implementation of the user interface (SAP UI5 part)

The standard list report supports the DB operations on the displayed data (entities).
So let’s use the standard template to generate the basic report:

Just specify basic attributes of the project and the OData service used…That’s all!
Launch the report:

Whouu… the report shows the actions required for the creation and deletion of the records!
If you’ve created some records with BOBT transaction, you can see also the detail action that should allow you to modify the entity:

Heeu…Wait the details view shows… nothing! But at least we have edit and delete actions !!

We need to specify which attributes should be visible from the detail view… to do that, let’s use some annotations to control the mapping entity-user interface. In the detail view, the UI.Facets annotations allow us to show the required fields:

Conclusion

If you need to expose, via a responsive web application, the management of simple data (table) then an Abap CDS view combined with annotations seems to be a nice way to to it!!