ABAP News for Release 7.40 – ABAP and SAP HANA

ABAP and HANA! Finally! Now it comes! … So you might think.

But beware, I am only the ABAP language documentation writer. What I will say in this blog cannot be more than the ABAP language documentation writer’s worm’s-eye view. All the big and great facts about SAP HANA are explained somewhere else and are easy to find. Read on here only if you want to know what I know (or at least believe to know) about ABAP and SAP HANA …

AS ABAP and SAP HANA

First of all, SAP HANA is an appliance that is rather independent from ABAP.  It is a combined hardware and software system for SAP in-memory computing used for high-performance analysis of large volumes of data. You don’t need ABAP to work with SAP HANA. SAP HANA can be used standalone, meaning that you don’t need an (ABAP) application server any more. This would be the end of the classical three-tier-architecture. All applications would be written in SAP HANA (with the programming languages available there) and the interfaces of SAP HANA would be used to communicate with UIs or other systems based on common protocols.

But there might be reasons to keep a three-tier-architecture and with it an (ABAP) application server even with SAP HANA. One reason I can think of is all that administrative stuff (authorizations, transaction handling, transport management, etc.) that is already available in an (ABAP) application server. Even if you don’t run applications on an application server, you might reuse its administrative capabilities also for SAP HANA. Another reason are the applications itself of course. Is it conceivable that all the million lines of existing application coding are fully migrated to SAP HANA in the near future? I don’t think so. Instead, there probably will be a coexistance of ABAP application servers and SAP HANA, where the ABAP systems will use the analytic capabilities of SAP HANA wherever it is useful.

There are mainly two scenarios for such a coexistence:

• Access of a standalone SAP HANA from AS ABAP
• Using SAP HANA as the Database of an AS ABAP

Access of a standalone SAP HANA from AS ABAP

An AS ABAP can access a standalone SAP HANA appliance via its APIs and the in-memory database of such a standalone SAP HANA appliance using a secondary database connection and Native SQL (mostly ADBC). Various tools and accelerators are available for replicating data from the database of an AS ABAP to the SAP HANA database, to enable dedicated high-performance analyses. Those are not embedded in ABAP and described elsewhere.

Using SAP HANA as the Database of an AS ABAP

SAP HANA works with the SAP HANA database, which is based on in-memory technology. The good thing is, that the SAP HANA database (besides all its other capabilities) can behave like a relational SQL database. All one has to do is to extend the Database Interface (DBI) of the AS ABAP in such a way that it supports the SAP HANA database. And this was done for Release 7.40! With Release 7.40 an SAP HANA database can be used as the central database of an AS ABAP. As for each database system supported by the DBI, you can access the database tables that are managed in the ABAP Dictionary with Open SQL.

Using Open SQL on the SAP HANA Database

Running an AS ABAP functionally correct on an SAP HANA Database is one big step. But of course you want more. You want to gain performance. But this is not gained automatically. Although the database access is optimized to the greatest extent possible in the DBI, many existing ABAP programs do not perform better automatically (in unfortunate cases, performance might even be somewhat worse). Why? The reason is that many ABAP programs are not optimized for database performance at all! A SELECT SINGLE inside a loop is a bad thing for any database. How should HANA improve here?  And – be honest! – are you already using Joins extensively?

Currently there is an extensive investigation ongoing at SAP that determines how you can get the most out of your existing ABAP when running it on HANA. The result will be guidelines and accompanying check tools that will point out the positions in existing ABAP code, where performance gains can be achieved. Interestingly enough, the guidelines for HANA will not differ too much from the existing guidelines for Open SQL! If you cared about performance already in your programs up to now, you must not do much when switching to HANA (Deja vu! It mainly were the lousy written programs that had problems when switching from non-Unicode to Unicode).

More than Open SQL for the SAP HANA Database

If you really want to exploit the capabilities of HANA for extensive analytics you must do more than simply using Open SQL on existing database tables. The buzz word is “code pushdown”. Suitable parts of application logic can be transferred  from the application server to SAP HANA. In fact, already an Open SQL join can present such a pushdown and can have quite an effect. But there is more. Currently (7.40, SP02) ABAP offers two ways to access the analytic capabilities of an underlying HANA Database directly:

• One way of doing analytics on HANA are the HANA views (attribute views, analytic views, and calculation views) that you model in the SAP HANA Studio and that internally are represented in SQL or in SQLScript (the language of HANA’s database procedures). These views are managed by SAP HANA and are not visible to Open SQL automatically. With Release 7.40, you can create so called external views for existing HANA views in ADT (ABAP Development Tools, Eclipse based). Such an external view is an ABAP Dictionary object (visible in SE11) and can be accessed by Open SQL like a normal dictionary view! The mapping between HANA types and ABAP types is done automatically. With other words: You can model parts or all of your analytics as a HANA view and access the result via an external view directly from ABAP now.
• If you need a more complex analysis than a HANA view can offer, you have to program it with SQLScript in HANA database procedures. Before Release 7.40, the only way of calling such a procedure from ABAP was Native SQL (mainly ADBC), which meant a lot of (awkward) coding. With Release 7.40, there is a new statement CALL DATABASE PROCEDURE that you can use to call a HANA database procedure of the underlying SAP HANA Database directly. Similar to an external view, you can create a so called Database Procedure Proxy in the ABAP Dictionary (in ADT or via an API), that can be accessed directly in the new statement. The parameters of the HANA database procedure are mapped to ABAP parameters of the proxy and a call looks very ABAP-like as follows:

  CALL DATABASE PROCEDURE dbproc_proxy EXPORTING in  = in

                                         IMPORTING out = out.

        Believe me, doing the same with ADBC does not look so nice …

Outlook

While the above two ways of accessing HANA views and procedures are quite nice already, with Release 7.40, SP05  something really cool is going to come:

ABAP Managed  Database Procedures (AMDP)

You will be able to code SQLScript directly in an ABAP method! The method is declared and called normally as any other method of ABAP Objects. When implementing the method you will simply add the addition BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT to the METHOD statement. That’s all! The implementation of the method is then done fully in SQLScript. You work normally in the ABAP environment (including syntax checks, transport management, …) and the code is automatically pushed down to HANA by the ABAP runtime environment before you call the method. When the method is called, the database procedure is executed on the SAP HANA Database while for the caller the method has the same look and feel as any ABAP method.

In my humble opinion, this will be the way for ABAPers to work with an underlying HANA database …

PS: Another kind of code pushdown will become available by using expressions (calculations with columns, etc.) in the select list of Open SQL.