Demo: Im AMDP anderer Prozedur aufrufen

Aufgabenstellung
Rufe die Methode aus der vorherigen Demo mit der Sprache 'E' in einer neuen AMDP Methode GET_COUNTRIES_TEXT_EN auf.

Performancegewinn bei HANA-Ausführung

Die höhere Performance bei der SAP-HANA-Ausführung hat mehrere Gründe:

• Kein Kopieren der Daten zwischen ABAP und HANA
• Größere Datenpakete (typisch: 1.000.000 vs. 50.000) reduzieren den Overhead für die Statusverwaltung und das Monitoring.
• Durch die Verarbeitung direkt auf der SAP-HANA-Datenbank kann die Datenverarbeitung gut parallelisiert werden.
• Vorhandene Routinen sind bei SAP-HANA-Transformationen in SQLScript implementiert. Diese lassen sich dann gut optimieren.

Transformationsroutinen als AMDP

Alle Routinen einer Transformation müssen in der gleichen Technologie implementiert werden: Entweder ABAP oder AMDP

Die generierte AMDP-Klasse

BW on HANA

• Für jede Routine wird eine eigene AMDP-Klasse im $TMP Paket mit kryptischem GUID-Namen im /BIC/-Namensraum generiert.
• Die Verbindung von Routine zu Transformation wird in der Transformation gespeichert
• Diese enthält immer genau eine Methode mit dem Namen PROCEDURE.

BW/4HANA

• Für jede Transformation werden zwei AMDP-Klasse im /BIC/-Namensraum generiert.
• Der TRF-Name ist im Klassennamen enthalten.
• Die Klassen haben die Endung _M(=Modifiziert) und _A (=Aktiv).
• Die Klassen enthalten pro Routine eine Methode.

Simulation einer Transformationsroutine in der Konsole

Der wiederholte Test von Transformationen ist zeitraubend. Dabei kann man den Code einer Transformation relativ einfach in der SQL-Konsole testen.

Vorgehen:

• Anlegen eines anonymen Blocks: DO BEGIN..END
• Einfügen des Transformationscodes
• Am Anfang des Blocks die Tabelle INTAB definieren und füllen
• Am Ende die OUTTAB abfragen

DO BEGIN
  intab = SELECT *, 
                 '' AS record, 
                 '' AS sql__procedure__source__record
            FROM "/BIC/A<DSO-Name>2";            
            --ggf. WHERE Bedingung oder LIMIT 1000 um die Datenmenge klein zu halten 
--------------------------------
  --Hier kommt der Routinen-Code hin
--------------------------------
  SELECT * FROM :outtab;
END;

Signatur der AMDP-Methoden

Die Schnittstelle der Methode PROCEDURE wird jeweils passend zu der Transformation generiert. Dabei gibt es für alle vier Routine-Typen die gleichen Parameter:

• Eingangstabelle INTAB – Die Daten werden über den IN-Parameter mit dem Namen INTAB an die Routine übergeben.
• Ausgabetabelle OUTTAB – Das Ergebnis der Routine wird in den Tabellenparameter OUTTAB geschrieben. Zum Aktivieren der AMDP-Klasse ist es erforderlich, dass dieser Parameter mit einer entsprechenden SELECT-Abfrage gefüllt wird.

Ab BW/4HANA nur noch, falls die Fehlerverarbeitung angeschaltet ist:

• Ausgabetabelle ERRORTAB – Fehlerhafte Datensätze werden in diese Tabelle geschrieben. Sie besteht aus zwei Feldern:
  • ERROR_TEXT – Beschreibung des Fehlers
  • SQL__PROCEDURE__SOURCE__RECORD – Feld aus dem zugehörigen Datensatz der INTAB
• skalarer Parameter I_ERROR_HANDLING – Dieser Parameter hat den Wert TRUE, wenn der aktuelle Prozeduraufruf die Fehlertabelle ERRORTAB abfragt.

Das Feld RECORD in den Tabellen

Das Feld RECORD ist eine 56 Zeichen lange Zeichenkette.

Das kann für die Reihenfolge des Einfügens in das Ziel der Transformation relevant sein. Initial enthält das Feld RECORD die verketteten Felder REQUESTID, DATAPAKID und RECORD aus der Quelle der Transformation.

Bei aufeinanderfolgenden Transformationen enthält es den Wert des Feldes RECORD der vorhergehenden Transformation.

SQL__PROCEDURE__SOURCE__RECORD

In dem Feld SQL__PROCEDURE__SOURCE__RECORD steht ein eindeutiger Schlüssel für Datensätze in der Tabelle INTAB.

Durch diesen Schlüssel können Einträge in der Fehlertabelle ERRORTAB dem jeweiligen Datensatz aus der INTAB zugeordnet werden. Falls in einer Routine neue Datensätze generiert werden, soll der Wert des jeweiligen Quell-Datensatzes übernommen werden.

