Moving Toward Data-Centric Designs with SAP HANA
- by James Wood, Founder and Principal Consultant, Bowdark Consulting
- August 2, 2013
Now that most of the core SAP Business Suite applications have been enhanced to run on SAP HANA technology, many ABAP developers are left wondering how this transition might affect them in their day-to-day development tasks. This article shows how the advent of SAP HANA technology marks a return toward data-centric design principles.
For years, limitations in the database tier have restricted the way that applications are developed in the SAP Business Suite. Now that the latest releases of SAP Business Suite applications are equipped to run on the SAP HANA database, developers confront fewer boundaries. Altering your approach to application design allows you to capitalize on the innovations offered by HANA.
SAP has delivered on its promise to enable the underlying technology stack of the SAP Business Suite to run on the SAP HANA database. This delivery represents a watershed moment in the history of SAP software, ushering in a new age of application development in which data is literally at our fingertips. However, to harness this data, you need to refine your development approach. In this article, I’ll shed some light in this area by describing how the arrival of HANA technology signals a shift (back) toward data-centric designs.
Function Dictates Form
To appreciate how HANA technology changes the way that applications are developed in the SAP Business Suite, let’s take a brief look back at some history. Since the release of SAP R/3 and its three-tier architecture in 1992, conventional wisdom in the ABAP development space has been to develop applications that minimize their use of the back-end database. Why? The short answer is that because the database has represented the primary bottleneck in the performance of SAP NetWeaver Application Server (AS) ABAP-based systems, ABAP developers have been asked to do their best to be good stewards of database resources. In general, this implies that you:
- Avoid the use of complex SQL JOIN statements and nested queries against large tables because this can tie up precious database processor threads. Instead, the preference is to collect the raw data into internal tables on the ABAP side and then crunch the data from there.
- Avoid the use of aggregate functions in SQL statements (e.g., SUM() and MAX()) against large tables because these are tasks that can be performed in the ABAP layer.
- Offload large data processing jobs to background processes and downstream systems such as SAP NetWeaver BW, SAP Supply Chain Management, SAP Advanced Planning and Optimization, and so forth to reduce traffic on the system database. Any requests for real-time reporting on large datasets are summarily rejected or ignored.
Would you like to see this full item?