SAP HANA as a Primary ABAP Database

Of course, SAP HANA can also be used as the primary DBMS under any ABAP- based system. With the SAP BUSINESS SUITE POWERED BY SAP HANA offering, ABAP-based Suite applications like ERP can be run with SAP HANA as the primary DBMS — no replication or other databases is needed. Likewise, ABAP has evolved to provide new tools and techniques that enable developers to directly access certain distinguishing features of SAP HANA. These features come with ABAP 7.40-based  systems.

We’ve already examined how secondary database connections can be accessed via both Open SQL and Native SQL in ABAP. We also learned that ABAP Open SQL is limited to objects that exist in the ABAP Data Dictionary. To address these limitations, ABAP 7.40 has introduced a new concept known as Data Dictionary Proxy Views. Proxy Views allow a developer to create  an ABAP Data Dictionary entry for SAP HANA-specific view types — Analytic, Attribute, and Calculation views. Developers can utilize Proxy Views to leverage the power and ease of use of ABAP Open SQL against these SAP HANA-specific view types. This capability is particularly useful when it is combined with ABAP range types — that is, Select-Options and Parameters.

Going further, ABAP 7.40 has introduced a parallel concept for Stored Procedures called Procedure Proxies. Procedure Proxies generate both an ABAP interface and parameter data types for a SAP HANA Stored Procedure. A new ABAP syntax (CALL PROCEDURE) was also introduced, which makes calling Stored Procedures very similar to calling ABAP Function Modules.

Both Proxy Views and Procedure Proxies make it unnecessary to drop into Native SQL within ABAP to leverage database-specific features. They streamline the amount of work the developer must perform to design applications for code push down into SAP HANA. They also improve the  data transfer efficiency between the ABAP Application Server and SAP HANA.

Transition Closer to the Database

Regardless of whether you are utilizing SAP HANA as your primary or secondary database connection, ABAP developers have to adopt different design strategies if they wish to take advantage of its full power. ABAP developers tend to shy away from deeper aspects of SQL in favor of processing the data on the application server in ABAP.

ABAP developers have been taught from early on to abstract the database as much as possible. Therefore, they tend to trust the processing on the application server where they have total control instead of the “black box” of the DBMS. This situation has been exacerbated in recent years because ABAP contains a greater array of tools that will generate the SQL for us.

This approach has served ABAP developers well for many years. Let’s take the typical situation of loading supporting details from a foreign key table. In this case, we want to load all of the fight details from SFLIGHT and also load the carrier details from SCARR. In ABAP, we could write an inner join:

Figure 4 — ABAP Open SQL with Inner Join

Many ABAP developers, however, would adopt an alternative approach where they perform the join in memory on the application server via internal tables:

Figure 5 — Typical ABAP Coding of Joining at the App Server

This approach can be benfificial when it is combined with ABAP table buffering. Keep in mind that we are comparing developer design patterns here, not the actual technical merits of these specific examples.

In HANA, the developer should strive to push more of the processing into the database. SAP HANA is an in-memory database. Almost any developer can appreciate the advantages of consolidating all of your data in fast memory as opposed to relatively slow disk-based storage. If this were the only advantage that SAP HANA offers, however, we wouldn’t notice a huge difference compared to processing in ABAP. After all, ABAP has full table buffering. Ignoring the cost of updates, if we were to buffer both SFLIGHT and SCARR, our ABAP table loop join in the previous example would be pretty fast, although it still wouldn’t be as fast as SAP HANA.

The other key points of SAP HANA’s architecture are that in addition to being in-memory, it is designed for columnar storage and parallel processing. In the ABAP table loop, each record in the table has to be processed sequentially, one record at a time. The current version of ABAP statements, however, just isn’t designed for parallel processing. Instead, ABAP leverages multiple cores/CPUs by running different user sessions in separate work processes. SAP HANA, in contrast, can parallelize blocks of data within a single request. The fact that the data are consolidated in memory only further supports this parallelization by making access from multiple  CPUs  more useful, because data can be “fed” to the CPUs that much faster. After all, parallalization isn’t useful, if the CPUs spend most of their cycles waiting for data to process.

Checkout SAP HANA Interview Questions

The other technical aspect at play here is the columnar architecture of SAP HANA. When tabular data are stored in columns, all of the data for a single column are stored together in memory. In contrast, row storage — as even ABAP internal tables are processed — places data in memory one row at a time.

Thus, for the join condition mentioned above, the CARRID column in each table can be scanned faster because of the arrangement of data. Scans of unneeded data in memory aren’t nearly as expensive as performing the same operation on disk (because of the need to wait for platter rotation), but there is a cost all the same. Storing the data columnar reduces that cost when performing operations that scan one or more columns as well as when optimizing compression routines.

For these reasons, developers (and especially ABAP developers) must re-think their application designs. To extract the maximum benefit of  SAP HANA, they will also need to push more of the processing from ABAP down into the database. To accomplish this task, developers need to write more SQL and to interact more frequently with the underlying database. The database will no longer be a “bit bucket” to be minimized and abstracted. Rather, it will become another tool in the developer’s toolset to be fully leveraged.