Zuweisung der Ausgabetabellen

Die Ausgabetabelle OUTTAB und ggf. auch ERRORTAB müssen im SQLScript-Quellcode zugewiesen werden, sonst gibt es Syntaxfehler. Dies ist auch dann erforderlich, wenn Sie keine Fehlerverarbeitung durchführen wollen.

 METHOD global_end BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY.
    OUTTAB   = SELECT * FROM :INTAB;
    ERRORTAB = SELECT '' AS ERROR_TEXT,
                      '' AS SQL__PROCEDURE__SOURCE__RECORD
                 FROM DUMMY WHERE DUMMY <> 'X';
  ENDMETHOD.

Dieser Code entspricht dem initialen Code der generierten Methode einer Endroutine auf einem BWoH 7.50, auch wenn er in dem Beispiel etwas ansprechender formatiert wurde.

• Die Tabelle OUTTAB wird 1:1 aus der INTAB gefüllt.
• Die Tabelle ERRORTAB bleibt offenbar leer.

ERRORTAB = SELECT * FROM :ERRORTAB;

Tabellen & Views der ADSOs

Die Tabellen- und Viewnamen für die ADSOs werden nach dem folgenden Schema gebildet:
/BIC/A<DSO-Name><Suffix>

NOT NULL

In den Ergebnisstabellen dürfen keine NULL-Werte stehen. Falls doch, kommt es zu einer Fehlermeldung:

Die automatische Initialisierung existiert ab BW/4HANA 2021:

Startroutinen

Die Startroutine wird am Anfang der Transformation durchlaufen, also bevor die Zuweisung der einzelnen Felder und deren Verarbeitung mit den Feldregeln erfolgt. Dementsprechend umfassen die beiden Tabellenparameter INTAB und OUTTAB die Felder der Datenquelle.

Typische Aufgaben der Startroutinen sind:

• Filtern von Datensätzen, wenn die Selektionskriterien im DTP nicht ausreichen, z.B. weil sie erst durch einen Join ermittelt werden können.
• Hinzufügen von Datensätzen, die dann in den weiteren Schritten der Transformation genau wie die ursprünglichen Daten verarbeitet werden.

Beides kann genauso in der End- oder Expertenroutine geschehen!

Expertenroutinen

Die Expertenroutine ersetzt die gesamte Transformationslogik. Wenn also eine Expertenroutine angelegt wird, sind keine Feldregeln (1:1-Mapping, Formeln, Lookups etc.) mehr möglich. Die Tabelle INTAB enthält nur die Felder der Quelle und die Tabelle OUTTAB die Felder des Ziels der Transformation.

Typische Anwendungsfälle

• Felder aus Quelle und Ziel werden benötigt
• Die Logik würde sich sonst auf viele Stellen verteilen (Feldregeln, Start- und Endroutine)
• Trigger-DSOs

Fehlerverarbeitung und Error Stack

TLDR - Es funktioniert nicht sauber!

In allen vier Routinentypen kann eine Fehlerverarbeitung erfolgen. Das bedeutet, dass die Routine die Werte des Feldes SQL__PROCEDURE__SOURCE__RECORD der fehlerhaften Datensätze aus der INTAB in die Tabelle ERRORTAB schreibt. Dort kann in der Spalte ERROR_TEXT auch ein geeigneter Fehlertext mitgegeben werden
Fehlerverarbeitung bitte gründlich testen

In der Vergangenheit hatte der Bereich Fehlerbehandlung und Error-Stack immer wieder Probleme gemacht. Es empfiehlt sich vor der Nutzung dieser Funktionen ein gründlicher Test, auch nach der Einspielung von neuen SPs.

Ablauf der Verarbeitung im Datentransferprozess

Jede Transformation, und somit auch jede Routine, wird beim Ausführen eines Datentransferprozesses zweimal durchlaufen.
Beim ersten Durchlauf werden die fehlerhaften Datensätze ermittelt und beim zweiten Mal findet erst die eigentliche Verarbeitung statt.

1. Beispiel: DTP Verarbeitung mit Fehlerbehandlung
   Erster Durchlauf des Beispiels
   Das Feld Beleg bildet eine semantische Gruppe. Das bedeutet, dass wenn eine Position auf einem Beleg fehlerhaft ist, der gesamte Beleg fehlerhaft ist und soll aussortiert werden.
   Datensätze ohne gültige Währung werden als fehlerhaft angesehen und von der Routine beim ersten Durchlauf in die ERRORTAB geschrieben.
   Der Datentransferprozess sortiert daraufhin alle Datensätze aus, die in einer semantischen Gruppe zusammen mit fehlerhaften Datensätzen sind.
   Zweiter Durchlauf des Beispiels
   Die korrekten Datensätze werden im zweiten Durchlauf der Routine von der Tabelle INTAB in die Tabelle OUTTAB verarbeitet.
   Dass die Routine zweimal durchlaufen wird, bedeutet nicht unbedingt, dass sich die Laufzeit verdoppelt. Beim ersten Durchlauf wird vom Datentransferprozess nur die Ausgabetabelle ERRORTAB abgefragt, beim zweiten Durchlauf nur die Ausgabetabelle OUTTAB. Wenn diese voneinander unabhängig ermittelt werden können, dann wird die SAP-HANA-Datenbank die Ausführung so optimieren, dass jeweils nur die tatsächlich benötigten Anweisungen durchlaufen werden.
