Mit der erweiterten Möglichkeit in BW-Transformationen neben ABAP auch AMDP-Routinen mit SQL-Script für die Umsetzung der Logiken zu verwenden, sind auch unterschiedliche Ansätze hinzugekommen, diese Implementierungen zu prüfen und zu testen.
Der Artikel beschreibt die Möglichkeiten, wie sich AMDP-Routinen im SAPDie SAP SE mit Sitz im baden-württembergischen Walldorf ist ein… BW während der Entwicklung und nach der Implementierung optimal testen, sowie auf ihre Funktionalität als auch auf Fehler prüfen lassen.
Im ABAP besteht unter anderem die Möglichkeit während der Entwicklung im ABAP-Editor den Quellcode über die „Prüfen-Funktion“ zu prüfen und sich bereits erste Fehler anzeigen zu lassen. Auch lassen sich sogenannte „Break Points“ im Quellcode setzen, die später im Debugging-Modus während der Ausführung der Routine für einen „Stop“ an der entsprechenden Stelle sorgen, um z.B. dann Schritt-für-Schritt fortfahren zu können. Hierdurch lassen sich die Inhalte von Tabellen und Variablen anzeigen und die Zuweisungen innerhalb des Quellcodes detailliert prüfen. Ähnliche Möglichkeiten bestehen auch für die Routinen, welche mittels SQL-Script umgesetzt werden, wobei sich das Vorgehen hier ein wenig unterscheidet. Nachfolgend soll auf zwei unterschiedliche Möglichkeiten eingegangen werden, um den Quellcode während der Entwicklung und auch nach erfolgreicher Implementierung prüfen zu können.
Debugging und Simulation von AMDP-Routinen in SAP BW Transformationen
Nachfolgend werden zwei Möglichkeiten beschrieben, wie sich AMDP-Transformationsroutinen testen und auf Fehler prüfen lassen. Dabei sollte beachtet werden, dass sich die beiden Methoden grundsätzlich darin unterscheiden, in welcher Umgebung sie angewendet werden. Während die zweite Methode, dem Debugging von AMDP-Routinen in SAP BW Transformationen, auf der Applikationsebene stattfindet, ist für die erste Methode, der Simulation einer SQL-Transformationsroutine, ein Datenbankbenutzer notwendig, da sie in der SQL-Konsole der Datenbank durchgeführt wird. Auch für die verschiedenen Entwicklungsphasen gibt es Unterschiede bzgl. der Anwendung zwischen den beiden Methoden. So kann eine Transformation grundsätzlich nur dann „debuggt“ werden, wenn sie fehlerfrei und bereits aktiviert ist, sowie auch ein entsprechender DatentransferprozessLegt fest, wie Daten von einem persistenten Objekt, zu einem… zum Zielobjekt bereits besteht. Die Simulation hingegen kann bereits während der Entwicklung stattfinden. Zwar wird auch hier vorausgesetzt, dass der Quellcode fehlerfrei ist, jedoch muss noch kein entsprechender Datenfluss vollständig angelegt worden sein, da sich die entsprechenden Objekte einfach in der SQL-Konsole simulieren lassen.
Simulation von AMDP-Routinen einer SAP BW-Transformation
Grundsätzliches Vorgehen:
- Umsetzung eines anonymen BLOCKS: DO BEGIN … END;
- Einfügen des Codes aus der BW-Transformation
- Vor dem eigentlichen „Transformations“-Code muss der „intab“ noch definiert und aus der Tabelle des Source-ADSO gefüllt werden (z.B. aktive Tabelle)
In folgendem Beispiel befindet sich eine Transformation zwischen zwei ADSOs welche eine AMDP-Routine beinhaltet:
Die Transformation enthält eine AMDP-Endroutine, um die „Division“ aus den Materialstammdaten zu ermitteln:
Die benötigten Informationen (DIVISION) werden in diesem Fall aus der Tabelle der aktiven Daten eines weiteren Materialstammdaten-ADSOs (RMDDMATR1) gelesen:
Um z.B. den Test-Aufwand während der Entwicklung zu reduzieren, da hierfür immer ein DTP ausgeführt und evtl. auch noch der AMDP-Debugger genutzt werden muss, bietet es sich an den „Entwicklungs“-Test in der SQL-Konsole durchzuführen.
Hierfür wird die Routine ein wenig angepasst und in die SQL-Konsole übertragen:
- Öffnen des SQL-Editors in der HANA-Datenbank Umgebung
- Implementierung des SQL-(Skript) Codes der AMDP-Routine zwischen „do begin“ und „end;“
- Füllen des „intab“ mit den Daten des Quell-ADSOs aus der Transformation
- Erstellen eines „SELECT“-Statements auf das „OutTab“, um das Ergebnis anzeigen zu lassen
Hierdurch lässt sich während der Entwicklungszeit, der Aufwand relativ geringhalten, um die Ergebnisse des Coding überprüfen zu können.
Nach Ausführung des SQL-Code mittels der entsprechenden Funktion, lässt sich das Quellcode-Ausführungs-Ergebnis einsehen:
Debugging von AMDP-Routinen in einer BW-Transformation
Grundsätzliches Vorgehen:
- Routine in „A-Class“ öffnen
- Breakpoint setzen
- Datentransferprozess ausführen
- Wechsel in Debugging Perspektive
Das in „Methode 1“ beschriebene Datenmodell lässt sich auf Applikationsebene direkt im BW/4HANA Schritt für Schritt mittels Debugger prüfen. Hierfür muss die entsprechende Routine fehlerfrei und aktiviert, sowie ein Datentransferprozess vorhanden sein.
Wird die entsprechende Routine aus der Transformation heraus ausgewählt, wird auch automatisch die M-Version der Routine geöffnet:
Um zur A-Version zu wechseln, besteht die Möglichkeit, die Such-Funktion in der Eclipse-Umgebung zu nutzen. Hierzu wird der Endung „M“ durch die Endung „A“ ersetzt:
In der A-Version der AMDP-Routine lässt sich nun ein „Breakpoint“ setzen:
Sobald der Breakpoint aktiv in der A-Version der Routine gesetzt wurde, lässt sich über die „normale“ Ausführung des DTP die entsprechende „Debugging Perspektive“ automatisch öffnen:
In dieser Ansicht ist es möglich das entsprechende Coding Schritt-für-Schritt beginnend am Breakpoint „ablaufen“ zu lassen. Die Werkzeugleiste der Debugging-Perspektive bietet hier unterschiedliche Funktionen, um die Ergebnisse der einzelnen Schritte zu analysieren:
Die Ergebnisse der enthaltenen Tabellen lassen sich durch Auswahl der entsprechenden Tabelle direkt anzeigen:
Grundsätzlich sind Breakpoints nur für eine „kurze“ zeit aktiv und werden dann automatisch deaktiviert. Um einen Breakpoint erneut zu aktivieren, besteht die Möglichkeit, über dem Kontext-Menü der rechten Maustaste den Breakpoint oder den AMDP-Debugger erneut zu aktivieren.
Fazit
Beide aufgezeigten Möglichkeiten erlauben es dem Entwickler die Analyse und Prüfung von AMDP-Routinen in den unterschiedlichen Entwicklungsphasen durchzuführen und somit frühzeitig Fehler oder Schwierigkeiten zu entdecken.
Christopher Kampmann
Senior Manager
SAP Information Management
christopher.kampmann@isr.de
+49 (0) 151 422 05 448
