1.5How SAP HANA Affects Application Development

Having explained the basic principles of the in-memory technology, the architecture of the SAP HANA database, as well as application cases and deployment models, you may now be asking yourself how the described hardware and software innovations affect application development with ABAP. This question is answered in the following section.

Note that not everything changes when implementing SAP HANA. Like in the past, you can develop powerful applications using ABAP even if these applications use SAP HANA as a database. Many of the rules for ABAP programming that you’re familiar with (e.g., the rules for efficient database access, that is, the five golden rules; see Chapter 14, Section 14.4) will essentially still be valid.

So what changes for application development in ABAP? In the following section, we’ll describe the technical options that benefit ABAP developers when using SAP HANA, and we’ll explain the code pushdown concept. You’ll learn why the database can no longer be considered a black box in the future, and which skills you should acquire.

1.5.1New Technical Options

Using SAP HANA, you can support several application scenarios—as described in Section 1.4.1. From an ABAP developer’s point of view, using SAP HANA provides the following new technical options:

1.5.2Code Pushdown

For applications that take advantage of the hardware and software innovations in SAP HANA described in Section 1.2, at least part of the application logic must be executed in the database. This is especially important if complex calculations with large data amounts must be performed. The process of moving application code from the application layer to the database layer is often referred to as code pushdown.

Traditionally, ABAP-based applications use the data-to-code paradigm. Applications optimized or developed specifically for SAP HANA, however, use the code-to-data paradigm. The remainder of this subsection describes the differences between the two paradigms.

As you can see in Figure 1.9, the application data is placed in the database layer when using the data-to-code paradigm. Basically, the application logic—comprised of orchestration logic and calculation logic—is executed entirely in the application layer. The presentation logic is executed in the presentation layer.

The Code Pushdown Principle

Figure 1.9The Code Pushdown Principle

[»]Elements of the Application Logic

In the following, the application logic is subdivided into two sections:

For ABAP programs, the following occurs: A data-to-code application reads the records from the database. The records are then buffered in internal tables of the application server. The application logic is implemented based on this principle. For presentation, the records or the data calculated based on these records are transferred to the frontend—SAP GUI, SAP Enterprise Portal, or SAP NetWeaver Business Client (NWBC). With this procedure, it’s possible to send millions of records from the database to the application server, even though only a few hundred calculated key figures will be displayed for the end user.

When using the code-to-data paradigm, the application data is also placed in the database layer. However, some of the application logic is executed in the application layer, while some of it’s implemented in the database layer. In an extreme case, the entire application logic can be executed in the database layer. Nothing fundamentally changes in the execution of the presentation logic.

When applying this paradigm to an ABAP program, the following occurs: The data of a code-to-data application is stored in the database. The orchestration logic is implemented on the application server. The calculation logic is usually executed in the database. The more complex a calculation is and the more records needed for the calculation, the more valuable is the execution in the database. With this approach, the amount of data transferred from the database to the application server can be kept to a minimum. Even if millions of records are needed for a calculation, the system only transfers the few hundred calculated key figures that the user should see.

1.5.3Database as White Box

Thanks to the architecture of AS ABAP and the database independence of Open SQL, you can develop ABAP applications without knowing database-specific details. Chapter 3, Section 3.2 describes all important elements of database access from ABAP applications in detail.

Using Open SQL, you can perform operations on the database of the application server. Open SQL provides a unified syntax and unified semantics for all database systems supported by SAP. The result of the operations and potential error messages are independent of the database system, which means programs that only use Open SQL can be run on all database systems supported by SAP.

In addition to Open SQL, Native SQL can also be used. With Native SQL, you can use database-specific operations that aren’t supported by Open SQL. However, the disadvantage of Native SQL is that programs using database-specific operations can’t be run on all database systems supported by SAP. This is probably the reason why you’ve only used Native SQL and database-specific operations in exceptional cases in the past. The database was usually a black box, or a closed system with an internal structure that didn’t need to be considered.

However, if the application logic, or at least part of it, is now to be executed (and possibly implemented) in the database, knowledge of database-specific (or better, SAP HANA-specific) details is very helpful. To really benefit from SAP HANA and achieve optimum performance, the database must become a white box. In particular, you must understand the following aspects:

When optimizing programs for SAP HANA, you should always ask yourself if these programs should also be used on different database systems (which is often the case). If a program is to be used not only on SAP HANA but also on other systems, you carefully need to weigh the pros and cons of optimizing it with SAP HANA Views or SQLScript (as you had to when using Native SQL in the past). You could, for example, have significantly better performance. A disadvantage, however, is the database-dependent application code that results from this optimization.

In general, you should only use Native SQL, SAP HANA Views, and SQLScript if optimization using Open SQL doesn’t result in the desired outcome (e.g., with regard to the response behavior) (see Chapter 14). Here you should consider that the functional scope of Open SQL was significantly enhanced in ABAP Release 7.4. Furthermore, as of this release, the CDS provide you with manifold options for view creation in ABAP. For more details, see Chapter 6.

Within a program—or generally speaking, within modularization units—you can distinguish between application code for SAP HANA and application code for other database systems using case distinctions, that is, by using IF... ENDIF. In some cases, if the application code would otherwise become too complex, you might need to create several alternative implementations of a modularization unit. In the extreme case, you have to develop a separate program for every database system.

[Ex]Alternative Implementations

Alternative implementations for a modularization unit might look like the following:

Code pushdown might lead to greater complexity of programs that are to support both SAP HANA and other database systems. Chapter 14, Section 14.1, will pick up this topic again.

1.5.4Required Qualifications for Developers

How should ABAP developers deal with the impact of SAP HANA on application development? It’s certainly not enough simply to understand the impacts described. To optimize existing applications and develop new applications or application types based on ABAP and SAP HANA, developers need to gain expertise. You should make sure to acquire this knowledge at an early stage.

From our point of view, you should gain detailed knowledge of the latest options of Open SQL and CDS (if you’re not already highly skilled with these two options), but should also familiarize yourself with technologies of the SQL standard and the SAP HANA database that go beyond Open SQL. You should know how to model SAP HANA Views and how to use SQLScript for more complex requirements both in SAP HANA Views and within database processes.

To optimize existing applications for SAP HANA—especially with regard to their performance—you need to know which programs and code patterns within these programs are particularly suitable candidates. You should familiarize yourself with the development tools used to identify suitable programs for code pushdown, and you should be able to perform a runtime analysis to examine the identified programs thoroughly.

Altogether, we assume that sound knowledge in the areas of performance analysis and performance optimization with regard to the in-memory technology will become (even) more important than in the past for traditional databases.

To develop new applications that process large data amounts using SAP HANA, the application architecture must be designed accordingly from the start. The performance of SAP HANA must be noticeable for the end user. It might not be sufficient to perform calculations with a high performance. The results of these calculations must also be displayed to the user very quickly and in simple and intuitive views. You should therefore also familiarize yourself with technologies for developing modern UIs.

And finally, you should understand the impact SAP HANA has on the known rules of ABAP programming. As already mentioned at the beginning of Section 1.5, many rules are essentially still valid. However, some rules now have a different priority; for instance, compared to using traditional databases, they are now more or less important when implementing SAP HANA. For example, avoiding many individual SQL statements (such as in a loop) is now more important than in the past.

At the same time, new guidelines will help you create several alternative implementations of a modularization unit so that a program can be run optimally, for example, both on the SAP HANA database and on traditional databases. ABAP developers should be familiar with those new guidelines as well. Details on all of these guidelines are provided in Chapter 14.