Skript: ABAP Tools - Debugging for Beginners [006]
Der Debugger der ABAP Development Tools ist bereits ein mächtiges Werkzeug, wird allerdings von vielen ABAP Entwicklern gemieden. In dieser Episode schauen wir uns die Konfiguration an und machen eine kleine Einführung in das Thema Debuggen.
Inhaltsverzeichnis
Einleitung
In dieser Folge schauen wir uns das Thema Debugging an. Viele Entwickler haben im Umgang mit den ABAP Development Tools noch Probleme bei der Nutzung des Debuggings. Deshalb möchten wir in diesem Video uns drei Dinge im Detail anschauen.
- Breakpoints - Hier möchten wir auf die verschiedenen Arten von Breakpoints eingehen. Die weiteren Einstellungen beim Debugging.
- Konfiguration - Die Konfiguration der Perspektive und der verschiedenen Views zur besseren Nutzung des Debuggers.
- Durchführung - Techniken und Best Practices beim Debuggen mit den ABAP Development Tools.
Beispiel
In diesem Beispiel haben wir eine ausführbare Klasse mit mehreren Methoden erstellt. Damit können wir verschiedene Szenarien des Debuggens durchspielen und die verschiedenen Views im Debugger testen. In dieser Methode gibt es zum Beispiel eine Ausnahme die ausgelöst wird und durch die verschiedenen Hierarchien an Methoden nach oben weitergegeben wird und dort in verschiedene andere Ausnahmen gewrappt wird.
Es gibt auch eine Methode die uns Daten in Form einer Tabelle zurückgibt oder eine Methode die einen JSON String erzeugt und als Variable zurückgibt. Zusätzlich haben wir noch eine Nachrichtenklasse und eine Ausnahmeklasse, auf die wir hier aber nicht im Detail eingehen.
Breakpoints
Wir werden Breakpoints in ADT nun eigentlich gesetzt und welche Arten gibt es? Im Gegensatz zur SAP GUI, gibt es in Eclipse nicht das Commando /h, um den Debugger über die GUI zu starten. In diesem Fall müssen wir Breakpoints schon zuvor in den Quellcode setzen.
Hier kannst du per Doppelklick auf eine Zeile einen Breakpoint setzen. Dabei wird automatisch auch ein externer Breakpoint gesetzt, sodass du jegliche Aufrufe für den definierten Benutzer debuggen kannst. Über die Einstellungen kannst du weitere Einstellungen zum Debugging finden, wie den aktuellen User oder ob du Tool Anfragen debuggen möchtest. Den Breakpoint kannst du auch via Rechtsklick und Kontextmenü aktivieren und deaktivieren. Die grünen Breakpoint sind sogenannte Soft-Breakpoints. Diese schauen wir uns später noch einmal im Detail an. Wenn der Breakpoint gesetzt wurde, kannst du die Schnittstelle starten oder wie in diesem Fall die Klasse per F9 starten.
Perspektive
Wenn der Debugger startet, wechseln wir in die Debugging Perspektive. Das System wird dich auch fragen, ob du das machen möchtest, was du bestätigen solltest. Grundsätzlich kannst du auch den Haken setzen, da wir beim Debugging immer in die Debugging Perspektive wollen. Vorteil ist die Anordnung der Views, diese können wir auf unsere Bedürfnisse anpassen. Der View stellt für viele Entwickler auch das größte Hindernis dar, da sie ihre gewohnten Tools nicht mehr finden.
Aber schauen wir uns erst einmal die Perspektive im Detail an. Im oberen Bereich finden wir die verschiedenen Aktionen zum Debuggen, diese verhalten sich von den Tastenkombinationen wie im GUI Debugger, damit hast du erst einmal keine Änderungen. Die verschiedenen Views der Arbeitsfläche kannst du frei positionieren, was wir auch gleich machen. Schaffen wir uns dazu erst einmal eine gewohnte Arbeitsatmosphäre und ordnen die Views neu an. Auf der linken Seite benötigen wir den kompletten Quellcode, damit wir viel Übersicht haben. Im rechten oberen Teil wollen wir den Callstack haben und unten die verschiedenen Variablen. Daneben lege ich persönlich die Tabellenansicht und den Exception Viewer an, um die wichtigsten Analysewerkzeuge im Zugriff zu haben. Damit nimmt die Ansicht langsam das Aussehen und die Funktionen des klassischen Debuggers ein. Die Perspektive kannst du ganz einfach im oberen Teil wechseln.
Debugging
Schauen wir uns das Debugging im Detail an und gehen auf verschiedene Punkte ein.
Tastenkombination
Dazu können wir wie gewohnt mit den Funktionstasten durch den Quellcode navigieren. Mit F5 navigieren wir in die Methode hinein und gehen jeweils einen Schritt weiter. Mit F6 führen wir einen Schritt aus, überspringen Dabei aber eine Methode, falls der nächste Schritt eine Methode wäre. Mit F7 verlassen wir die aktuelle Methode und spingen hinter die Ausführung.
Die Funktion "Springen" findest du im Menü oben oder über den Standard Shortcut SHIFT + F12. Diese Funktion solltest du ebenfalls sparsam nutzen. Wie in der SAP GUI wird der Quellcode beim Sprung nach vorn nicht ausgeführt. Sprinst du zurück, dann werden Variablen nicht gelöscht und damit können falsche Ergebnisse in Tabellen vorhanden sein. Daher solltest du diese Funktion immer mit Vorsicht einsetzen. Im Menü findest du dann noch weitere Optionen zum Schließen des Debuggers oder Run to Line, die es im SAP GUI Debugger nicht gibt.
Mit F8 lassen wir die Logik weiterlaufen, entweder bis das Ende erreicht ist oder ein weiterer Breakpoint erreicht ist. Um dann zum Coding zurückzukehren, musst du nur die Perspektive wechseln.
Informationen
Möchtest du Informationen zu Variablen und Inhalten bekommen, musst du während des Debuggings nur über die entsprechende Variable mit dem Mauszeiger gehen und erhältst die Information im Popup. Per Doppelklick auf die Variable, wird diese in den entsprechend verfügbaren View angezeigt. Hier stehen Variablen, Tabellen und Ausnahmen zur Verfügung.
Enthält die Variable ein bestimmtes Format, wie zum Beispiel einen JSON String, dann kannst du bei der Anzeige der Variable, den View ändern. Per Rechtsklick kannst du dir die passende Anzeige wählen in diesem Fall wollen wir den JSON View.
Ändern
Möchten wir den Inhalt einer Variable ändern, um zum Beispiel andere Eingaben zu Simulieren oder verschiedene Teile der Programmlogik zu ändern, dann müssen wir die Variable zuerst in den Variablenview holen. Mit einem Klick auf den Wert bzw. die Wertspalte startet der Änderungsmodus. Hier geben wir den neuen Wert ein und bestätigen mit ENTER oder klicken an eine andere Stelle
Tabellen
Für die Anzeige von Tabellen gibt es eigenen eigenen View. Empfehlung unsererseits ist die Anzeige direkt neben den Variablen, um kurze Wege bei der Analyse zu haben. Schauen wir uns dazu eine interne Tabelle an, die uns die Methode GET_TABLE_CONTENT zurückgibt. Über den View sehen wir die Daten in Tabellenform. Hier können wir zum Beispiel die Reihenfolge der Spalten anpassen, aber wir können auch Inhalte filtern, wenn wir etwas spezifisches suchen. In diesem Beispiel suchen wir nach Euro in der Tabelle, die Zeilen werden im View hervorgehoben. Die visuelle Suche in den Daten ist dabei ein Punkt. Wenn du ENTER betätigst, dann werden die Daten auch gefiltert. Das Gleiche machen wir noch einmal für unser erstes Beispiel. Ein Ändern von Inhalten in Tabellen ist ebenfalls möglich.
Ausnahmen
Schauen wir uns einmal das Thema Ausnahmen an. Für die Anzeige von Ausnahmen gibt es ebenfalls einen eigenen View der uns weitere Informationen zur Ausnahme und allen enthaltenen Ausnahmen gibt. Sollte es mehrere verkettete Ausnahmen geben, können wir bis zur auslösenden Meldung kommen.
In diesem Beispiel müssen wir den Inhalt der Variable anpassen, damit die Ausnahme ausgelöst wird. Daher setzen wir einen Breakpoint auf das IF-Statement. Nachdem wir den Debugger gestartet haben, setzen wir einen weiteren Breakpoint vor die Ausgabe im Catch, damit wir uns die Ausnahme anschauen können. Die Ausnahme wurde ausgelöst und wir können uns diese im entsprechenden View anschauen. Hier sehen wir den Stapel an erstellten Ausnahmen und wo sie erzeugt wurden. Darüber erhalten wir weitere Informationen, was der eigentliche Fehler war.
Breakpoints
Die Verwaltung der verschiedenen Punkte ist mit dem Breakpoint View besonders einfach. Diesen haben wir in den meisten Fällen neben dem Callstack platziert, da wir ihn nicht immer benötigen. Dieser gibt uns Informationen zu allen gesetzten Punkten und wir können hier zentral auch Punkte deaktivieren oder komplett löschen, wenn wir sie nicht mehr benötigen. Wenn wir Punkte deaktivieren, dann werden sie im Quellcode Weiß dargestellt und sind im View immer noch zu sehen. Aktivieren wir dann einen Breakpoint wieder, ist dieser wieder aktiv und im Code sichtbar.
Soft Breakpoints
Löschen wir dazu erst einmal alle gesetzten Breakpoints. Bei der Übersicht der verschiedenen Haltepunkte, haben wir auch auf Soft-Breakpoints verwiesen. Diese sind spezielle Punkte die wir nutzen können, um während des Debuggings anzuhalten. Die Besonderheit hier ist aber, wenn kein Debugger aktiv ist, werden die Punkte einfach überspringen. Dazu setzen wir zwei Punkte in der MAIN Methode und führen die Klasse aus. Der Debugger wird nicht gestartet und die Klasse normal durchlaufen. Setzen wie daher einen normalen Breakpoint im Code und führen die Klasse erneut aus. Der Breakpoint wird nun ausgelöst und der Debugger startet wie bisher. Führen wir die Verarbeitung mit F8 fort, dann halten wir auch an unseren Soft-Breakpoints an. Deaktivieren wir noch einmal den normalen Breakpoint und führen die Klasse aus, dann läuft die Klasse wieder bis zum Ende durch.
Statements
Über den Breakpoint View können wir nicht nur eine Übersicht aller gesetzten Breakpoints bekommen, sondern auch spezielle Punkte setzen. Möchtest du zum Beispiel bei jedem IF Statement oder Message Statement anhalten, gibt es hier im View die spezifischen Einstellungen. Fügen wir also einen neuen Breakpoint für alle RAISE Statements ein und prüfen das Verhalten. In der Übersicht der Breakpoints wird auch dieser Punkt angezeigt. Halten wir dazu nun wieder in der Methode und ändern des Inhalt von RAISE_ERROR, damit eine Ausnahme erzeugt wird. Immer wenn wir F8 drücken, halten wir an jedem RAISE Statement an, dies ist besonders effizient, wenn wir einemal nach Fehlern bei der Verarbeitung suchen, aber nicht genau wissen, wo diese erzeugt werden.
Fazit
Vor allem am Anfang wird das Debuggen mit dem neuen Debugger langsamer sein. Hier solltest du dir die Perspektive so einstellen, wie du am schnellsten an alle Informationen kommst. Wichtig ist dabei den Debugger kontinuierlich zu verwenden, um dich schnell einzuarbeiten und die vielen Zusatzfunktionen schnell zu verstehen. Aus persönlicher Sicht arbeiten wir seit ca. 2 Jahren nur noch mit dem neuen Debugger und da wir keine Reports mehr umsetzen, vermissen wir auch nicht die Funktion /h, die vor allem für die GUI wichtig ist.
Danke für dran bleiben und zuhören und wieder einmal ... bis zum nächsten Mal.
YouTube
Video