Code-to-Data Paradigm in ABAP with SAP HANA

I have started learning ABAP with SAP HANA and I understand that Code pushdown is nothing new, It’s just “new” for many ABAP developers. So I want to share my exploration on this.

Traditional ABAP coding Style:

In traditional ABAP coding, it’s a standard practice to limit the number of hits to the database by bringing data as much as possible to the application server and then performing the operations on it to produce the desired output. Even though retrieving a large amount of data from a database is time-consuming.

In an ABAP/4 programming language, there are two types of SQL being used.

1. OPEN SQL: Open SQL allows you to access the database tables declared in the ABAP dictionary regardless of the database platform that the R/3 system is using.

2. Native SQL: allows you to use database-specific SQL statements in an ABAP/4 program. This means that you can use database tables that are not administered by the ABAP dictionary, and therefore integrate data that is not part of the R/3 system.

With S/4 HANA – SAP now uses HANA as its native database to store data. But HANA is much more than just a database. Among other advantages and features, like

◉ Row and Column Datastore,

◉ Data Compression,

◉ Supporting both: OLTP and OLAP patterns within one application,

It has capabilities of In-memory computing.

One of the imperatives of In-memory computing is that you must:

◉ Avoid (unnecessary) movement of large data volume

◉ Perform data-intensive calculations in the database.

To get more benefits from SAP HANA’s capabilities it is necessary to change the programming paradigm as well as traditional application design as shown in the above figure.

on applications server layer, HANA’s capability insists that you perform data-intensive operations to be performed in the database layer itself.

To achieve optimal speed, it makes more sense to push down your coding logic to the database layer. Once the data-intensive operation is performed, the only result will be transferred and used within your ABAP program.

This is what termed as a code-to-data paradigm in the context of developing an ABAP application optimized for SAP HANA.

The Code to Data Paradigm is experienced in three levels or stages in SAP HANA each with increasing levels of complexity and performance improvements

1. Transparent Optimizations: Fast Data Access, Table Buffer enhancements.

2. Advanced SQL in ABAP: Open SQL Enhancements, CDS Views

3. SAP HANA Native Features: AMDP, Native SQL

how can we optimally support ABAP developers following the Code-to-Data paradigm? And for that, we have this bottom-up approach with a product, ABAP 7.4 with the first Support Package, the SP2 support,

Bottom-Up Approach:

So, in principle, this is a very great concept, but it has some drawbacks and the problem is the life cycle.

One of the problems or one of the issues in the life cycle that needs to be challenged.

HANA views and HANA database procedures are managed by the HANA Lifecycle Management System. They are living in a delivery unit which need to be transported. And on the other hand, side, you have the external views and the database procedure proxies.

you can use the new ABAP language statement CALL DATABASE PROCEDURE.

If anything changes here on the database level, Data Dictionary does not know it. You must synchronize the proxy objects for the views manually and you also need to transport the delivery unit. You can do that in the SAP HANA Transport Container, which is also a proxy object.

so we have these drawbacks, especially about the life cycle.

And that’s why the top-down approach came. Starting with ABAP 7.4 Support Package 5 and onwards,

The top-Down approach is our usual way of working with ABAP development objects. Meaning you would develop HANA based ABAP artifacts in the ABAP Application Server itself and deploy(activate) them on the HANA Database. It’s just like our usual ABAP Report development, wherein we develop the report at the application server level and the report is then activated and a transport request is generated which can be released in order to move the object across systems.

Below are some rules to increase the performance of the ABAP program on the SAP HANA database.

1) keep the result set small.

this reduces both amounts of memory used in a database system and network load when transferring data to the application server.

to reduce the size of your result set use WHERE and HAVING clause.

2) minimize the amount of data transfer.

To only transfer the columns, you really need to use SELECT with field list instead of using SELECT * statement.

3) minimize the number of database access. On all the database systems, there

is small performance overhead associated with every request for connection handling, SQL parsing, execution plan determination and so on.

avoiding such frequent single database request is more important on SAP HANA

you can, therefore, minimize the load on the network and the database system by minimizing the number of times you access the database.

The best advice is to use JOINS and SUBQUERIES instead of the nested SELECT loop.

4) minimizes the search overhead. Minimize the size of the result set by using WHERE and HAVING clauses.

To increase the efficiency of these clauses you better formulate them to fit with database table indexes.

5) reduce the database load. Unlike the applications server and presentation server, there is only one database server in your system.

Therefore, you should still aim to reduce the database load as much as possible.

To reduce the database load, avoid reading data redundantly and use table buffering wherever applicable and sort data in your ABAP program.