S/4 HANA presents a new opportunity for code optimization.
If you are into ABAP Development then by now you must already be familiar with the code to data paradigm. In simple terms this means pushing much of the data processing down to where the data resides i.e. the database.
Historically SAP ABAP supports 2 kinds of languages to interact with the database system.
- Open SQL – SAP’s own way of performing SQL data interaction
- Native SQL – Using the underlying database’s native SQL supported features.
Let me remind you that SAP as a software largely supports most of the common relational databases, MS-SQL, and Oracle being the most common that I have encountered. As an established rule, for a database to be called relational, it should support the structured query language, SQL. However in addition to supporting standard SQL, database makers add their own unique constructs which makes it stronger than other databases for some purpose.
SAP therefore supports Native SQL which means if you know the uderlying database, you can exploit its potential by using statements specifically supported by that database using Native SQL. In contrast to this, OpenSQL allows SAP developers to code in a database agnostic way. In other words OpenSQL statements will be always be understood and executed by the underlying database ( because they are driven off of industry standard SQL ) while NativeSQL may or may not be understood by the DB. For this reason NativeSQL statements are considered a big no-no within the ABAP Development community. In my programming career I may have hardly used NativeSQL may be like 5 times and that too mostly %_HINTS statement to optimize program SQL performance.
So what is Code to Data Paradigm and why should I be concerned of it ?
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 Data store,
- 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 have to
- Avoid (unnecessary) movement of large data volume
- Perform data-intensive calculations in the database.
One of the key differences for developing applications in ABAP for HANA is that you can push down data intense computations and calculations to the HANA DB layer instead of bringing all the data to the ABAP layer and then processing the data to do computations. This is what is termed as Code-to-Data paradigm in the context of developing ABAP applications optimized for 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
- Transparent Optimizations : Fast Data Access, Table Buffer enhancements.
- Advanced SQL in ABAP : Open SQL Enhancements, CDS Views
- SAP HANA Native Features : AMDP, Native SQL
Most of the times one would be satisfied with advances achieved with level 2 itself and Level 3 is really squeezing out the final bit of optimization, but each of them are interesting in their own applications.
Top-Down Approach for Development
The Code to Data paradigm means that data intensive operations be pushed down to the database. The obvious implementation of this would be the Bottom – Up approach in which we would program stored procedures and views directly into the HANA database and then consume them in the application server as needed. Since the procedures are coded at the database level itself, they would run faster. Correct ?
Yes. True and Even SAP thought the same way prior to NW 7.4 SP2. But later on realized that the issue with this approach for general consumption is that
- As a developer you would have to work in two environments, HANA DB to create the DB artifacts and ABAP to consume those artifacts as remote proxies. So far we have been transparent to the Database layer. In fact I have never ever directly logged in into the database layer ever.
- You will have to bear the responsibility of keeping your HANA and ABAP artifacts in sync and take care of the life cycle management.
So with NW 7.5 Sp5 onwards a change in methodology , the Top – Down approach was adopted. 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. Its just like our usual ABAP Report development, where in 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.
Currently Top-Down approach is used in the CDS views and ABAP Managed Database Procedures (AMDP).
There are already a number of blogs on this topic. I am planning to post a few topics on CDS views. What are your findings on S/4 HANA ? Have you already started working on it ? or are you interested to learn more on these topics ? Let me know your views on this topic.