ABAP Entwicklung unter SAP HANA: SQLScript
Um SAP HANA's Performancepotential optimal auszunutzen, sind einige Performanceoptimierungen nötig. SQLScript hilft Ihnen dabei. Aber was ist das eigentlich?
“Three things are important in the database world:
performance, performance, and performance”
(Bruce Lindsay, IBM)
SAP R/3 Systeme unterstützen unterschiedliche Datenbanksysteme wie DB/2, Oracle oder MaxDB zur Datenhaltung. Datenbankunabhängiger Zugriff wird ermöglicht durch den SQL Dialekt “OpenSQL” welcher in ABAP Code eingebunden und von dort ausgeführt werden kann. Diese Flexibilität wird künftig “geopfert” zugunsten des neuen ERP-Systems SAP S/4 HANA, denn SAP hat angekündigt zum Jahr 2025 den Support für R/3 Systeme einzustellen.
SAP S/4 HANA ist optimiert für die effiziente Nutzung der Hauptspeicherdatenbank SAP HANA, was den Anwendern einen enormen Performancegewinn verspricht. SAP HANA wurde 2012 veröffentlich und ist seitdem eine der schnellsten und vielseitigsten Datenbanken auf dem Markt.
Ein Grund dafür ist, dass sämtliche Daten ausschließlich im Hauptspeicher eines Datenbanksystems vorgehalten werden, was mindestens einen 100fach schnelleren Datenzugriff ermöglicht. Außerdem ist SAP HANA optimiert für aktuelle Rechnerarchitekturen mit großem Arbeitsspeicher und vielen Prozessorkernen, wodurch eine stark parallelisierte Durchführung komplexer Berechnungen direkt auf der Datenbankebene möglich wird.
Mit der Einführung dieser Datenbank ändern sich auch die Spielregeln für die Programmierung. Zwar ist das alte Coding auch ohne Anpassungen auf SAP HANA lauffähig, dennoch sollten einige Optimierungen vorgenommen werden um das Performancepotential von SAP HANA bestmöglich auszuschöpfen.
Was läuft anders unter SAP HANA?
Allgemein läuft Datenbankprogrammierung mit relationalen SQL-Datenbanken nach einem bestimmten Schema ab:
- SQL Abfragen werden formuliert und zusammen mit dem ABAP Code auf dem Applikationsserver ausgeführt.
- Der Applikationsserver leitet die Abfragen an das Datenbanksystem weiter, wo sie optimiert und ausgeführt werden.
- Das Ergebnis der Abfrage wird dann zurück an die Applikation geleitet, wo weitere Berechnungen mit den Daten passieren können.
Um das Datenbanksystem zu entlasten wurde bisher vermieden, komplexe Berechnungen auf der Datenbank auszuführen. So wurden lediglich Daten abgefragt und die Berechnungen auf der Applikationsebene durchgeführt. Dieses Bild ändert sich nun unter SAP HANA. Da die Datenbank für das parallele Ausführen komplexer Berechnungen optimiert ist, sollten Berechnungen nicht mehr auf Applikations- sondern auf Datenbankebene durchgeführt werden. Dieses Vorgehen ist auch als “Code pushdown” bekannt. Lediglich die Ergebnisse einer Berechnung werden dann an die Anwendung zurückgeliefert. Der Flaschenhals wandert somit von der Datenbank zur Applikation.
Als Konsequenz sollte bestehendes Coding, welches Datenbankabfragen enthält, angepasst werden. Zum Beispiel sollten Berechnungen in SQL Queries verpackt werden statt sie in der ABAP-Anwendung durchzuführen. Dazu hat SAP den datenbankunabhängigen Dialekt “Open SQL” um Aggregationen (z.B. SUM) und Kontollflusskonstrukte (z.B. CASE, IF-ELSE) erweitert. Auch wenn es ein wichtiger Schritt in Richtung Code pushdown mit Open SQL ist, ist diese Fähigkeit leider auf wenige Operatoren und Konstrukte limitiert.
Funktionen wie z.B. Währungsumrechnung, welche mit SAP HANA ausgeliefert werden, können beispielsweise in Open SQL nicht genutzt werden. Dazu müsste man den HANA-eigenen SQL-Dialekt benutzen. Leider gibt es für HANA SQL keine native Unterstützung in ABAP, sodass HANA-SQL Abfragen dynamisch in einer EXEC-Umgebung ausgeführt werden müssten. Dieses Vorgehen sollte jedoch zugunsten der Portabilität des Codings vermieden werden.
Um dieses Problem zu umgehen, hat SAP HANA-SQL imperative und funktionale Sprachkonstrukte erweitert und somit eine eigene Scriptsprache zur Datenbankprogrammierung entwickelt: SQLScript. Damit wird es möglich HANA-SQL Code in ein Script zu integrieren, welches direkt auf der Datenbank ausgeführt wird. Das Prinzip der datennahen Ausführung nennt man auch “code-to-data” Paradigma wie in der folgenden Abbildung dargestellt:
Quelle: SAP
Und wie wird SQLScript in die ABAP Landschaft integriert?
Auch hier hat SAP Abhilfe geschaffen und ABAP Managed Database Procedures (AMDP) und CDS Views eingeführt, die SQLScript Code kapseln. AMDP sind spezielle ABAP Prozeduren, die mit SQLScript programmiert werden aber wie ganz normale ABAP Prozeduren aufgerufen werden können. CDS Views sind programmierbare Sichten auf Daten, welche wie Tabellen in SQL Queries eingebunden werden können. Der Vorteil von CDS Views ist, dass sie wie AMDP mit SQLScript programmiert werden, von außen aber wie normale Tabellen verwendet werden können.
Muss man jetzt eine ganz neue Sprache lernen?
SQLScript ist syntaktisch an ABAP angelehnt. Außerdem können HANA SQL Abfragen direkt integriert werden. Das Ganze in bekanntes ABAP Coding verpackt bietet eine sehr niedrige Einstiegsschwelle in SQLScript.
Für eine bessere Übersicht über die Integration von SQLScript in ABAP sowie über die SQLScript Syntax, haben wir im Folgenden ein kleines Beispiel aufbereitet (Quelle: https://help.sap.com/doc/abapdocu_750_index_htm/7.50/en-US/abenamdp_abexa.htm)
Definition der AMDP increase_price_clnt:
METHOD increase_price_clnt BY DATABASE PROCEDURE FOR HDB
LANGUAGE SQLSCRIPT
USING sflight.
IF :inc > 0 AND :clnt > 0
THEN
UPDATE sflight SET price = price + :inc WHERE mandt = :clnt;
END IF;
ENDMETHOD.Demo Report:
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA clnt TYPE abap_bool.
DATA incprice TYPE sflight-price.
DATA price_before TYPE sflight-price.
DATA price_after TYPE sflight-price.
IF NOT cl_abap_dbfeatures=>use_features(
EXPORTING
requested_features =
VALUE #( ( cl_abap_dbfeatures=>call_amdp_method ) ) ).
cl_demo_output=>display(
`Current database system does not support AMDP procedures` ).
RETURN.
ENDIF.
cl_demo_input=>add_field( CHANGING field = incprice ).
cl_demo_input=>add_field(
EXPORTING
as_checkbox = abap_true
text = `Use session client`
CHANGING
field = clnt ).
cl_demo_input=>request( ).
IF incprice IS INITIAL.
RETURN.
ENDIF.
SELECT SINGLE price FROM sflight INTO price_before.
TRY.
NEW cl_demo_amdp( )->increase_price_clnt(
clnt = sy-mandt
inc = incprice ).
CATCH cx_amdp_error INTO amdp_error.
cl_demo_output=>display( amdp_error->get_text( ) ).
RETURN.
ENDTRY.
SELECT SINGLE price FROM sflight INTO price_after.
IF price_after - price_before = incprice.
cl_demo_output=>display( `Price increased successfully` ).
ENDIF.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).
Die Prozedur increase_price_clnt ist eine Methode der ABAP Klasse cl_demo_amdp, deren Definition hier aus Übersichtlichkeitsgründen nicht dargestellt ist. Die Methode hat einen Input Parameter inc, dessen Wert auf einen bestimmten Preis addiert wird sowie einen weiteren Parameter clnt welches den Client beschreibt für den die Daten geändert werden sollen.
Auch wenn dieses simple Beispiel genauso gut mit Open SQL geschrieben werden könnte, zeigt es dennoch wie gut sich SQLScript in ABAP integrieren lässt. Der Gewinn? Performance, Performance, and Performance
