Skip to Content

(2nd part of SAP TechEd recap blog)

In my last blog I have written about why we need ABAP for SAP HANA, about what we have already done as well as what we are planning to do in order to facilitate the integration between ABAP and the in-memory database technology and about which possibilities SAP HANA offers to ABAP (custom) development.

In this blog I want to write about the concrete impact SAP HANA has on the ABAPer.

Key innovations introduced with SAP HANA

To understand the impact SAP HANA has on the ABAPer, it can be helpful to revisit some of the key innovations introduced with the in-memory database technology. Since you will find plenty of information around these innovations, I will try to keep it short and focus on five innovations built into SAP HANA that I consider being of particular importance for this blog’s subsequent paragraphs. For details on in-memory database technology in general you can, for example, take a look at the home page of HPI (where you also find the original copies of the pictograms I have used).

/wp-content/uploads/2012/12/i1_in_memory_164766.png The first important innovation is (I am sure that you have heard about it) that SAP HANA is capable of storing all relevant business data in main memory. That does not mean that SAP HANA does not support storing data on disk. It does mean that SAP HANA (typically) does not need to access the disk during query execution.

SAP HANA supports multi-core architectures by distributing queries across multiple CPU cores (and across multiple server nodes). Applications running on SAP HANA hence can benefit from massive parallelization.

To give you an idea of what is technically possible: during SAPPHIRE in Orlando Vishal Sikka demonstrated SAP HANA running on a system with 4.000 CPU cores.

/wp-content/uploads/2012/12/i3_column_store_164828.png Within SAP HANA data can be organized either in row store (like in ‘traditional’ databases) or in column store. While both stores have specific advantages and disadvantages, the bulk of business data resides in the column store where it can be quickly searched and aggregated.
/wp-content/uploads/2012/12/i4_compression_164829.png SAP HANA can compress business data (in row store). This not only reduces the amount of main memory needed, but also the amount of data to be transferred between main memory and CPU. The latter is important to handle the bottleneck of in-memory database technology: CPU waiting for data to be loaded from main memory into cache (in contrast to disk I/O which used to be the bottleneck in the past).

Last not least, I want to mention SAP HANA’s capability to partition datasets. Partitioning is of particular interest for large database tables. It supports the parallelization of queries.

For example, if a database table is spread across multiple partitions (on one server node), the aggregation of one column can be done in two steps. In the first step all partitions are aggregated simultaneously. In a second step the results of the first step are added up.

Remark: while I have described the innovations one by one, it is the combination of them that really accounts for power of SAP HANA.

A new paradigm for ABAP emerges: “code-2-data”

To leverage the outlined innovations introduced with SAP HANA from ABAP, the database access becomes very important. And it is crucial – not so say compulsory – for ABAP applications to move data intense operations (i.e. costly calculations on large datasets) to the database layer. This is in some respects a paradigm shift, which is often referred to as “code pushdown” or “code-2-data” approach (in contrast to the “data-2-code” approach ABAP programs followed in the past).


The above diagram illustrates the two approaches: the “data-2-code” approach on the left and the “code-2-data” approach on the right.

What is the difference between the two?

In the past (based on traditional database technology) ABAP applications considered the database to be the bottleneck. Hence the complete business logic – including costly calculations – was implemented on the application layer. Very often a large number of records was transferred from the database to the application server to calculate only a few results there (for example to aggregate many line items to only a handful of key figures).

Now and in the future (based on SAP HANA) the database is not the bottleneck anymore. ABAP applications need to move – at least – parts of the business logic to the database layer. This not only reduces the amount of data to be transferred between database and application server, but it also ensures that the part of the business logic moved to the database (implicitly) benefits from the innovations built into SAP HANA.

However – especially when looking at existing ABAP programs – rewriting the business logic completely in the database might not be reasonable due to the efforts involved. Instead the “code pushdown” should mainly focus on costly calculations on large datasets (aka ‘number crunching’). Orchestration, process and display logic – that cannot be implemented in SAP HANA as of today or that will not benefit significantly from rewriting it in the database – should stay on the AS ABAP.

What does all that mean for the ABAPer?

Ok, now you might want to understand what all that means in terms of your skills and competencies as ABAPer. Tobias Trapp has already touched this in his blog ‘First experience with ABAP for HANA’. I like to add a few thoughts.

During SAP TechEd I have heard questions like:

  • Do I have to forget everything I know about ABAP development?
  • Does Open SQL also work on SAP HANA?
  • Will all function modules be re-implemented as database procedure?

