Foreword

SAP HANA has been in the market for more than five years and has stirred up the database market considerably. Column-based main-memory databases have established themselves as major players, and all major database manufacturers either have integrated a version already or have announced their intention to do so. Compared to most other approaches, the main difference with SAP HANA is that the main memory column store is also used for transactional applications, which prevents multiple representation.

We could not have foreseen this development back in 2002 when we integrated the first version of a pure main memory-based (non-transactional) column store into the TREX search engine. For the document world, column-based storage of metadata (e.g., author, creation date, etc.) delivered added value because it was possible to add metadata in a flexible and easy manner and to query this data efficiently.

Things got interesting when we started using the technology to aggregate large volumes of data. Initial performance results were phenomenal and produced an air of disbelief within SAP, quickly followed by immense euphoria. Production continued until 2005; in that year, we delivered the SAP BW Accelerator (BWA) as an accelerator for our SAP Business Warehouse (SAP BW) systems. The benefits were obvious: no additional database aggregates, as well as extremely good and, above all, consistent access times because the risk of accessing undefined aggregates had disappeared.

The major breakthrough in relation to main memory-based column stores occurred in 2009 when Hasso Plattner had the vision to postulate joint column storage for Online Analytical Processing (OLAP) (reporting) queries and the Online Transaction Processing (OLTP) load. This proposal was revolutionary due to Hasso’s suggestion to place OLAP and OLTP in one system and to supplement this system with database storage in the form of a main memory-based column store. At first, the research community was very skeptical, but soon after, the sheer number of high-quality publications on this topic proved that it had well and truly arrived.

To turn this vision into a viable product, SAP HANA was established in 2009 when three groups (P*Time, MaxDB, and TREX) were merged and later joined by the Sybase team. The goal was—and remains—to build a database management platform that offers much more than traditional databases and to make this platform available to a wide range of applications, including SAP application platforms. At the end of 2010, SAP delivered the first “data-mart variant” of SAP HANA, followed by SAP HANA for BI and SAP HANA for SAP BW. A major event and final confirmation of Hasso’s vision was the announcement of SAP Business Suite powered by SAP HANA in January 2013 and its delivery to our customers. The sales figures of SAP Business Suite 4 on SAP HANA (S/4HANA) and SAP HANA itself speak for themselves.

Our customers, partners, and internal development groups can now implement a large range of options that incorporate SAP HANA’s speed and functionality into their applications and thus reap the rewards of deploying SAP HANA. ABAP is and will be one of the substantial development environments for SAP HANA, but as the developer, you must rethink whether you want to exploit the potential of SAP HANA fully. This book will certainly help in this regard.

SAP HANA will remain SAP’s innovation platform. We can therefore all look forward to exciting times ahead with lots of new features, innovations, and opportunities to build new types of never before conceived applications.

Franz Färber
Executive Vice President SAP PI HANA Platform, SAP SE