2. Beispiel: Fehlerhafte Daten in Tabelle OUTTAB erkennen
   Manchmal lassen sich die fehlerhaften Daten erst nach der Berechnung der Tabelle OUTTAB erkennen. Deswegen wird die Tabelle ERRORTAB häufig durch eine SELECT-Abfrage auf die Tabelle OUTTAB ermittelt, wie in Listing 1.8 zu sehen.
3. Beispiel: Ungültige Feldinhalte mit regulären Ausdrücken finden
   Ein typischer Fallstrick in der Datenverarbeitung mit SAP BW sind die nicht erlaubten Zeichen. Welche Zeichen erlaubt sind, wird im Customizing des BW-Systems eingestellt. Normalerweise bereiten vor allem die Steuerzeichen wie z. B. Backspace oder der Zeilenumbruch Probleme.
   Sobald die Daten mit unerlaubten Zeichen in SAP BW als Schlüssel für InfoObjects verwendet werden, kommt es zu Aktivierungsfehlern. Da die ADSOs auch feldbasiert, also ohne Zuweisung von InfoObjects, modelliert sein können, fallen die nicht erlaubten Zeichen dort zunächst nicht auf. Neben den unerlaubten Zeichen gibt es Fehler, wenn Merkmalswerte in SAP BW mit einem Ausrufezeichen beginnen oder nur aus dem Doppelkreuz # bestehen.
   In Listing 1.9 habe ich eine AMDP-Routine erstellt, die in der Spalte TEXT diese Steuerzeichen mit regulären Ausdrücken erkennt und die entsprechenden Datensätze in die ERRORTAB schreibt. Diese Routine gibt die Tabelle INTAB ohne Veränderung 1:1 zurück an die Tabelle OUTTAB.
   3.Beispiel Quelltext
   Diese Routine lässt sich einfach um weitere zu prüfende Felder erweitern. Normalerweise müssen aber nicht alle Felder geprüft werden, denn diese Fehler treten nur in Feldern auf, die im Quellsystem manuell (vor allem mit Copy & Paste) erfasst werden, und dort, wo keine Prüftabelle hinterlegt ist, z. B. bei Buchungstexten.
   Eine Alternative zu der gezeigten Implementierung wäre eine Ersetzung der Steuerzeichen mit einem Leerzeichen.

AMDP Debugging

Der Status des AMDP-Debuggers

Ein Breakpoint wird im AMDP-Debugger, wie im ABAP-Debugger auch, als kleiner runder Kreis links von der Zeilennummer dargestellt:

Debugging von BW-Transformationsroutinen

Typische Fehlerquellen beim Debuggen:

• Keine Daten in der Quelle oder keine Daten abzuholen im Delta Modus
• Falsche Option beim Ausführen (Parallel statt seriell)
• In BW/4HANA muss der Breakpoint in der _A-Klasse gesetzt werden! Siehe https://launchpad.support.sap.com/#/notes/2659814

Vorsicht – Routinen können verschwinden

Selbst auf aktuellen BW4-Systemen kann es immer mal vorkommen, dass Routinen nach dem Aktivieren der Transformation bzw. des DTPs verschwunden sind!

Empfehlung deshalb:

• Quellcode in die Zwischenablage oder das Notepad sichern
• Objekt schließen, wieder öffnen und prüfen, welcher Code jetzt da ist.
• Dummy-Änderungen in der Transformation vor dem Aktivieren machen, z.B. Leerzeichen in der Beschreibun einfügen. -
• Danach Speichern und erst danach Aktivieren.

Tipps

Im Folgenden kommen ein paar Tips, die das Leben mit Eclipse leichter machen. ;-)

Feldliste im Editor erzeugen

1. Die Definition aus dem Element Info kopieren
2. im Notepad++, Ersetzen: " type.*" durch ","

Das kann auch als Makro aufgezeichnet werden.

Ausserdem kann man auch gleich die Spezielle Notation mit Gänsefüsschen erzeugen.

Verknüpfung der Projektsicht mit den Editoren rechts

Automatischer Syntaxcheck ein- und ausschalten

Hintergrundfarbe für SQL-Script einstellen