You can put your mind at rest. As already mentioned in the first blog of this series, existing ABAP programs (developed for traditional databases) continue to run on SAP HANA. That implies that also a lot of your ABAP knowledge stays relevant. You can use Open SQL to access SAP HANA just like you access any traditional database. You can work with function groups (even though I personally prefer classes) when running on SAP HANA. And you should not attempt to re-implement all your function modules as database procedures. In five words: many things stay the same.

Even performance guidelines given by us for traditional databases in the past remain valid for SAP HANA to a large extend. But certain performance guidelines become more (‘use field lists’) or less (‘avoid access using non-key fields in WHERE clause’) important.

We definitely like to encourage you to apply your ABAP knowledge to business problems also when running on SAP HANA. In fact, when optimizing an existing ABAP program for SAP HANA you should first try to do the optimization by ‘standard’ ABAP means. Only if that does not do the trick, you should consider using SQL features beyond Open SQL (i.e. Native SQL / ADBC), SAP HANA views or database procedures from within ABAP (which is planned to be quite easy in SAP NetWeaver AS ABAP 7.4).

At the same time you need to look beyond your own backyard. I like to encourage you to brush up your SQL knowledge (beyond Open SQL features), gain experience with performance optimization and familiarize yourself with modeling and scripting in SAP HANA.

Now Eric Westenberger will take over. In the remaining two blogs Eric will deepen some of the thoughts, give you background information on the database architecture of the AS ABAP and show you some concrete examples.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Suma Rammohan

    Good Overview on Code Pushdown Thorsten.

    For ” especially when looking at existing ABAP programs – rewriting the business logic completely in the database might not be reasonable due to the efforts involved. Instead the “code pushdown” should mainly focus on costly calculations on large datasets (aka ‘number crunching’). ” , do we have any guidelines/tool from SAP side to arrive at these costly calculations ?

    I think we would need to pick on specific SQL statements within Custom code / Standard report that could really take long time to read data and do calculations on it .



    1. Hermann Gahm

      Hi Suma,

      you can always use the existing traces tools (E.g. ST05, ST12, SAT, …) to analyze your programs. With this tools you’ll find out how much time is spent on the database layer and where it is spent.

      An alternative source of information is the SQL cursor cache of your database in ST04. There you’ll find expensive SQL statements.

      That is we use the classical tools and methods for perfomance analysis.

      Besides that we are working on additional tools. These tools will most likely be available in 7.40 SP2.

      Kind regards,


  2. Jean-Bernard Rolland

    Thank you for this blog Thorsten. It is highly instructive. As my group is in the process to optimize HCM for HANA, we are facing the code push-down you are talking about. It is particularly relevant in areas with heavy data volumes, such as Time Management, Org Modelling or Payroll processing.

    I would love to hear more from you as we progress in optimizing Business Suite for HANA.

  3. Kumar Mayuresh

    Hi Thorsten Schneider,

    Thanks for writing a wonderful blog especially on “Code Push down” This blog can save my time in explaining code push down to others 🙂 . Mean while as you have suggested “To learn performance optimization and familiarizing  with modeling and scripting in SAP HANA”. I am on to that 🙂   and would request you to guide us – what all other skills are and will be necessary to Leverage the full potential of ABAP on HANA in near future.

    I would like to know that Is there any way to gain an Hand’s-on experience on ABAP 7.4 with HANA  (say on cloud as a trial system for a month or so, ) if not being able to go through CE program…?



  4. Amit Mittal

    Very informative blog.

    One thought from my side. Pushing part of code to database in the form of procedures, for getting heavy duty figures like aggregates etc, seems to be quite hyped by SAP in the name of HANA.

    Before SAP, when I used to work in Oracle and Visual basic, we used the database a lot in terms of writing procedures, triggers etc directly inside the database. Conventional SAP has used database only for storing data in the form of tables. Developers are not allowed to access the database directly, which is good in fact in my opinion.

    With this approach of writing procedures inside database to make the logic faster, I think we are moving backwords in time. This may sound enticing in the name of Hana, however in the long run the consistency between database objects viz procedures and front-end logic in programs would require extended maintenance. Developer has to maintain the consistency of code in two places now, normal ABAP logic and the logic written inside the database aswell. In conventional SAP, the developer only needs to worry on the usual abap logic written at single place.

    Also, what would be the performance difference when writing in plain ABAP a select SUM (value) aggregate query, and writing similar logic inside database procedure? I don’t think much.

    Just my opinion with limited knowledge. Thanks.


    Amit Mittal.


Leave a Reply