Im vorherigen Beitrag haben Sie die Vorteile von SQLScript kennengelernt. Während SQLScript Transformationsroutinen zweifelsohne bei der Performance Punkten, existieren auch einige Einschränkungen. Diese werden in diesem Artikel beleuchtet.
Transformationen werden nämlich nicht in allen Fällen in der SAP HANA Datenbank ausgeführt. Innerhalb der Transformation können Sie prüfen, ob die HANA Laufzeit unterstützt wird. Nutzen Sie dazu den Prüfen Button im Laufzeitstatus Bereich.
Wenn die Transformation nicht auf der Ebene der HANA Datenbank ausgeführt werden kann, wird die Liste der nicht unterstützten Funktionen angezeigt.
Im Folgenden erläutere ich die 10 wichtigsten Einschränkungen.
1. Unterstütze InfoProvider
Beachten Sie auch, dass nicht alle InfoProvider als Ziel einer HANA Transformation verwendet werden können. Folgende Objekte werden als Ziele unterstützt:
- DSO: Standard- und schreiboptimierte Typen
- ADSO: alle Typen, außer der Einstellung "InfoCube"
- Semantisch partitionierte Objekte basierend auf DataStore-Objekten
- Open-Hub-Ziele mit Datenbanktabellen (ohne Datenbankverbindung) oder Tools von Drittanbietern
Ab SAP BW 7.5 können auch folgende Objekte als Ziele genutzt werden:
- ADSO: Alle Typen, einschließlich der Einstellungen für „InfoCube“
- InfoObjekte
- InfoCubes
Allerdings werden lediglich die Extraktion und Transformation mit SAP HANA durchgeführt. Die SIDs werden im ABAP generiert. Deshalb führt die Verwendung von AMDP Script in einer einfachen Transformation mit 1:1 Zuweisung zu keiner Leistungsverbesserung. Wir empfehlen daher, ADSOs mit den Enterprise Data Warehouse Architecture Vorlagen bei der Modellierung zu verwenden.
2. Queries als InfoProvider können nicht als Quelle verwendet werden
Außerdem können Queries, die als InfoProvider definiert wurden, nicht als Quelle einer HANA Transformation verwendet werden. Sie können diese Einschränkung umgehen, indem Sie auf Basis der Query eine externe SAP HANA View definieren.
Die Einstellung “External SAP HANA View” muss auch beim InfoProvider gesetzt werden.
3. Transformationen mit Regelgruppen nicht möglich
Darüber hinaus ist es nicht möglich, Transformationen mit Regelgruppen in HANA auszuführen. Sobald eine Regelgruppe angelegt wird, ist lediglich die Ausführung in der ABAP Umgebung möglich.
4. Nearline Verbindungen nicht unterstützt
Nearline Storage stellt die Möglichkeit zur Verfügung, Daten über einen Datenarchivierungsprozess auszulagern. Dabei wird das Datenvolumen von InfoProvidern verkleinert, während die Daten weiterhin für Queries zur Verfügung stehen. Leider können diese Nearline Verbindungen nicht innerhalb von HANA Transformationen genutzt werden.
5. Semantische Gruppen in DTPs
Beachten Sie bitte außerdem, dass die DTP Einstellung Semantische Gruppen keinen Einfluss auf die Reihenfolge der extrahierten Daten hat. Diese Einstellung beeinflusst nur die Gruppierung der Daten, die an den Fehler-Stack gesendet werden.
6. ABAP Routinen innerhalb der Transformation nicht möglich
Wenn Sie eine Routine innerhalb einer Transformation anlegen, müssen Sie sich entweder für ABAP oder SQLScript entscheiden. Beides zusammen ist nicht möglich.
ABAP Start-, End- oder Feld-Routinen können nicht mit SQLScript Routinen kombiniert werden.
Wenn Sie mehrere Transformationsroutinen verwenden, die durch eine InfoSource verbunden sind, gilt die folgende Regel: sobald eine vorausgehende Transformation in ABAP abgebildet ist, kann die zweite Transformation nicht in HANA abgebildet werden. Wenn die erste Transformation jedoch in HANA ausgeführt wird, kann die zweite in ABAP ausgeführt werden. Als Gedankenstütze könne Sie sich das folgende Prinzip merken - sind die Daten erst einmal im ABAP Stack, ist kein Pushdown mehr möglich.
Steigern Sie die Leistung Ihres BW mit SQLScript
7. Kundeneigene Funktionen im Formel Editor
Wenn Sie Routinen mithilfe des Formeleditors anlegen, dürfen Sie nur die von SAP ausgelieferten Funktionen verwenden. Kundendefinierte Funktionen werden nicht unterstützt.
Bei der Prüfung der HANA Unterstützung im Laufzeitstatus Bereich der Transformation wird eine entsprechende Meldung ausgegeben.
8. Datenprüfung
Daten, die mit einem AMDP-Skript transformiert werden, werden direkt in das Datenziel geschrieben. Das System führt keine Datenvalidierung durch. Die Ausgabe der Transformation muss in tabellarischer Form unter Verwendung einer vordefinierten Reihenfolge der Spalten erfolgen, und die Werte müssen den vorgegebenen Datentypen entsprechen.
Beachten Sie dabei, dass die Ausgabedaten nicht nur mit dem in SAP HANA verwendeten Datentyp entsprechen müssen, sondern auch der BW-spezifischen Definition für jedes Feld. So ist zum Beispiel der in HANA gültige Datentyp DATE mit dem Format YYYY-MM-DD nicht kompatibel mit dem Datentyp DATS im YYYYMMDD Format.
Achten Sie darüber hinaus auf folgende Fallstricke:
- NULL-Werte sind auf keinen Fall erlaubt und führen zu einem Fehler. In diesem Beitrag lernen Sie, wie Sie sich dagegen absichern können
- Initiale Werte für InfoObjekte hängen vom jeweiligen Datentyp ab. So dürfen zum Beispiel initiale NUMC Felder nur mit Nullen gefüllt werden, obwohl für das Datenbankfeld alle Zeichen erlaubt sind
- Zulässige Zeichen für InfoObjekte vom Typ CHAR werden im BW-Customizing definiert (Transaktion RSKC)
- Kleinbuchstaben sind nur dann erlaubt, wenn die entsprechende Einstellung für das InfoObjekt aktiviert ist
- Felder müssen im internen BW Format gefüllt werden, insbesondere wenn Konvertierungs-Exits vorhanden sind. So werden zum Beispiel Fiskalperioden im Format YYYYMMM Format gespeichert, aber extern als MMM/YYYY für den Benutzer dargestellt
- Beachten Sie auch, dass Werte nicht mit BW Stammdatentabellen abgeglichen werden. So könnten unerwünschte Einträge entstehen
- Wenn einem InfoObjekt eine Konstante zugewiesen ist, muss der exakte (interne) Wert für das entsprechende Feld angegeben werden
9. Fehlerbehandlung in SAP HANA
In diesem Zusammenhang ist Fehlerbehandlung wichtig. Ab SAP BW 7.5 SP 4 kann die Fehlerbehandlung im DTP aktiviert werden. Dadurch wird die Signatur der ABAP-verwalteten Datenbankprozedur geändert und die Rückgabe von Fehlermeldungen an das SAP BW ermöglicht.
Allerding wird die Fehlerbehandlung mit BW on HANA und BW/4HANA 1.0 nicht für die HANA Laufzeit unterstützt. Sodass die fehlerhaften Datensätze zwar in den Error Stack geschrieben, jedoch nicht über einen Fehler DTP geleert werden können.
Mit BW/4HANA 2.0 wurde das Error Handling für die HANA-Laufzeit grundlegend überarbeitet, sodass Sie auch den Fehler DTP einsetzen können. Allerdings sollten Sie die Performance Aspekte beachten, bevor Sie die Fehlerbehandlung produktiv einsetzen. Weitere Informationen finden Sie im SAP Hinweis 2580109 - Error Handling in BW Transformationen und Datentransferprozessen in der HANA-Laufzeit.
10. Handling von Paketen bei sehr großen Datenmengen
Wenn Sie mit sehr großen Datenmengen (z.B. Hunderte Millionen Datensätze) im BW arbeiten, müssen Sie beachten, dass die Extraktion mit der HANA Ausführung nur bei folgenden InfoProvidern stattfindet:
- DataStore-Objekt (advanced)
- DataStore-Objekt (klassisch)
- SAP HANA DataSource
InfoCubes dagegen werden nicht unterstützt. Wenn Sie einen InfoCube als Quelle verwenden, werden Daten nicht paketweise extrahiert. Dies kann die Speicherkapazität ausschöpfen und zu Out of Memory Fehlern führen.
Weitere Informationen finden Sie im SAP Hinweis 2329819 - “SAP-HANA-Ausführung in DTPs (Datentransferprozesse) - Optimierungen”. Mögliche Lösungen werden im SAP Hinweis 2230080 - “Beratung: DTP: erschöpfte Speicherkapazität bei 'SAP-HANA-Ausführung' und requestweiser Extraktion” angeboten.
Unser Fazit - HANA SQLScript
Wenn Sie die in diesem Beitrag genannten Einschränkungen beachten und die Kriterien für die Umstellung auf SQLScript beachten, können Sie von enormen Performance Vorteilen profitieren. In unserer Beratungspraxis haben wir Fälle mit mehr als 15-fach besserer Laufzeit beobachtet. Der Kunde kann sich nun auf Datenanalysen und das Erreichen von Ergebnissen konzentrieren, anstatt auf die Verarbeitung der Daten zu warten.
Daher sollten Sie grundsätzlich bei datenintensiven Logiken SQLScript verwenden, um zusätzliche Datenübertragungen zwischen Applikations- und Datenbankservern zu vermeiden.
Sprechen Sie uns an, wir helfen Ihnen bei der Auswahl der richtigen Strategie und individueller Umsetzung.
