ABAP oder AMDP? Diese Frage stellen sich viele Kunden bei der Verwendung von HANA-basierten Systemen. In diesem Blog zeigen wir Vor- und Nachteile der beiden Ansätze auf und geben eine Entscheidungshilfe für zukünftige Implementierungen.
Was ist AMDP?
In unserem vorherigen Blog zu SQLScript sind wir darauf eingegangen, wie HANA ein Tor zu neuen Modellierungen öffnet. Durch die datenbanknahe Entwicklung wird die gesamte Stärke der In-Memory Datenbank ausgeschöpft.
SAP hat für die Verwendung von SQLScript eine Erweiterung in ABAP eingebaut: ABAP Managed Database Procedures (AMDP). Hierbei handelt es sich um Datenbankprozeduren oder -funktionen, die über ABAP erstellt, verwaltet und transportiert werden. SAP ermöglicht somit ein Fenster in die Welt von SQLScript, ohne direkt auf die Datenbank herabsteigen zu müssen.
Doch viele Kunden stehen nun vor einer zentralen Frage: ABAP oder AMDP?
AMDP vs. ABAP: Das sind die Unterschiede
Das Wichtigste zuerst: ABAP ist nicht obsolet! Es ist und bleibt integraler Bestandteil von Systemen wie S/4HANA und BW/4HANA. Deutlich wird die Relevanz auch durch ABAP Steampunk, der Zukunft von ABAP in der Cloud.
Allerdings stellt sich nun weiterhin die Frage, welche Programmiersprache bei Datenbankverarbeitungen eingesetzt werden soll. Doch wo liegt eigentlich der Unterschied zwischen den beiden Technologien?
Bei ABAP werden alle Daten zunächst aus der Datenbank in den Applikationsserver geladen. Dabei ist es immer wichtig, den Datenfluss zwischen den Systemen (Traffic) gering zu halten, da hier wertvolle Zeit verloren geht. Anschließend wird mit den Daten in internen Tabellen weitergearbeitet.
AMDP auf der anderen Seite hat dieses Problem nicht, da es direkt auf der Datenbank lebt und keinen Traffic verursacht. Somit können Tabellen direkt miteinander verbunden werden, ohne Umwege zu gehen.
ABAP kann zwar AMDP-Methoden aufrufen (siehe Blog), umgekehrt ist es jedoch nicht möglich: SQLScript hat keine Verbindung zu ABAP, da es nativ in der HANA-Datenbank sitzt. Gerade bei BW Transformationen oder ABAP CDS Views muss am Anfang entschieden werden, ob mit AMDP gearbeitet werden soll.
AMDP Beispiele
Im Folgenden werden wir uns konkreten Beispielen widmen, wie AMDP im Vergleich zu ABAP funktioniert und implementiert werden kann.
AMDP Lookup
Schauen wir uns die beiden Technologien an einem simplen Beispiel an: Wir befinden uns in der Endroutine einer BW-Transformation. Ziel ist es, einen Lookup auf Stammdaten zu realisieren.
Mit ABAP ist es das Ziel, den Datenfluss zwischen den Systemen zu minimieren, weswegen oft Prefetch-Tabellen verwendet werden. Das Vorgehen ist dabei folgendes:
- Erstellung Typen für Prefetch- und Lookup-Tabelle
- Füllen der Prefetch-Tabelle
- Selektion der relevanten Datensätze aus der Stammdatentabelle
- Loop über Result Package mit Read-Statement auf Hashed Tabelle
Das ABAP Coding für den Lookup hat folgende Form:
Abbildung 1: ABAP Lookup mit LOOP
Mit ABAP 7.4 wurde der neue VALUE-Befehl eingeführt, der Loops in den meisten Fällen ersetzt. Ein entsprechendes Coding kann dem nächsten Bild entnommen werden (ohne Typdefinition):
Abbildung 2: ABAP Lookup mit VALUE
Häufig werden Lookups auch über Klassenmethoden implementiert, wobei der Konstruktor die Stammdaten in eine interne Tabelle befüllt und weitere Get-Klassenmethoden für die Attribute existieren. Egal ob klassisch mit Loop, modern mit VALUE-Befehl oder über eine Klassenmethode: ABAP benötigt relativ viele Befehle für einen performanten Lookup.
Mit AMDP sieht das Coding komplett anders aus:
Abbildung 3: AMDP Lookup
Warum ist das AMDP Coding so viel schlanker? Da wir uns direkt auf der Datenbank bewegen, werden keine Prefetch oder andere interne Tabellen benötigt, da es keinen Traffic zwischen Datenbank und Applikationsserver gibt. Die Daten können direkt verbunden werden.
AMDP IF-Statement
ABAP Programme bestehen oft aus vielen Verzweigungen durch IF-Statements. Durch diesen Ansatz können viele verschiedene Fälle abgefangen und es kann unterschiedlich reagiert werden. So können Daten für ein Feld aus mehreren Tabellen stammen, die in unterschiedlichen Reihenfolgen abgearbeitet werden. Das Coding soll folgende Logik abbilden:
- Suche nach Header-Daten
- Wenn Header-Daten nicht gefunden werden, Dummy-Werte setzen für Kundennummer und Stadt
- Wenn Header-Daten gefunden werden, Kundennummer setzen
- Suche nach Stadt über Kundenstammdaten
- Wenn Daten nicht vorhanden, dann in alternativer Stammdatentabelle schauen, sonst Dummy setzen
- Wenn Kundenstammdaten vorhanden, Stadt direkt setzen
- Abhängig vom dritten Buchstaben der Stadt die Region bestimmen
Bei folgendem Coding haben wir die Befüllung der internen Tabellen weggelassen.
Abbildung 4: IF mit ABAP
Bei einer AMDP Implementierung der Logik wird oft versucht, die genaue LOOP- und IF-Struktur des ABAP Codings zu übernehmen. Allerdings ist die Verwendung von imperativer Ablauflogik in SQLScript bzw. AMDP nicht optimal und sollte vermieden werden.
Ein besserer Ansatz ist, die verwendete Anforderung umzuschreiben, sodass sie mit aufeinander aufbauenden SELECT-Statements und temporären Tabellen direkt ausgeführt werden kann. Auch hier haben wir das Coding um die Befüllung der temporären Tabellen abgekürzt.
Abbildung 5: „IF“ mit AMDP
Durch die Verwendung von CASE, COALESCE bzw. IFNULL und mehreren Joins können wir die verschachtelte Abfrage direkt in einem SELECT-Statement umsetzen. Die weitere Logik auf das abgeleitete Stadt-Feld wird in eine weitere temporäre Tabelle ausgelagert.
Dieses Beispiel zeigt sehr deutlich, dass eine 1:1 Übersetzung von dem ABAP Code kein geeigneter Ansatz ist und somit ein Grundverständnis von SQLScript essenziell für die Erstellung von AMDP Skripten benötigt wird.
AMDP Formatierung
Eine große Herausforderung bei der Harmonisierung von Daten liegt in deren Manipulation zur Bereinigung der Inhalte dieser Daten. Dabei werden häufig Zeichenketten oder Strings so verändert, dass sie aus verschiedenen Quellsystemen zusammenpassen. Typische Operationen sind:
- ALPHA-Konvertierung
- Großschreibung
- Herausfiltern von unerlaubten Zeichen
- Entfernung von Leerzeichen
Mit ABAP können all diese Tätigkeiten sehr bequem über Standardfunktionen realisiert werden, da ABAP es leicht ermöglicht über die einzelnen Zeichen eines Strings zu iterieren und diese zu prüfen.
Wie im vorherigen Beispiel ist es nicht zielführend, diese Logik mit AMDP 1:1 zu übersetzen. An dieser Stelle ist es unabdingbar, sich mit den gegebenen SQLScript Funktionen für String Manipulationen auszukennen, wie die folgende Abbildung zeigt:
Abbildung 6: Formatierung AMDP
Erwähnenswert hierbei sind die sehr mächtigen regulären Ausdrücke. Über die eigene Syntax können hochkomplexe String-Manipulationen realisiert und mit SQLScript-Funktionen verbunden werden. Beispielweise kann die Liste der erlaubten Zeichen über eine Tabelle in eine deklarierte Variable geschrieben und dann für die Negation im regulären Ausdruck verwendet werden.
AMDP Analytische Funktionen
AMDP zeigt sein wahres Potenzial bei der Anwendung von analytischen Funktionen auf große Datenmengen. Hierfür schauen wir uns folgendes Beispiel an: Wir haben eine Tabelle mit Rechnungsinformationen (Kunde, Datum, Position, Anzahl Artikel). Nun interessieren uns zwei Dinge:
- Was ist die Gesamtanzahl an Materialien pro Rechnung?
- Hat der Kunde mit der nächsten Rechnung mehr oder weniger gekauft?
Die folgende Abbildung zeigt eine mögliche Umsetzung mit ABAP. Es sei erwähnt, dass es mit COLLECT oder VALUE eine Vielzahl an Implementierungsmöglichkeiten gibt.
Abbildung 7: Analytisch mit ABAP
Auch bei diesem Beispiel besteht das ABAP Coding aus einer Vielzahl von Befehlen und IF-Abfragen. Es muss geprüft werden, ob die nächste Zeile der Tabelle existiert und ob diese zum Kunden gehört sowie entsprechend reagiert werden.
Wie bei den anderen Beispielen sieht eine Implementierung mit AMDP völlig anders aus.
Abbildung 8: Analytisch mit AMDP
Zunächst werden die Ausgangsdaten direkt über GROUP BY aggregiert und somit die Anzahl aller Rechnungspositionen pro Rechnung einfach und effizient bestimmt. Im zweiten Teil wird über die analytische Funktion LEAD der Wert auf der nächsten Zeile bestimmt. Dabei bestimmt der PARTITION BY-Befehl, wie das Fenster definiert ist: In diesem Fall über die Kundennummer.
AMDP oder ABAP?
Nach diesen Beispielen steht allerdings weiter die Frage offen, welche der beiden Technologien wann eingesetzt werden sollte. Dabei konnten die diversen Beispiele zeigen, dass eine direkte Übersetzung von ABAP nach AMDP vermieden werden sollte.
Für die Entscheidungshilfe bieten wir nachfolgend eine Reihe von Fragen an, die helfen sollen, die ideale Lösung zu finden. Dabei ist der erste und wichtigste Schritt, die genauen Anforderungen des Codings zu bewerten und zu verstehen. Sowohl ABAP als auch AMDP haben ihre Stärken, dennoch, wie so oft, ihre Schwächen, je nach Anwendungsfall.
- Wie groß ist das Datenvolumen?
- ABAP kann bei geringen Datenmengen sogar schneller sein
- In Kundenprojekten hat sich AMDP bei mehr als 1 Mio. Datensätze bewährt
- Wie ist der Support aufgestellt oder das SQLScript Knowhow?
- ABAP ist im SAP-Umfeld eine sehr gut verstandene Sprache
- ABAP ist sehr viel komfortabler bei der Fehlersuche (Debugging)
- AMDP ist durch SELECT-Statements nur schwer zu debuggen
- Gibt es Anforderungen, die AMDP nicht möglich machen?
- Verwendung von Standard ABAP-Klassen oder Funktionsbausteinen
- Schreiboperationen in BW-Transformationen (AMDP ist dort read-only)
- Generische Programmierung (SQLScript-EXEC ist kein Ersatz)
- Komplexität der Datenverarbeitung
- AMDP bietet mächtige analytische Funktionen mit sehr hoher Geschwindigkeit
Fazit
Es gibt keine goldene Regel oder Herleitung für die Entscheidung, welche Technologie eingesetzt werden soll. Jede Entwicklung benötigt eine Analyse der Anforderungen und Abwägung, ob ABAP oder AMDP besser geeignet ist. AMDP ermöglicht eine neue Art der Modellierung und kann große Performance-Verbesserungen ermöglichen, allerdings kann gerade bei geringen Datenmengen ABAP schneller und Support-freundlicher sein.
Diese Herausforderung sollte als Chance angesehen werden, optimale und zukunftsfähige Entwicklungen auf den HANA-basierten Systemen zu realisieren.