ABAP CDS Views – all you need to know

ABAP CDS Views

Share This Post

Share on linkedin
Share on twitter
Share on facebook
Share on email

ABAP CDS Views – all you need to know

You may have heard the term ABAP CDS Views, or perhaps you are curious what modern development on SAP S/4HANA system looks like?  

In this blog post Radek Chudziak, Senior Developer at Absoft, explains what ABAP CDS views are, why they were introduced by SAP and how they can act as a data provider to different kinds of applications.

–    What are ABAP CDS Views?

        ABAP Dictionary Views vs. ABAP CDS Views

        Why ABAP CDS Views? – Classic vs Code Pushdown approach

        Code Pushdown – Example

        Consumption of CDS Views

        The Power of Annotations

        System Requirements

        Development Environment

      ABAP CDS vs HANA CDS

What are ABAP CDS Views?

In a nutshell, ABAP CDS Views is an important technology for modern application development on SAP systems and should not be overlooked. They provide enhancements in terms of data modelling and enable improved performance when combined with SAP HANA database.

ABAP CDS Views allow developers to create semantically rich data models which the application services expose to UI clients. It is the central pillar of S/4HANA development and is used as the core technology in most of SAP’s programming models.

Whether it is ABAP Programming Model for SAP Fiori, ABAP RESTful Application Programming Model,  SAP Cloud Application Programming Model or S/4HANA Embedded Analytics CDS Views is the main technology used for data querying and modelling.

Created using an enhanced version of openSQL syntax, ABAP CDS Views reside in the application server (data dictionary) but process the logic in the database.

While the data in SAP is still physically stored in transparent tables, CDS Views are an abstraction layer on top of the tables for data modelling purposes. They understand the relationship between database tables and hide the complexity from the ABAP programmer.

A diagram showing how tables relate to the overall ABAP CDS View

ABAP Dictionary Views vs. ABAP CDS Views

If you are familiar with ABAP Dictionary views, then you can think of CDS Views as a much more sophisticated version.

ABAP Dictionary views just link database tables, whereas CDS views bring many more features. Such features include calculations, aggregations, more variations of table joins, and they can also be stacked with each other. The comparison is illustrated by the diagram below:

A diagram showing the process of moving ABAP Dictionary Views to ABAP CDS Views

Why ABAP CDS Views? – Classic vs Code Pushdown approach

The classic SAP development approach has been to keep the unnecessary load away from the database. Developers would select the required data from a database and do further processing and manipulation on the application server. The code would become complex (as its majority has been built for performance reasons) through the use of indexes and added no value to core business functions.

With the invention of SAP HANA database and consequent introduction of ABAP CDS Views this approach has changed. The new programming paradigm is called ‘code pushdown’ or “code to data”. The rule-of-thumb is to ‘do as much as possible in the database to get the best performance’.

And “as much as possible” means: all expensive calculations, aggregations and string operations should be done on the database level with only the resulting sets to be transferred to the application layer. SAP HANA database is optimised to complete such tasks. This leads to performance gains and reduction of the the complex application code. For comparison – huge amounts of data had to be transferred for processing with the classic approach. In some cases this could cause short dumps due to memory consumption limits.

SAP HANA is capable of aggregating on the fly. There is no need for pre-built aggregates and indexes since the data is organized using column stores. Also, in an S/4HANA system the data model has been simplified, by getting rid of tables necessary for aggregations and indexes.

The classic vs code pushdown (data centric approach) comparison can be represented by the following diagram:

A diagram displaying the classic approach and the data eccentric approaches to application programming models and databases

Code Pushdown – Example

So, what does ‘code pushdown’ really mean? I am using an example of a CDS View below to explain: 

Various lines of coding being highlighted

Apart from regular fields selection from database table SBOOK this CDS view:

  • Uses a cases statement, based on the value of CLASS field it will return a corresponding value: ‘Economy’, ‘Business’, ‘First’.
  • Does a currency conversion from source currency to USD using a built-in function
  • Calculates the difference between order date and flight date using a built-in function

In the classic approach, all these calculations and conversions would have been done on the application server in ABAP. With CDS Views it is possible to do so on the database level.

Consumption of CDS Views

CDS Views can be consumed in many ways as a data source. Whether it is well known ALV report using ALV with Integrated Data Access (IDA) or modern SAP Fiori application with the CDS view exposed using SAP Gateway in the oData format. You can also quickly build FIORI apps on top of CDS Views with SAP FIORI Elements templates. CDS Views also work very well with SAP’s analytical apps using analytics related annotations and analytical engine. Below is a simplified diagram of CDS Views consumption:

A simplified diagram of how CDS Views are processed for consumption

The Power of Annotations

As already mentioned, CDS views are created with openSQL which can be enriched with annotations. These annotations fall into different categories: semantic (used for S4HANA Embedded Analytics), analytical (used by analytical tools like Bex, Lumira), UI annotations (used for FIORI applications). The UI annotations are an interesting case. By marking the CDS view with relevant annotations and the use of SAP FIORI Elements we can generate a FIORI app without writing a single line of JavaScript code. The whole UI generation is driven by the CDS View and the UI annotations.

There are some drawbacks however, e.g. only certain floorplans are supported, and it is not as flexible as a freestyle SAPUI5 app. On the other hand, it is a great tool to quickly generate reports with filter bars. This is demonstrated by the illustration below. On the left-hand side you can see a CDS View with UI annotations and on the right-hand side is the generated FIORI app.