Moving Toward Data-Centric Designs with SAP HANA

  • by James Wood, Founder and Principal Consultant, Bowdark Consulting
  • August 2, 2013
/HANA
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.
Key Concept

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.

James Wood

James Wood is the founder and principal consultant of Bowdark Consulting, Inc., an SAP NetWeaver consulting and training organization. With more than 10 years of experience as a software engineer, James specializes in custom development in the areas of ABAP Objects, Java/J2EE, SAP NetWeaver Process Integration, and SAP NetWeaver Portal. Before starting Bowdark Consulting, Inc. in 2006, James was an SAP NetWeaver consultant for SAP America, Inc., and IBM Corporation, where he was involved in multiple SAP implementations. He holds a master’s degree in software engineering from Texas Tech University. He is also the author of Object-Oriented Programming with ABAP Objects (SAP PRESS, 2009), ABAP Cookbook (SAP PRESS, 2010), and SAP NetWeaver Process Integration: A Developer’s Guide (Bowdark Press, 2011). James is also a contributor to Advancing Your ABAP Skills, an anthology that holds a collection of articles recently published in SAP Professional Journal and BI Expert.

See more by this author


Comments

No comments have been submitted on this article. 


Please log in to post a comment.

To learn more about subscription access to premium content, click here.