Code-to-Data Paradigm in ABAP with SAP HANA

Code-to-Data Paradigm:

Hi Folks, I started learning ABAP with SAP HANA and in the process of learning, I learned Code Push down techniques. Code pushdown is just a mechanism that Pushes the code to the database layer and get required result set instead of getting all the data to the application layer and write the code in the application layer to get the required output. this concept is not new for me this I know when I started working on web applications by using technologies like Java and MySQL which is 6 years back.

I perceive that Code pushdown is nothing new, It’s simply “new” for several ABAP developers. Therefore, I would like to share my exploration of this.

Traditional ABAP Coding Style: In old Style of  ABAP coding, it’s a standard practice to limit the number of hits to the database by transfer data the maximum amount as possible to the application server then playing the operations thereon to provide the required output. even though retrieving an outsized quantity of data from a database is time-consuming.

In AN ABAP/4 programming language, there are 2 styles of SQL getting used.

Open SQL permits you to access database tables declared among the ABAP Dictionary no matter which database platform that you are using in R/3 System.

Native SQL permits you to use database-specific SQL statements in an ABAP program which means Database dependent SQL statements. You will use database tables that aren’t administered by the ABAP Dictionary, and thus integrate data that are not a part of the R/3 System.

The syntax for using Native SQL.

EXEC SQL [PERFORMING form].

Database specific SQL.

ENDEXEC.

SAP currently uses HANA as its native database to store data in S/4 HANA.

Hana is not only just Database but also it is giving the below powerful benefits.

Row and Column Datastore,

Data Compression,

supporting both: OLTP and OLAP patterns among one application,

The concept of In-memory computing of the Hana Database produces the ability to Avoid unnecessary movement of huge data volume and Perform data-intensive calculations within the database. Once the data-intensive operation is performed, the only result is transferred and used among your ABAP program.

This new programming paradigm is called code-to-data or Code Pushdown.

Below is the reference image.

AN ABAP application can optimize for SAP HANA in 3 levels.

1)Transparent Optimizations: quick data Access,

2) Table Buffer enhancements. Advanced SQL in ABAP: Open SQL Enhancements, CDS Views

3)SAP HANA Native Features: AMDP, Native SQL.

To support ABAP developers following the Code-to-Data paradigm SAP came up with a bottom-up approach with a product, ABAP 7.4 with the primary Support Package, the SP2 support

Bottom-Up Approach: this is a nice concept, in theory, but it has some drawbacks. One of the issues the main issue is with the HANA Lifecycle Management System.

HANA views and HANA database procedures are managed by the HANA Lifecycle Management System. These are living in an exceedingly delivery unit which requires to be transported. And on the opposite hand, side, you’ve got the external views and therefore the database procedure proxies.

By using the new ABAP language statement, we can call the Database procedure.

Call database PROCEDURE.

If something changes here on the database level, the data dictionary doesn’t know it. We {need to} synchronize the proxy objects for the views manually and you furthermore might need to transport the delivery unit. you’ll be able to do that within the SAP HANA Transport container, which is also a proxy object. so, we’ve got these drawbacks, particularly regarding the life cycle. With this reason, top-down approach came from the beginning with ABAP 7.4 Support Package 5 and onwards

Top-down Approach:

With this Approach, Developers can develop objects with the usual approach of working with ABAP development objects which means you will develop HANA based mostly ABAP artifacts within the ABAP Application Server itself and deploy(activate) them on the HANA database.

It’s a bit like our usual ABAP Report development, whereby we have a tendency to develop the report at the application server level and therefore the report is then activated and a transport request is generated which may be released so as to move the object across systems