Introduction to Application Development with SAP HANA

Let us focus on some of the most salient features of programming applications for SAP HANA that can maximize its speed and computational power. In addition, let us concentrate on examples of some of the new capabilities that SAP HANA provides to developers.

Basic Concepts

SAP HANA is an ACID-compliant database, conceptually similar in most ways to every other database you’ve ever worked with. It speaks SQL and MDX, it has JDBC and ODBC libraries, it stores data in tables, with rows and columns, and it requires administration and backup. However, there are quite a few key philosophical differences and cutting-edge development concepts that you need to consider when you’re writing apps that leverage SAP HANA as a database. Most importantly, you’ll have to let go of some of the “rules of gravity” that existed in the “old world” order to take advantage of all of the new capabilities that SAP HANA provides.

SAP  HANA  is compliant with the standard interfaces of all databases.

Therefore, to implement this system, you could simply keep your existing applications, redirect the ODBC or JDBC configuration, and then run them as- is with SAP HANA as their new database layer. The problem with this scenario is that SAP HANA offers capabilities that other databases simply don’t. Some of these advantages involve the core technical capabilities of the database, which are superior to those of other databases. In addition, SAP HANA goes well beyond the traditional database to offer a full application and development platform as well as to extend capabilities in areas such as search, predictive analysis, and so on. Therefore, building an application with these SAP HANA-specific advantages in mind will provide you with the maximum opportunities for innovative and responsive applications.

No Constraints

The primary philosophical difference between developing apps in the “old world” and developing apps for SAP HANA is probably the mindshift that is needed to program in a world without constraints. Several of the early developers who worked with SAP HANA referred to this psychological shift as “taking the red pill.”   Developers are taught from their very first “hello world” application that they have to achieve a compromise between the maximum utility of the application and maximum usage of the base infrastructure supporting the app. There are numerous books that teach these “best practices” (including quite a few from SAP) to help developers achieve this shaky balance.

In a traditional disk-based architecture, writing a complex algorithm that calls raw data from 200 large (100 million rows), unique tables simultaneously, and performs an on-the-fly join would be considered foolish and impossible just a couple of years ago. But, what if it wasn’t foolish or impossible? What if that algorithm in the app would provide a huge amount of business value to the users? What if there were no “penalties” for writing that algorithm? What if you could get an answer to that calculation in a few milliseconds instead of several hours? What if you had a supercomputer dedicated to calculating that algorithm whenever you needed it? What if, in addition to performing these operations in the database, you could collapse all of the other application and presentation layers down into the database to provide a simple, low-complexity platform to run the entire application?

This is the type of the philosophical shift required to make the leap from programing in a world of constraints into the new world of SAP HANA. In the SAP HANA world, the old constraints of database I/O and computational power become largely irrelevant. The boundaries as to where the database ends and the application server begins are also strongly challenged.

Abstraction

In the SAP world (ABAP especially), developers are taught to abstract their applications completely from the database and treat them as a “black box.” The ABAP engine is the primary location for all application logic and SQL generation, so the database is used only for data storage. ABAP developers literally have no idea what database their app is going to be run on, so they have to assume the “lowest common denominator” and write to NO specific database. JAVA, PHP, .NET, and various other development platforms often utilize very similar abstraction approaches, thanks to  ODBC/JDBC. Unfortunately, these platforms often sacrifice capabilities for compatibility. This extreme separation of application logic and data storage has been one of the cornerstones of ABAP application development for the past 20 years, primarily because this was the most effective strategy for SAP to compromise between broad  support for many databases and  performance of the applications.

In contrast, in the SAP HANA world, the ABAP engine knows EXACTLY which database it is going to interface with. It also knows that SAP HANA has been optimized to meet its needs. Consequently, the ABAP engine not only can take advantage of the native speed of memory-to-processor, it can also take advantage of all of the “under-the-hood” capabilities that SAP HANA offers for calculations and business functions.

Abstraction is also present in the JDBC interface for Java apps and ODBC for various other development platforms. This “buffer” between the app logic and the data, it needs works well to insulate the developers from the database engine. However, it also prevents the developers from utilizing many of the database functions.

With SAP HANA, many of the performance-related processing tasks are actually carried out deep inside the database (like stored procedures on steroids). Thus, SAP HANA enables developers to get deep inside the data model. In addition, SAP HANA functions inside the database to program data-intensive operations at the data level, not inside the application as they do in disk-based databases.

                    Figure 1: New Programing Paradigm

Frequently Asked SAP HANA Interview Questions & Answers

In the old programming paradigm, developers would design the application and write the app logic, data transformations, and algorithm/calculations while leaving the database largely untouched. When the app ran, it would fetch whatever data it needed from the database, bring it up to the app, transform the data, and then run them through the algorithm or calculations to present the results to the user. In SAP HANA, that process is flipped upside down. The app contains only the business logic. A function call is inserted to fetch the ANSWER from the database. The data transformations, algorithm, and calculations are all executed INSIDE the database, and only the result is passed up to the application. Offloading all of the data-intensive operations to the database and calling those operations as functions from the application makes the entire architecture significantly more elegant and efficient. In fact, companies that employ SAP HANA have seen their application performances improve by hundreds of thousands of time.

Figure 2: Paradigm Switch in Programming Models

This shift from data manipulation at the application level to data manipulation at the database level is necessary to take advantage of all of the power contained in SAP HANA. Of course, you can keep your old apps the way they are and obtain slightly faster response times simply because the database sits in memory. If you delegate the data-intensive operations down to SAP HANA, however, you’ll not only simplify the architecture and streamline the application, you’ll also see SAP HANA really let loose its horsepower for supercharged performance in the applications.

ABAP Programming for SAP HANA

Because ABAP is the primary application programming language and application server foundation for the SAP BUSINESS SUITE, it plays an  important role in SAP HANA’s adoption into SAP’s current customer base. Consequently, many people are interested in how they can utilize SAP HANA within the SAP Business Suite and, by connection, how they can use ABAP to access SAP HANA logic and constructs. In the next few sections, we will look at the various architectures where ABAP and SAP HANA work together to create innovative opportunities in the SAP Business Suite.

In this section, we will discuss several scenarios for leveraging the power of SAP HANA with both new and existing SAP Business Suite applications. These scenarios range from very simple, non-disruptive applications to accelerate a handful of problematic transactions or reports all the way to running the entire SAP Business Suite natively on SAP HANA as the primary database.