When focusing on a few of the specific aspects of the programming applications for SAP HANA, we need to look at those that can maximize computational power and speed. Some of the examples below look at the newer capabilities that SAP HANA can provide to developers.
An ACID-compliant database, SAP HANA is similar in conception with most databases that have been in use before. It is compliant with MDX and SQL and also has access to ODBC and JDBC libraries. SAP HANA saves data in rows and columns within tables. These require administration as well as a backup.
That said, a number of key differences exist and with ever-evolving technologies make it a necessity that you consider when you write or design apps that make use of SAP HANA as a database. Importantly, you will also need to eliminate a few of the ‘rules of gravity’ that used to be the norm in the ‘old world’ and leverage the more modern capabilities of SAP HANA. Happily, SAP HANA is fully compliant with all of the standard database interfaces.
In order to make full use of this system, we have the option of retaining our existing applications, redirecting the JDBC or ODBC configuration and execute them as they are but keeping SAP HANA as the new database layer.
However, the drawback of this scenario is the fact that SAP HANA has capabilities that other databases cannon use. These advantages include fundamental technical capabilities in the database which tend to be superior to other databases.
Additionally, SAP HANA goes above and beyond normal traditional databases and offers complete application and development platform and is able to extend its capabilities in areas including predictive analysis, search, etc.
Thus, putting together an application using advantages central to SAP HANA can provide you with the highest opportunity to create responsive and innovative applications.
The core difference when attempting to develop apps before SAP HANA and developing apps for SAP HANA is largely the shift in mentality that is required when working in a world without constraints. A number of developers who have worked with SAP HANA during the initial stages mentioned this phenomenon as ‘taking the red pill’.
At the outset, developers are trained to strive for a compromise between maximum utility of an application and a maximum usage of the core infrastructure that supports the app. There are a number of textbooks that can illustrate the ‘best practices’ for developers to achieve the pinnacle of this balance.
When it comes to disk-based architecture, the task of writing a complicated algorithm than can call data large, unique tables in parallel and perform off-the-cuff join can be thought of as being foolish till the recent past. However, what if the algorithm contained within the app can present the user with a substantial business value?
What happens if the algorithm carried no ‘penalties’? What if an answer to a question was received in a matter of milliseconds instead of hours? If there always was a super efficient computer at the ready to calculate an algorithm whenever needed? If, while performing these operations, what if you could also collapse all other applications and be able to provide a low-complexity, stable platform for this single application?
This is the kind of shift in thought process that is needed to make the change to the world of zero constraints – the world of SAP HANA.
When it comes to SAP, developers are trained to remove their applications from the corresponding database and consider them as a ‘black box’. The primary location for application logic and SQL generation is the ABAP engine. Therefore, the database is mainly utilized for storing data only. As most ABAP developers have very little knowledge of which database their application is finally destined to run on, they tend to build keeping in mind the lowest common denominator. PHP, JAVA .NET and a number of different development platforms make use of similar abstraction methods mainly due to ODBC / JDBC.
However, they tend to sacrifice capabilities in favor of compatibility. The separation of data storage and application logic is one of the basics of ABAP application development for almost 2 decades. This is largely due to the reason that the most effective strategy for SAP is to strike a balance between performance of applications and broad support for different databases.
Contrastingly, when it comes to working with SAP HANA, the ABAP engine knows the database it is expected to work it. It is also aware that SAP HANA has been optimized to provide the support it may need. As a result, the ABAP engine is able to leverage the speed of memory-to-processor and make use of the myriad of capabilities and features that SAP HANA is able to offer in terms of business functions and calculations.
The JDBC interface also includes Abstraction for Java-based apps and ODBC for the different other platforms. This ‘buffer’ works well when insulation is needed between the database engine and the developers. However, it also able to prevent developers from using a number of different database functions.
A lot of the tasks around performance processing for SAP HANA are executed by databases deep within the application. Therefore, SAP HANA allows developers access into far greater depths of the data model. Additionally, for data-heavy operations, SAP HANA works within the database and not inside the application as against other disk-based databases.
Figure 1: New Programming Paradigm
Under the earlier programming methods, developers would first design the application, write the app logic, calculations and algorithms as well as data transformations and leave the database mostly alone. When an app was executed, it would be required to retrieve the required data from the database, present it to the app and then go through the calculations and algorithms to produce the result.
When it comes to SAP HANA however, the complete process is reversed. The app includes only the business logic. A call function is included which retrieves the result from the database. The calculations, algorithms, and data transformations take place inside the database itself. The only part passed to the application is the result.
By isolating the data-heavy operations, and then retrieving the required operations in the form of application functions allows the complete, overall architecture to be efficient and more elegant. More and more organizations are using SAP HANA and are noticing the performance of their applications improve significantly.
This transfer from application level data manipulation to database level data manipulation is the key to successfully leverage the power of SAP HANA. It goes without saying that the old apps can be retained and still benefit from a marginally quicker response time just because the database is now contained in memory.
However, if you move the data-heavy operations to SAP HANA, you will not just streamline the application and make the architecture simpler, but also be able to observe SAP HANA really coming to the fore in terms of a turbocharged performance when it comes to applications.
As ABAP is the main language used for application programming and is the app server foundation for SAP BUSINESS SUITE, it plays a key role in the adoption of SAP HANA into the existing SAP customer base. As a result, a number of users are interested to learn about using SAP HANA in conjunction with the SAP Business Suite and, by extension, how ABAP can be used to gain access to SAP HANA’s constructs and logic.
Basic Concepts
An ACID-compliant database, SAP HANA is similar in conception with most databases that have been in use before. It is compliant with MDX and SQL and also has access to ODBC and JDBC libraries. SAP HANA saves data in rows and columns within tables. These require administration as well as a backup.
That said, a number of key differences exist and with ever-evolving technologies make it a necessity that you consider when you write or design apps that make use of SAP HANA as a database. Importantly, you will also need to eliminate a few of the ‘rules of gravity’ that used to be the norm in the ‘old world’ and leverage the more modern capabilities of SAP HANA. Happily, SAP HANA is fully compliant with all of the standard database interfaces.
In order to make full use of this system, we have the option of retaining our existing applications, redirecting the JDBC or ODBC configuration and execute them as they are but keeping SAP HANA as the new database layer.
Comparison to Traditional Database
However, the drawback of this scenario is the fact that SAP HANA has capabilities that other databases cannon use. These advantages include fundamental technical capabilities in the database which tend to be superior to other databases.
Additionally, SAP HANA goes above and beyond normal traditional databases and offers complete application and development platform and is able to extend its capabilities in areas including predictive analysis, search, etc.
Thus, putting together an application using advantages central to SAP HANA can provide you with the highest opportunity to create responsive and innovative applications.
No Constraints
The core difference when attempting to develop apps before SAP HANA and developing apps for SAP HANA is largely the shift in mentality that is required when working in a world without constraints. A number of developers who have worked with SAP HANA during the initial stages mentioned this phenomenon as ‘taking the red pill’.
At the outset, developers are trained to strive for a compromise between maximum utility of an application and a maximum usage of the core infrastructure that supports the app. There are a number of textbooks that can illustrate the ‘best practices’ for developers to achieve the pinnacle of this balance.
When it comes to disk-based architecture, the task of writing a complicated algorithm than can call data large, unique tables in parallel and perform off-the-cuff join can be thought of as being foolish till the recent past. However, what if the algorithm contained within the app can present the user with a substantial business value?
What happens if the algorithm carried no ‘penalties’? What if an answer to a question was received in a matter of milliseconds instead of hours? If there always was a super efficient computer at the ready to calculate an algorithm whenever needed? If, while performing these operations, what if you could also collapse all other applications and be able to provide a low-complexity, stable platform for this single application?
This is the kind of shift in thought process that is needed to make the change to the world of zero constraints – the world of SAP HANA.
Abstraction
When it comes to SAP, developers are trained to remove their applications from the corresponding database and consider them as a ‘black box’. The primary location for application logic and SQL generation is the ABAP engine. Therefore, the database is mainly utilized for storing data only. As most ABAP developers have very little knowledge of which database their application is finally destined to run on, they tend to build keeping in mind the lowest common denominator. PHP, JAVA .NET and a number of different development platforms make use of similar abstraction methods mainly due to ODBC / JDBC.
However, they tend to sacrifice capabilities in favor of compatibility. The separation of data storage and application logic is one of the basics of ABAP application development for almost 2 decades. This is largely due to the reason that the most effective strategy for SAP is to strike a balance between performance of applications and broad support for different databases.
Contrastingly, when it comes to working with SAP HANA, the ABAP engine knows the database it is expected to work it. It is also aware that SAP HANA has been optimized to provide the support it may need. As a result, the ABAP engine is able to leverage the speed of memory-to-processor and make use of the myriad of capabilities and features that SAP HANA is able to offer in terms of business functions and calculations.
The JDBC interface also includes Abstraction for Java-based apps and ODBC for the different other platforms. This ‘buffer’ works well when insulation is needed between the database engine and the developers. However, it also able to prevent developers from using a number of different database functions.
A lot of the tasks around performance processing for SAP HANA are executed by databases deep within the application. Therefore, SAP HANA allows developers access into far greater depths of the data model. Additionally, for data-heavy operations, SAP HANA works within the database and not inside the application as against other disk-based databases.
Figure 1: New Programming Paradigm
Under the earlier programming methods, developers would first design the application, write the app logic, calculations and algorithms as well as data transformations and leave the database mostly alone. When an app was executed, it would be required to retrieve the required data from the database, present it to the app and then go through the calculations and algorithms to produce the result.
When it comes to SAP HANA however, the complete process is reversed. The app includes only the business logic. A call function is included which retrieves the result from the database. The calculations, algorithms, and data transformations take place inside the database itself. The only part passed to the application is the result.
By isolating the data-heavy operations, and then retrieving the required operations in the form of application functions allows the complete, overall architecture to be efficient and more elegant. More and more organizations are using SAP HANA and are noticing the performance of their applications improve significantly.
This transfer from application level data manipulation to database level data manipulation is the key to successfully leverage the power of SAP HANA. It goes without saying that the old apps can be retained and still benefit from a marginally quicker response time just because the database is now contained in memory.
However, if you move the data-heavy operations to SAP HANA, you will not just streamline the application and make the architecture simpler, but also be able to observe SAP HANA really coming to the fore in terms of a turbocharged performance when it comes to applications.
ABAP Programming for SAP HANA
As ABAP is the main language used for application programming and is the app server foundation for SAP BUSINESS SUITE, it plays a key role in the adoption of SAP HANA into the existing SAP customer base. As a result, a number of users are interested to learn about using SAP HANA in conjunction with the SAP Business Suite and, by extension, how ABAP can be used to gain access to SAP HANA’s constructs and logic.
- SAP Managed Tags:
