SAP HANA in der Praxis - Mehrwert durch ABAP Erweiterungen

Unser Kunde – ein deutscher Versicherer – führt aktuell die „SAP Business Suite on HANA“ ein. Die Entwicklungssysteme wurden bereits auf HANA umgestellt, die QS-Systeme folgen in Kürze. Mit der Umstellung auf die HANA Datenbank stellten sich für uns die Fragen für welche Anforderungen sich HANA mit ABAP-Erweiterungen eignen und wie aufwendig einzelne Lösungen im Vergleich sind. Und natürlich ob ggf. der „Teufel im Detail“ eine Umstellung bestehender Programme verhindert oder nicht praktikabel erscheinen lässt. Für einen Vergleich haben wir aktuelle – bis dahin nicht-HANA ABAP-Entwicklungen aus einem parallelen Projekt im SAP FS-CD Maklerinkasso herangezogen. 

Ausgangssituation

Für den Kunden steht bei der HANA Einführung die Umstellung auf die HANA DB im Vordergrund. Das Projekt hat daher einen technischen Charakter und soll die Basis für zukünftige Vorhaben legen. Die Umstellung beinhaltet keine Optimierung kundeneigener Anwendungen und Code pushdown zur Performance Verbesserung sind nicht vorgesehen. Grundsätzlich soll die Performance der Abläufe durch die HANA Migration nicht beeinträchtigt werden.

Zusammengefasst: Die „Suite on HANA Einführung“ ist eine reine Datenbank-Migration

  • Austausch der bestehenden Datenbank gegen eine HANA DB
  • Der SAP ERP ECC Kern (Enterprise Core Components) bleibt bestehen
  • SAP FS-CD bleibt bestehen 
  • Alle Anwendungen laufen – funktional – weiter wie zuvor

Für diese Datenbank-Migration wurden die projektübergreifenden Entwicklungsrichtlinien für HANA konforme Entwicklung angepasst und entsprechende Prüfvarianten für die automatisierte Codeprüfung aktiviert. Wie üblich sind die zwingend notwendigen ABAP Programmkorrekturen hinsichtlich Abhängigkeiten von spezifischen Datenbankeigenschaften, z.B. Indizes, Sortierung und die empfohlenen SQL Performance Verbesserungen in den bestehenden Kundenerweiterungen durchgeführt worden.

Vorbemerkung zu den Beispielen

Um die Orientierung und das Verständnis zu erleichtern haben wir zum Teil technische Details, wie z.B. bekannte Tabellennamen und SAP Module genannt. ABAP, SQL Sprachelemente und ABAP Dictionary Elemente und Namen sind der besseren Lesbarkeit und Unterscheidbarkeit in Großbuchstaben geschrieben.

Zur Übersicht hier ein Auszug wichtiger Erweiterungen:

  • Core Data Services (CDS)
  • ABAP Managed Database Procedures (AMDP)
  • Open SQL
  • ALV with Integrated Data Access (IDA)
  • Application Function Library (AFL)

Bei den nun folgenden Beispielen standen für uns immer diese Fragen im Mittelpunkt:

  • Lässt sich die Verarbeitung beschleunigen?
  • Können größere Datenmengen bearbeitet bzw. dargestellt werden?
  • Lässt sich die Lesbarkeit bzw. Wartbarkeit der kundeneigenen Entwicklung verbessern?

BEISPIEL1:
Dialog für neues  Stammdatenobjekt

Für die Erstellung von interaktiven Reports und Dialogen setzt der Kunden vorgefertigte ABAP Vorlagen ein, die unter anderem auf dem ALV Grid und ALV Tree basieren. In einen kundeneigenen Stammdatendialog für ein neues Objekt im SAP FS-CD Umfeld haben wir eine der Vorlagen verwendet um den Dialog zu implementieren. Das Objekt hat eine „handvoll“ Attribute und wird in einer Datenbanktabelle persistiert. Der Dialog erlaubt die Erfassung, Aktualisierung und Auswertung.

Ergebnis:
Das Objekt hat maximal wenige hundert Ausprägungen. Große Datenmengen und Antwortzeiten sind also keine Themen bei dieser Implementierung. Praktisch bietet sich der Einsatz der oben erwähnten neuen ABAP Features nicht an.

BEISPIEL 2:
Migration von Stammdaten der Aufbauorganisation

Die Aufbauorganisation des Unternehmens, d.h. die aufgabenbezogene, funktionale Struktur wird mit der Komponente SAP-Organisationsmanagement (PD-Org) abgebildet. Auch für Prozesse im SAP FS-CD und SAP FS-ICM nutzt der Kunde diese Abbildung in der PD-Org. Die Organisationseinheiten z.B. Abteilungen und Planstellen sind dort abgebildet sowie die hierarchischen Beziehungen. Ein Ausschnitt der Aufbauorganisation ist noch nicht in der Komponente PD-Org, sondern in einem Vorsystem. Dieser fehlende Ausschnitt soll nun im Rahmen der Migration übernommen werden.

Zunächst wird geprüft, ob die Organisationseinheit des Vorsystems im Zielsystem bekannt ist und die Eigenschaften validiert und ggf. im Reporting Abweichungen gemeldet. 

Die Extraktion, Transformation und Load wird im Kundennamensraum entwickelt.

Für die Validierung werden SAP Standard Funktionen des PD-Org Organisationsmanagement angesteuert. Diese Funktionen lesen die Strukturen und suchen gemäß Parametern die Daten aus der Hierarchie. Dabei werden die strukturellen Berechtigungen geprüft, also ob auf eine spezifische Orga-Einheit lesend zugegriffen werden darf. Die Aufbauorganisation wird entlang eines im PD-Org Customizing eingestellten Auswertungsweges analysiert.

Der lesende Zugriff auf die PD-Org Daten ist komplett durch die SAP Standard Funktionen gekapselt. Diese Standard Funktionen und die darunterliegenden Datenbanktabellen z.B. HRP1000 und HRP1001 sind noch nicht HANA optimiert. Ein direkter Zugriff via Open SQL ist nicht gewünscht und technisch – Stichworte Customizing, strukturelle Berechtigungsprüfung – nicht trivial.

Der schreibende Zugriff auf die PD-Org Daten wird durch SAP Standard Servicefunktionen des SAP FS-ICM Provisionsmanagement durchgeführt.

Ergebnis:
Optimierungen sind im Organisationmanagement erst möglich, wenn auf HANA angepasste Servicefunktionen eingesetzt werden. Optimierung im kundeneigenen Namensraum sind in diesem Anwendungsfall nicht möglich.

BEISPIEL 3:
BDT Erweiterung Versicherungsobjekt

Das Versicherungsobjekt wurde um weitere Attribute ergänzt. Die Änderungen in den Stammdatendialogen wurden im Business Data Toolset hinzugefügt.

Dabei wurde für ein Attribut im frühem Stadium großzügige Annahmen über die notwendige Feldlänge gemacht und auch implementiert. Später wurde die Feldlänge gekürzt. Dementsprechend war eine nachträgliche Anpassung der Feldlänge in den Datenbankstrukturen notwendig.

Eine Anpassung der Tabelle ist in vielen Fällen schnell gemacht, wenn die Änderung mit einem ALTER TABLE SQL Befehl mit dem Datenbank Utility im ABAP Dictionary erreicht werden kann.

Für die Kürzung der Feldlänge und gleichzeitigen Erhalten der Daten ist eine Tabellenumsetzung nötig, die in einzelnen Schritten angefangen mit dem Setzen einer Sperre gegen weitere Änderungen, Erzeugen der Tabelle mit der geänderten Struktur und Indizes, Kopieren der Daten in die neue Tabelle, Löschen der alten Tabellen und Umbenennen der neuen Tabelle endet.

Eine Tabellenumsetzung zählt genauso wie das Erstellen eines Index zu den I/O-intensiven Datenbankoperationen. Diese Operationen können in Produktion für große Objekte, prominentes Beispiel ist die Tabelle Belegsegment des Hauptbuchs BSEG, in der die Buchhaltungsbelege gespeichert werden, schon einmal mehrere Stunden oder Tage dauern.

