Das international tätige IT-Beratungsunternehmen bdf consultants GmbH hat für seine vollständig in SAP ERP integrierte Add-On-Lösung Process Control Center (PCC) erste Erfahrungen auf der Basis von ECC 6.0 EHP7 HANA gesammelt.
Eine moderne SAP-Architektur der nächsten Generation (Next-Level SAP) verlangt für die optimale Unterstützung der Geschäftsprozesse eine integrierte und durchgängige Planung, Generierung, Zuordnung und Ablage der Business Objekte (z. B. virtuelle Materialstämme, Materialstämme, virtuelle Dokumente, Dokumente) für jeden Arbeitsschritt. Hier bietet die Nutzung der SAP-Infrastruktur in Kombination mit PCC eine sehr preiswerte und zugleich funktional weitreichende Lösung.
SAP HANA (ehemals: High Performance Analytic Appliance, SAP HANA® nachfolgend HANA genannt) ist eine Datenbanktechnologie der SAP, die 2010 erstmals vorgestellt wurde. Es handelt sich dabei ursprünglich um eine Appliance, d.h. eine Kombination aus Hardware und Software, die mit Hilfe der In-Memory-Technologie den gegenüber der Festplatte erheblich schneller zugreifbaren Arbeitsspeicher des Computers zur Datenspeicherung nutzt. Gegenüber herkömmlichen Anwendungen ermöglicht dieser Ansatz Auswertungen mit höherer Performance. Heute ist HANA mit verschiedenen Hardwaresystemen und auch virtualisiert verwendbar (Quelle: Wikipedia).
Im Rahmen einer Performanceoptimierung mit HANA hat bdf beispielhaft eine SAP PLM 7 basierte PCC- Web- Dynpro-Anwendung untersucht. In dieser Anwendung wird eine Produktstruktur durch sogenannte PSM-Knoten abgebildet, die die verschiedenen Bestandteile der Produktstruktur und ihre Attribute repräsentieren. Ausgehend von einem beliebigen Einstiegsknoten löst die Anwendung die Produktstruktur zunächst vollständig auf. Anschließend werden Attribute der enthaltenen Strukturknoten nachgelesen und schließlich dem Benutzer in einer Web-Dynpro- Oberfläche zur Änderung angeboten.
Als Testdaten werden zwei Strukturen unterschiedlichen Umfangs verwendet, die 2155 Knoten und 4451 über jeweils 8 Strukturebenen enthalten. Jeder dieser Knoten hat ca. 1200 Attribute.
Die nachfolgende Tabelle vergleicht die Ergebnisse der Laufzeitmessungen einer X-Datenbank mit denen der HANA Datenbank im Ausgangszustand (Spalten 2 und 3) und im optimierten Zustand der Software (Spalten 4 und 5). Die Spalte 6 liefert das Ergebnis einer zweiten Optimierungsstufe, in der zusätzlich eine HANA native Programmoptimierung vorgenommen wurde.
Die Ergebnisse zeigen folgende Auffälligkeiten:
- Die Anwendung wird bei einem Umzug von einer X-DB auf eine HANA Datenbank langsamer.
- Die vorgenommenen Optimierungen werden von einer HANA Datenbank stärker angenommen als von einer anderen Datenbank.
Insbesondere der Geschwindigkeitsverlust der Anwendung direkt nach der Umstellung verwundert zunächst, er wird bei näherer Betrachtung der Arbeitsweise der Anwendung jedoch verständlich. Die Anwendung ist für die Datenpflege ausgelegt und objektorientiert programmiert. Während der Instanziierung der Knotenobjekte und weiterer abhängiger Datenobjekte erfolgen satzweise Lesezugriffe auf die Datenbank. Der Aufwand für die Ausführung eines Statements ist bei HANA jedoch derzeit vermutlich noch etwas höher als bei klassischen Datenbanken [siehe auch: Thorsten Schneider, Eric Westenberger, Hermann Gahm: ABAP Entwicklung für SAPHANA; Galileo Press, Bonn 2013].
Die Optimierung der Anwendung erfolgt durch folgende Ansätze:
- Umstellen vieler Einzel- auf wenige Mengenoperationen
- Verlagern von Anwendungslogik in die Datenbankschicht (Code Pushdown)
Um die Einzeloperationen durch Mengenoperationen ersetzen zu können, wird die Logik der Anwendung umgestellt.
Der Zeitpunkt der Instanziierung der Knoten- und Datenobjekte wird vom Zeitpunkt der Strukturauflösung und Datenbeschaffung entkoppelt.
Das bedeutet:
- Die Instanziierung und die damit verbundene Bereitstellung von Prüf- und Verarbeitungslogik erfolgt erst dann, wenn der Benutzer Eingaben auf dem UI vorgenommen hat. Sie wird nicht pauschal für alle Datensätze ausgeführt, sondern nur im Bedarfsfall für diejenigen, die der Benutzer ändert.
- Die Datenbeschaffung zur erstmaligen Anzeige der Daten kommt hingegen ohne weitere Logik aus und bedient sich direkter Mengenzugriffe auf die Datenbank.
Mit der beschriebenen Umstellung werden auf beiden Datenbanksystemen bereits sehr gute Performancegewinne erzielt, wobei sich nun das Verhältnis zugunsten von HANA umkehrt. Die HANA Anwendung ist über beide Testfälle hinweg etwa doppelt so schnell wie die Anwendung auf der X-DB.
Während sich der erste Optimierungsschritt ausschließlich der Möglichkeiten des ABAP Open SQL bedient, erfolgt ein weiterer Optimierungsschritt unter Verwendung nativer HANA Anweisungen.
Die Logik der schrittweisen Strukturauflösung wird dabei aus der ABAP-Anwendung in die Datenbank verlagert. Das geschieht durch Definition einer Datenbankprozedur in HANA, die aus der Anwendung heraus über einen sogenannten Datenbankprozedur Proxy und der ABAP Anweisung CALL DATABASE PROCEDURE angestoßen wird. Die Auflösung der Struktur erfolgt mit dieser Methode innerhalb eines Datenbankzugriffs, während bei der ABAP-gesteuerten Auflösung in den Test-Beispielen 7 Datenbankzugriffe ergeben.
Durch die beschriebene Verwendung der Datenbankprozedur zur Strukturauflösung ergibt sich ein weiterer Performancegewinn gegenüber der ABAP-gesteuerten Auflösung, der bei der großen Struktur mit 4451 Knoten etwas 1,5 s erreicht. Die Beschleunigung an dieser Stelle ist zudem nicht ausgereizt, auch das momentan noch nachträglich ausgeführte Lesen der Knotenattribute ließe sich in die Datenbankprozedur integrieren, wodurch weitere Performancegewinne zu erwarten sind.
Fazit
Durch Verwendung der In-Memory-Datenbank HANA anstelle einer klassischen X-DB lässt sich eine Anwendung zur Massenverarbeitung signifikant beschleunigen. Voraussetzung dafür ist, dass die Regeln für perfomante Datenbankzugriffe mit ABAP Open SQL eingehalten werden. Weitere Performancegewinne lassen sich durch Anwendung nativer Programmiertechniken in HANA erzielen. Im gezeigten Beispiel der PCC Strukturauflösung fallen sie noch stärker ins Gewicht, wenn tiefere Strukturen als die hier verwendeten 8-stufigen Strukturen angewendet werden. Ein weiteres Potential bietet die Integration momentan noch nachgelagerter Datenbankzugriffe in die Datenbankprozedur der Strukturauflösung.
Eine moderne SAP-Architektur der nächsten Generation (Next-Level SAP) verlangt für die optimale Unterstützung der Geschäftsprozesse eine integrierte und durchgängige Planung, Generierung, Zuordnung und Ablage der Business Objekte (z. B. virtuelle Materialstämme, Materialstämme, virtuelle Dokumente, Dokumente) für jeden Arbeitsschritt. Hier bietet die Nutzung der SAP-Infrastruktur in Kombination mit PCC eine sehr preiswerte und zugleich funktional weitreichende Lösung.
SAP HANA (ehemals: High Performance Analytic Appliance, SAP HANA® nachfolgend HANA genannt) ist eine Datenbanktechnologie der SAP, die 2010 erstmals vorgestellt wurde. Es handelt sich dabei ursprünglich um eine Appliance, d.h. eine Kombination aus Hardware und Software, die mit Hilfe der In-Memory-Technologie den gegenüber der Festplatte erheblich schneller zugreifbaren Arbeitsspeicher des Computers zur Datenspeicherung nutzt. Gegenüber herkömmlichen Anwendungen ermöglicht dieser Ansatz Auswertungen mit höherer Performance. Heute ist HANA mit verschiedenen Hardwaresystemen und auch virtualisiert verwendbar (Quelle: Wikipedia).
Im Rahmen einer Performanceoptimierung mit HANA hat bdf beispielhaft eine SAP PLM 7 basierte PCC- Web- Dynpro-Anwendung untersucht. In dieser Anwendung wird eine Produktstruktur durch sogenannte PSM-Knoten abgebildet, die die verschiedenen Bestandteile der Produktstruktur und ihre Attribute repräsentieren. Ausgehend von einem beliebigen Einstiegsknoten löst die Anwendung die Produktstruktur zunächst vollständig auf. Anschließend werden Attribute der enthaltenen Strukturknoten nachgelesen und schließlich dem Benutzer in einer Web-Dynpro- Oberfläche zur Änderung angeboten.
Als Testdaten werden zwei Strukturen unterschiedlichen Umfangs verwendet, die 2155 Knoten und 4451 über jeweils 8 Strukturebenen enthalten. Jeder dieser Knoten hat ca. 1200 Attribute.
Die nachfolgende Tabelle vergleicht die Ergebnisse der Laufzeitmessungen einer X-Datenbank mit denen der HANA Datenbank im Ausgangszustand (Spalten 2 und 3) und im optimierten Zustand der Software (Spalten 4 und 5). Die Spalte 6 liefert das Ergebnis einer zweiten Optimierungsstufe, in der zusätzlich eine HANA native Programmoptimierung vorgenommen wurde.
Die Ergebnisse zeigen folgende Auffälligkeiten:
- Die Anwendung wird bei einem Umzug von einer X-DB auf eine HANA Datenbank langsamer.
- Die vorgenommenen Optimierungen werden von einer HANA Datenbank stärker angenommen als von einer anderen Datenbank.
Insbesondere der Geschwindigkeitsverlust der Anwendung direkt nach der Umstellung verwundert zunächst, er wird bei näherer Betrachtung der Arbeitsweise der Anwendung jedoch verständlich. Die Anwendung ist für die Datenpflege ausgelegt und objektorientiert programmiert. Während der Instanziierung der Knotenobjekte und weiterer abhängiger Datenobjekte erfolgen satzweise Lesezugriffe auf die Datenbank. Der Aufwand für die Ausführung eines Statements ist bei HANA jedoch derzeit vermutlich noch etwas höher als bei klassischen Datenbanken [siehe auch: Thorsten Schneider, Eric Westenberger, Hermann Gahm: ABAP Entwicklung für SAPHANA; Galileo Press, Bonn 2013].
Die Optimierung der Anwendung erfolgt durch folgende Ansätze:
- Umstellen vieler Einzel- auf wenige Mengenoperationen
- Verlagern von Anwendungslogik in die Datenbankschicht (Code Pushdown)
Um die Einzeloperationen durch Mengenoperationen ersetzen zu können, wird die Logik der Anwendung umgestellt.
Der Zeitpunkt der Instanziierung der Knoten- und Datenobjekte wird vom Zeitpunkt der Strukturauflösung und Datenbeschaffung entkoppelt.
Das bedeutet:
- Die Instanziierung und die damit verbundene Bereitstellung von Prüf- und Verarbeitungslogik erfolgt erst dann, wenn der Benutzer Eingaben auf dem UI vorgenommen hat. Sie wird nicht pauschal für alle Datensätze ausgeführt, sondern nur im Bedarfsfall für diejenigen, die der Benutzer ändert.
- Die Datenbeschaffung zur erstmaligen Anzeige der Daten kommt hingegen ohne weitere Logik aus und bedient sich direkter Mengenzugriffe auf die Datenbank.
Mit der beschriebenen Umstellung werden auf beiden Datenbanksystemen bereits sehr gute Performancegewinne erzielt, wobei sich nun das Verhältnis zugunsten von HANA umkehrt. Die HANA Anwendung ist über beide Testfälle hinweg etwa doppelt so schnell wie die Anwendung auf der X-DB.
Während sich der erste Optimierungsschritt ausschließlich der Möglichkeiten des ABAP Open SQL bedient, erfolgt ein weiterer Optimierungsschritt unter Verwendung nativer HANA Anweisungen.
Die Logik der schrittweisen Strukturauflösung wird dabei aus der ABAP-Anwendung in die Datenbank verlagert. Das geschieht durch Definition einer Datenbankprozedur in HANA, die aus der Anwendung heraus über einen sogenannten Datenbankprozedur Proxy und der ABAP Anweisung CALL DATABASE PROCEDURE angestoßen wird. Die Auflösung der Struktur erfolgt mit dieser Methode innerhalb eines Datenbankzugriffs, während bei der ABAP-gesteuerten Auflösung in den Test-Beispielen 7 Datenbankzugriffe ergeben.
Durch die beschriebene Verwendung der Datenbankprozedur zur Strukturauflösung ergibt sich ein weiterer Performancegewinn gegenüber der ABAP-gesteuerten Auflösung, der bei der großen Struktur mit 4451 Knoten etwas 1,5 s erreicht. Die Beschleunigung an dieser Stelle ist zudem nicht ausgereizt, auch das momentan noch nachträglich ausgeführte Lesen der Knotenattribute ließe sich in die Datenbankprozedur integrieren, wodurch weitere Performancegewinne zu erwarten sind.
Fazit
Durch Verwendung der In-Memory-Datenbank HANA anstelle einer klassischen X-DB lässt sich eine Anwendung zur Massenverarbeitung signifikant beschleunigen. Voraussetzung dafür ist, dass die Regeln für perfomante Datenbankzugriffe mit ABAP Open SQL eingehalten werden. Weitere Performancegewinne lassen sich durch Anwendung nativer Programmiertechniken in HANA erzielen. Im gezeigten Beispiel der PCC Strukturauflösung fallen sie noch stärker ins Gewicht, wenn tiefere Strukturen als die hier verwendeten 8-stufigen Strukturen angewendet werden. Ein weiteres Potential bietet die Integration momentan noch nachgelagerter Datenbankzugriffe in die Datenbankprozedur der Strukturauflösung.
