What are the components of SAP HANA

SAP HANA

A brief overview of the content and technological basics of SAP HANA and SAP Fiori.

SAP S / 4HANA

The software suite S / 4HANA (introduced in 2015) is the successor to SAP R / 3. The "S" in SAP S / 4HANA stands for the "Simple" principle and the number "4" for the 4th product generation. The product (with the modules / components for ERP, CRM, SRM, etc.) is based on the in-memory and column-oriented database SAP HANA and offers a new, HTML5-based user interface in accordance with the SAP Fiori standard.

SAP does not simply have its various specialist modules technically ported, but rather optimizations of the user interface, the ABAP code and, in particular, the data model. As just one example of many, there is a new table in the SAP-FI module, "Integrated accounting document" (Universal Journal), which links financial data with data from controlling.

Industry experts consider SAP S / 4HANA to be the most important innovation for over two decades and considered the most profound adaptation of the SAP ERP and platform strategy.

A changeover from SAP / R3 to S / 4HANA is in many cases just as complex as the changeover from SAP / R2 to SAP / R3 (published 1995).
SAP SE has already announced that support for SAP / R3 (and thus also for today's SAP GUI) will expire in 2025. Mind you, the support, i.e. the maintenance. It can be assumed that from 2018 all major further and new developments will only take place on the new S / 4HANA platform.

SAP Fiori UX

SAP Fiori is the generic term for the new SAP UX (= User Experience) guidelines and the heart of the future SAP UI strategy.

The technical implementation of the design guide is called Fiori SAPUI5, a roughly 15MB heavy MV * framework based on jQuery (similar to AngularJS developed by Google).

SAPUI5 is based on HTML5 (and CSS3), a specification that has been standard for browser-based applications since 2014.

SAP HANA architecture

The overview shows the architecture:
First the SAP Fiori-based presentation layer, then S / 4HANA with the ERP applications and reporting (DWH) and finally the SAP HANA column-based, in-memory-based database.


SAP HANA database

SAP HANA is a technological architecture that is developed and marketed by SAP SE. At its core it consists of one in-memory, columnar, relational database.

development

The development of SAP HANA started with the aim of developing a database for the real-time analysis of large amounts of data (typical big data use cases). In the early phase, various technologies were developed or acquired by SAP SE.

  • The TREX (Text Retrieval and information EXtraction) search engine (in-memory and column-oriented search engine) and part of the SAP BI (NetWeaver) component since 2005.
  • P * TIME (in-memory OLTP platform acquired from SAP in 2005).
  • MaxDB with its in-memory LiveCache engine.

The first demonstration of the platform took place in 2008: teams from SAP SE, the Hasso Plattner Institute and Stanford University demonstrated an application architecture for real-time analysis and aggregation. Vishal Sikka, former CEO of SAP SE, mentioned this architecture as "Hasso's new architecture". From this the name HANA somehow stabilized, meanwhile also called "High-Performance Analytic Appliance", but today at least without official meaning, so no acronym! For many years, SAP HANA was designed and available exclusively for DWH systems.

  • The first HANA delivery took place at the end of 2010 as an appliance, as SAP HANA only ran on special SUN servers.
  • At the end of 2012, SAP announced a platform as a service offering called SAP HANA Cloud Platform.
  • In mid-2013, the SAP Business Suite (classic ERP components for the first time) became available on SAP HANA.
  • In November 2016, SAP HANA 2 was announced, which offers enhancements for several areas such as database management and application management and includes two new cloud services: text analysis and geoanalysis.
  • SAP HANA has been available in an express edition since March 2017; an optimized version that can run on laptops and other resource constrained environments. This edition is provided free of charge and can manage in-memory databases of up to 32 GB.

Overview of the various development stages of the SAP HANA database.


At the same time, SAP said goodbye to its classic release strategy and uses so-called Support Package Stacks (SPS) which are published every 6 months and contain updates (bug fixes and new functionalities). The advantage is that these PLCs are not as powerful as releases that appear every few years: this means less effort is required for customer systems and new functionalities can be rolled out more quickly.

technology

The primary function of SAP HANA as a database server is to store and retrieve data. In addition, it performs analyzes (predictive analytics, spatial data processing, text analysis, text search, streaming analytics, graph-oriented processing) and includes ETL capabilities and an application server.

In-memory

As with any database, the main function of IMDBs (in-memory database) is to store, retrieve (and delete) data. However, the data to be processed is stored in the main memory (RAM) and not on magnetic hard drives or flash memories. This offers much higher access speeds than hard disk drives and the algorithms for access are simpler. In addition, the access times are more predictable than hard disk-based databases. Meanwhile, the prices for RAM (working memory) are so low that this can hardly be cited as a disadvantage.

However, suitable concepts are required to ensure the persistence of data storage (power failures, hardware errors, etc.): snapshot backup, transaction log, etc.

Column-oriented database

Column-oriented DBMS (database management system) store all data for a single column in the same location instead of storing all data for a single row in the same location (row-oriented systems).

Column-oriented databases are much faster than the classic row-oriented databases in terms of read access and the typical aggregation required for evaluations. This opens up the possibility of real-time evaluation based on the operational database

Note: a "table" always consists of rows and columns and is mapped in this way by both systems. The difference between the two database systems lies in the technical implementation.

In addition, there is a concept of "late materialization" of data: the data is stored in compressed form and as many joins, views, selections, filters and aggregations as possible are carried out before the data is visualized in decompressed form.
One disadvantage is that column-oriented databases are slower when inserting (many) new rows. In many ERP systems, this happens during the night through batch processing, but is compensated for by in-memory technology.

Hybrid - OLAP / OLTP

This architecture enables transactional (OLTP, online transaction processing) and analytical procedures (OLAP, online analytical processing) to be carried out in the same system.
This means that the processing and analysis of large amounts of data (big data) can take place almost in real time on the productive database.

OLAP is in contrast to OLTP, which is typically characterized by much less complex queries to process transactions rather than data for reporting and business intelligence (data warehouse (DWH)) purposes. While OLAP systems are mostly optimized for reading large amounts of data, OLTP has to process all types of queries (read, insert, change and delete).

Review: Since the end of the 1970s, it was impossible to imagine commercial companies without IT, the following paradigm has prevailed: There was a hardware (and database / application server) for operational processing. And at the same time a second, called data warehouse (DWH), for evaluations. The DWHs obtained their data (redundantly!) From the ERP systems, but their architecture was optimized for fast evaluations. The reason for this expensive, redundant and time-delayed architecture: it was simply not possible to run evaluations of this kind on the operational database without simultaneously hindering operational operations through high hardware utilization.

Although line-oriented systems were traditionally preferred for OLTP, the storage of the entire database in the main memory opens up the development of hybrid systems that are suitable for both OLAP and OLTP requirements, which means that separate hardware and software architectures are no longer required.

Advantages disadvantages

Here in a nutshell the main advantages and points of criticism

  • All these features enable a performance increase by a factor of 50 to 5,000, depending on the specific application and in particular on the type and number of database accesses.
  • For end users and their daily, dialog-based business transaction processing, on the other hand, there is little noticeable of the acceleration, since the amounts of data that are processed there are relatively small.
  • The full force of HANA unfolds with the so-called batches, which often still run overnight and which now do their work in 20 minutes instead of 5 hours, for example. This is an immense step, especially for 24/7 availability.
  • The advantages are even greater for all kinds of evaluations, including big data analyzes, which can often be carried out almost in real time.
  • The costs are mainly due to the increased hardware requirements (especially RAM). On the other hand, you save a second server landscape for the operation of a data warehouse (SAP BW).
    Added to this are the costs for a migration from SAP R / 3, which will be incurred as soon as support for SAP R / 3 expires.

 

In this context it should also be mentioned that a bitter "platform“War (digital“ ecosystem ”) between SAP, Microsoft, (Oracle) and SalesForce is raging. Triggered by three factors:

  1. On the one hand, through digitization, which for many companies means that their processes are as fully automated as possible in the sense of end-to-end processing (B2B / B2C).
  2. In addition, many IT departments have finally understood after decades that a proliferation of modules from different manufacturers (and possibly in-house developments) is extremely difficult (time-consuming, error-prone) to maintain.
  3. The third point is the tendency to no longer operate IT applications themselves (on-premise) but rather in the cloud. Salesforce (founded in 1999, 25,000 employees in 2018), for example, is completely cloud-based.