Ergebnis:
Wir waren positiv überrascht, dass die Umsetzung der Tabelle mit immerhin mehreren Millionen Sätzen auf der HANA DB in wenigen Sekunden abgeschlossen war und bis auf einen kleinen ‚Schluckauf‘ – nahezu unbemerkt durch die Kollegen in der Entwicklerecke – über die Bühne ging.

BEISPIEL 4:
Auswertung der Änderungsbelege des Versicherungsobjektes

Für einen maschinellen Abgleich wird eine Auswertung der Änderungsbelege der Versicherungsobjekte benötigt. Innerhalb eines Betrachtungszeitraumes sollen spezifische Änderungen – jeweils die letzte Änderung eines spezifischen Attributes/Feldes – ermittelt werden.

Das Ergebnis der Auswertung wird primär als Arbeitsvorrat für einen maschinellen Abgleich benötigt. Zu Kontroll- und Testzwecken soll die Auswertung optional als SAP ALV angezeigt werden.

In diesem Anwendungsfall müssen weder SAP Servicefunktionen genutzt werden noch ein technischer Rahmen wie das BDT. Somit bestehen auch keinerlei Einschränkungen hinsichtlich Einsatz von HANA Techniken: CDS Views, Erweiterungen des OPEN SQL, ABAP Managed Database Procedures und ALV with IDA könnten hier verwendet werden.

Die Pool- und Clustertabellen werden durch die Umstellung auf HANA in transparente Tabelle umgewandelt. Das trifft auch auf die Positionstabelle der Änderungsbelege CDPOS zu. Ein Datenbank JOIN zwischen der Kopf- (Tabelle CDHDR) und Positionstabelle der Änderungsbelege ist nun möglich. In diesem Fall war ein einfacher INNER JOIN ausreichend und dementsprechend kann der JOIN wahlweise im ABAP Dictionary, als CDS View oder im OPEN SQL formuliert werden. Dabei unterscheidet sich die CDS Variante nicht in Bezug auf Ausführungsgeschwindigkeit, sondern nur in dem Freiheitsgrad bezüglich der Definition des Views an sich. Ein CDS View – bei gleichartiger Definition – ist im Vergleich zum klassischen View nicht ‚automagisch‘ schneller.

Das Anwendungsbeispiel eignet sich auch um AMDP – ABAP managed Database Procedure zu verwenden: Der JOIN der Kopf- und Positionstabelle der Änderungsbelege selektiert alle relevanten Änderungen innerhalb des Zeitraumes. Das Ergebnis des JOINS reduziert man mit zwei aufeinanderfolgenden SELECT Operationen auf die letzte Änderung pro Versicherungsobjekt. 

Wenn ich jeden Schritt dieser Sequenz mittels SQL implementiere, hätte ich „prä-HANA“ jeweils die Ergebnismengen zwischen Applikation und Datenbank bewegen müssen.

Der Datentransfer zwischen den Schritten ist mit HANA unnötig: alle 3 Schritte können in einer AMDP Methode hintereinander ablaufen und nur das Ergebnis des letzten Schrittes zur Applikation transportiert werden.

Auch hier gilt wieder wie schon beim CDS View: Um einen Vorteil gegenüber der klassischen ABAP Lösung zu erreichen reicht es nicht ein einzelnes SQL Statement in eine AMDP Methode „push down“ zu verschieben. Im Gegenteil, der Overhead für die AMDP Methode würde die Laufzeit insgesamt verlängern.

Idealerweise ersetzt man in einer Sequenz von Datenoperationen alle ABAP Anweisungen durch SQL Operationen und bündelt diese in einer AMDP. So spart man – erstens – mehrfachen Transfer der Daten zwischen HANA und dem Applikationsserver und – zweitens – man ersetzt langsame ABAP Operationen auf große Datenmengen durch schnelle SQLs.

Oder wie es SAP zur In-memory Datenverarbeitung (HANA!) formuliert:

  • Vermeiden (unnötigen) Datentransfer von großen Datenmengen (zwischen Datenbank und Applikation)
  • Datenintensive Berechnungen und Operationen in der Datenbank ausführen

Die optionale Anzeige des Ergebnisses kann auch mit dem „ALV with IDA“ implementiert werden. Bei der IDA Version werden die Daten nicht vorab selektiert und dann per Referenz auf die interne Tabelle übergeben, sondern jeweils nach Bedarf direkt aus der Datenbank nachgelesen.

Ergebnis:
Auch bei großen Datenmengen, getestet haben wir mit mehr als 70.000 Datensätzen, zeigt die IDA Version die Ergebnisse von Sortier- Filter- und Gruppierungsfunktionen „auf Tastendruck“ sofort an – beeindruckend !

Fazit

Einige Verbesserungen kommen frei Haus. Technologisch basieren diese nicht immer auf HANA. Die Umstellung der Cluster/Pooltabellen gehört dazu. Die Entwicklung wird vereinfacht und bessere Performance kann mittels JOIN per CDS oder klassischen ABAP View erreicht werden.

Die Geschwindigkeit der In-Memory Datenbank zeigt sich auch bei Randthemen wie dem Change Management. Strukturelle Änderungen an den großen SAP FS-CD Tabellen die zu Tabellenumsetzungen führen sollten immer noch gut begründet und geplant werden. Beim Transport in die Qualitätssicherungssysteme wird der ein oder andere Kollege in der Administration schon seinen Spaß an den kurzen Aktivierungszeiten haben.

Eine Aufgabenstellung, die die Verarbeitung von großen Datenmengen erfordert und dabei kurze Antwortzeiten erwartet, ist prinzipiell ein Kandidat für Optimierung. Ob es gelingt mit den vorgestellten ABAP Erweiterungen zu Punkten hängt wie wir gesehen haben von mehreren Faktoren ab:

  • Können die Daten unmittelbar per SQL Statement erreicht werden oder sind die Daten über Standard Servicefunktionen oder ein Framework gekapselt, die noch nicht HANA optimiert sind
  • Lassen sich langlaufenden ABAP Loops über Datenmengen in eine Sequenz von SQL Operation umsetzen
  • Kann der Datentransfer zwischen HANA und Applikationsserver durch code pushdown reduziert werden 

Welchen Unterschied eine HANA Optimierung des SAP Standards – hier ALV – für den Anwender bedeuten kann, zeigt ALV with IDA. Die Antwortzeiten im Dialog mit großen Datenmengen sind bemerkenswert. Die IDA Version nutzt den Geschwindigkeitsvorteil beim code pushdown von Rechenoperationen, der sich hier sehr schön anhand der Standard Summierungsfunktion auf Mengen- oder Betragsspalten zeigen lässt. Ein tolles Tool um sich in der Fachabteilung beliebt zu machen.

Wer sich näher mit den Ideen die hinter der HANA Architektur stehen beschäftigen möchte und auch einen Ausflug in die Entstehungsgeschichte nicht scheut, sollte einmal die Seite des HPI aufsuchen. Das Hasso-Plattner-Institut bietet zum Thema einen Kurs an, In-Memory Data Management, der bemerkenswerterweise vom Gründer des Instituts selbst gelesen wird. Für Hands-on Eindrücke und kleineren Fingerübungen in der HANA Entwicklungsumgebung ist der openSAP Kurs ABAP Development for SAP HANA geeignet.   

WAS FEHLT NOCH….

An den nächsten ABAP Versionen wird gearbeitet und man kann erwarten, dass das Zusammenspiel zwischen ABAP und HANA kontinuierlich verbessert wird. Sobald man an schreibendende Datenoperationen denkt, fallen einem unter anderem Sperren und eindeutige Schlüssel ein. In der aktuellen Product Roadmap wird darauf nicht eingegangen allerdings wurde tatsächlich in einem Lab Preview diese Operationen unter dem Stichwort service pushdown angekündigt:

  • Nummernkreise
  • Systemgenerierte eindeutige IDs (GUIDs)
  • SAP Datenbanksperren (Enqueue, Dequeue)

QUELLEN

open.hpi.de: In-Memory Data Management 2015/7

open.sap.com: ABAP Development for SAP HANA 09/2014

SAP Blogs

SQL Script Referenz

Note 2217050 – SAP LT V2: De- Clustered table on HANA DB