6.3 Mit dem ABAP Debugger arbeiten 

Der ABAP Debugger bietet verschiedene Arbeitsmodi und Sichten auf den Programmablauf. Je nach Problemstellung und Bedarf wechseln und kombinieren Sie diese Sichtweisen mit dem jeweiligen Modus. Für den Einstieg in ABAP sind die Registerkarten der Variablen (Variable 1 und Variable 2) auf der Registerkarte Desktop 1, mit denen Sie den Programmablauf und die Inhalte von Variablen verfolgen, sowie die Registerkarten Strukturen und Tabellen, mit denen Sie den Inhalt von Arbeitsbereichen und internen Tabellen beobachten, die wichtigsten Modi. Mit der Registerkarte Break-/Watchpoints verwalten und beobachten Sie die Break- und Watchpoints. Diese Beobachtungen und die daraus resultierenden Analysen sind unerlässlich für die Fehlerbehebung, aber auch, um die richtigen Stellen zu finden, falls Sie Änderungen in einem Quellcode vornehmen müssen.
6.3.1 Desktop 1 

Schalten Sie vom ABAP Editor auf den Debugger-Modus um, gelangen Sie standardmäßig auf der Registerkarte Desktop 1 an die Stelle des Breakpoints. Möchten Sie schrittweise jede Anweisung einzeln ausführen, um Feldinhalte, Inhalte von Tabellenbereichen etc. zu prüfen, klicken Sie auf den Button Einzelschritt (/(F5)).
Das System führt nur das Kommando aus, vor dem der gelbe Pfeil steht, und wartet dann wieder auf weitere Anweisungen; in unserem Beispiel steht das System anschließend vor der WRITE-Anweisung. Schritt für Schritt können Sie auf diese Weise den Quellcode durcharbeiten.
Bei Quellcode mit vielen Zeilen kann dies ein sehr mühseliges Unterfangen werden. Diese Vorgehensweise ist deshalb nur dann sinnvoll, wenn Sie ein unbekanntes Programm analysieren müssen und am Anfang noch nicht wissen, an welchen Stellen sinnvollerweise Breakpoints gesetzt werden sollten.
[ ! ] Nicht in die Tiefe stürzen!
Vorsicht, Falle! Angenommen, das System steht vor einem Unterprogrammaufruf, vor einem Funktionsbausteinaufruf oder vor einem anderen Objekt, und Sie drücken die Taste (F5), dann wechselt der ABAP Debugger sofort auf die nächsttiefere Ausführungsebene, verzweigt demnach in das Objekt und macht dort normal weiter. Hierdurch besteht das Risiko, dass Systembereiche oder andere Module analysiert werden, die Sie eigentlich als fertige Komponenten verwenden, deren Quellcode Sie aber nicht debuggen möchten. Denken Sie daher daran, dass Sie die Arbeit mit der (F5)-Taste gnadenlos in die Tiefen des Systems führen kann. Seit Release 7.0 EHP 2 gibt es mit dem Layer-aware Debugging einen Schutz gegen diese Gefahr – diese Technik wird in Abschnitt 6.4 beschrieben.
Damit können Sie auch schon den Hauptunterschied zur (F6)-Taste erkennen: Ist das nächste ausführbare Kommando der Aufruf eines Funktionsbausteins, eines Unterprogramms oder eines anderen Objektes, wird alles, was hinter diesem Aufruf liegt, verdeckt ausgeführt. Der ABAP Debugger bleibt auf der Ausführungsebene und hält nach dem Aufruf vor der nächsten ausführbaren Anweisung an.
In unserem Beispiel steht der Debugger vor der SHIFT-Anweisung. Es macht bei dieser Anweisung keinen Unterschied, ob Sie mit der (F5)- oder der (F6)-Taste arbeiten; in beiden Fällen hält das System als Nächstes vor der WRITE-Anweisung an.
Die Taste (F7) ist gewissermaßen der Rettungsanker, falls Sie sich mit der (F5)-Taste einmal »verlaufen«. Haben Sie die Programmebene verlassen und befinden sich in unbekannten Tiefen, kehren Sie mit (F7) wieder an die Oberfläche zu Ihrer Ebene zurück. Man könnte umgangssprachlich auch sagen, dass die Kombination von (F5) und (F7) in einem solchen Fall wirkt, als ob Sie gleich die (F6)-Taste verwendet hätten.
Mit dem Menüpunkt Sonstiges • Zeige Liste können Sie beobachten, wie die Liste sich nach und nach entwickelt. Hält das System an einem Breakpoint, können Sie über diesen Button den augenblicklichen Zwischenstand der Liste sehen und zudem kontrollieren, ob zu diesem Zeitpunkt die Liste so aussieht, wie Sie es erwarten. Mit (F3) kehren Sie aus der Listdarstellung in den ABAP Debugger zurück.
[+] Weiter
Wie erwähnt, wird das zeilenweise Durchlaufen eines umfangreichen Quellcodes sehr schnell sehr mühselig. In der Praxis ist es daher sinnvoll, an mehreren Stellen, die Sie für kritisch halten, Breakpoints zu setzen, um den Systemzustand zu prüfen. Zwischen diesen Breakpoints können beliebig viele Anweisungen liegen. Mit (F8) verarbeitet der ABAP Debugger alle nachfolgenden Anweisungen bis zum nächsten Breakpoint und hält dort wieder an. Ist in der Programmlogik bis zum Ende kein Breakpoint mehr enthalten, wird das Programm ausgeführt und beendet. In unserem Beispiel würde anschließend die Listausgabe erfolgen.
Möchten Sie sich die Inhalte von Feldern ansehen, beispielsweise den augenblicklichen Inhalt des Feldes WA_ZTEILNEHMER-TNAME, haben Sie im neuen ABAP Debugger hierzu zwei Möglichkeiten: Entweder Sie klicken doppelt auf das Feld WA_ZTEILNEHMER-TNAME im linken Teil des Bildschirms, oder Sie schreiben den Feldnamen direkt in die Tabelle im rechten Bildschirmteil und drücken die (¢)-Taste (siehe Abbildung 6.7).
Abbildung 6.7 Augenblicklichen Feldinhalt im ABAP Debugger prüfen
Anschließend wird das Feld sofort in den rechten Bildschirmteil übernommen. Links sehen Sie den Feldnamen und rechts den augenblicklichen Feldinhalt. Lassen Sie den Debugger die nächste Anweisung verarbeiten – über den Button Einzelschritt bzw. die Taste (F5) –, sehen Sie, ob und wie die ausgeführte Anweisung den Feldinhalt verändert hat.
Auf diese Weise können im Debugger beliebig viele Felder beobachtet werden. Wie viele Sie gleichzeitig sehen können, ist von der eingestellten Fenstergröße abhängig. Für die Übrigen können Sie blättern oder die Rollbalken zum Scrollen benutzen.
Möglicherweise genügt es Ihnen jedoch nicht, nur die augenblicklichen Feldinhalte zu betrachten, sondern vielleicht möchten Sie zu Testzwecken den Inhalt eines Feldes verändern, um die Programmlogik zu testen. Beispielsweise könnte im Extremfall – durch die Konstellation der Testdaten bedingt – eine Division durch null dazu führen, dass das Programm nie eine Liste produziert, weil das System bereits vorher einen Laufzeitfehler erzeugt hat. In einem solchen Fall könnten Sie die Feldinhalte so korrigieren, dass die Division durch null vermieden wird und das Programm die erwartete Liste erzeugt. Natürlich können die Ergebnisse in der Liste nicht besser sein als die Testdaten, aber Sie können zumindest prüfen, ob das Listbild in Ordnung ist und die nicht manipulierten Felder die erwarteten Listausgaben produzieren.
Um im Debugger Feldinhalte zu ändern, klicken Sie doppelt auf den Variablennamen. Das System wechselt dann auf die Registerkarte Detailanzeige. Für diese Variable können Sie mit dem Button Feldinhalt ändern () den Inhalt der Variablen umschreiben und mit der (¢)-Taste sichern (siehe Abbildung 6.8).
Abbildung 6.8 Detailsicht der Variablen
In den obersten beiden Bildzeilen des Debuggers sehen Sie grau hinterlegt, d. h. sie sind nicht eingabebereit, zwei Felder der Struktur SY. Diese Struktur ist eine Systemstruktur, und ihre Felder werden mit SY-Feldname angesprochen. SY-SUBRC beispielsweise ist ein Feld, das den Rückgabewert einer Anweisung aufnimmt. Konnte eine Anweisung vom System formal ohne Probleme ausgeführt werden, ist der Rückgabewert eines Kommandos üblicherweise die Null. Es hängt von der Anweisung ab, ob und welchen Returncode das System in welchem Fehlerfall liefert. Weitere Hinweise zu den Returncodes erhalten Sie in Kapitel 10, »Programmablaufsteuerung und logische Ausdrücke«. Das zweite hier dargestellte Feld, SY-TABIX, ist ein Systemfeld, das in Schleifen über interne Tabellen den aktuellen Tabellenindex anzeigt.
6.3.2 Registerkarte »Strukturen« 

Die Registerkarte Strukturen verwenden Sie, wenn z. B. Veränderungen in Tabellenbereichen verfolgt werden sollen. Nachdem der Breakpoint gesetzt ist und das System die Programmausführung angehalten hat, wechseln Sie zur Registerkarte Strukturen (siehe Abbildung 6.9).
Abbildung 6.9 Tabellenarbeitsbereich prüfen
Auf der Registerkarte Feldliste sehen Sie das Eingabefeld für den Strukturnamen. Möchten Sie beispielsweise die Workarea WA_ZTEILNEHMER überwachen, schreiben Sie den Strukturnamen in das Eingabefeld und drücken anschließend die (¢)-Taste. Die zweite Möglichkeit, die Workarea anzuzeigen, ist auf der Registerkarte Desktop 1 ein Doppelklick auf den Strukturnamen, zuerst im linken Teil des Bildschirms, dann im rechten Teil. Sie gelangen daraufhin auch auf die Registerkarte Strukturen des ABAP Debuggers (siehe Abbildung 6.10).
Abbildung 6.10 Registerkarte »Strukturen«
Wie bei den Variablen arbeiten Sie nun schrittweise mit der (F5)-Taste das Programm durch und können dabei die Veränderung des Tabellenarbeitsbereichs beobachten (siehe Abbildung 6.11). Wenn Sie es jetzt schon ausprobieren möchten, können Sie mit den Beispiel-Reports aus den vorangegangenen Kapiteln die Möglichkeiten des ABAP Debuggers testen.
Abbildung 6.11 Inhalt des Tabellenbereichs nach dem Lesen eines Satzes
6.3.3 Registerkarte »Break-/Watchpoints« 

Ein weiterer, in der Praxis häufig verwendeter Arbeitsmodus des ABAP Debuggers ist der Modus für Watchpoints. Watchpoints sind insbesondere beim Arbeiten mit großen Datenmengen sehr vorteilhaft. Während ein Breakpoint einen Halt an einer bestimmten Stelle im Quellcode erzwingt, beobachtet ein Watchpoint einen Feldinhalt. Das System hält die Programmausführung an, sobald der Inhalt des beobachteten Feldes mit dem von Ihnen vorgegebenen Wert übereinstimmt.
Möchten Sie mit einem Watchpoint arbeiten, müssen Sie zunächst einen neuen Watchpoint anlegen. Hierzu wechseln Sie auf der Registerkarte Break-/Watchpoints wiederum zur Registerkarte Watchpoints und klicken dort auf den Button Watchpoint anlegen (, siehe Abbildung 6.12). Im folgenden Dialogfenster Watchpoint anlegen/ändern schlägt das System den Quellcode als zu überwachendes Objekt vor.
Abbildung 6.12 Neuen Watchpoint anlegen
[»] Sinn von Watchpoints
Stellen Sie sich eine Datei mit mehreren Tausend Datensätzen vor, bei der Sie den Breakpoint beispielsweise nach dem Lesen und vor dem Verarbeiten eines Satzes setzen. Aber woher soll der Breakpoint »wissen«, ob der Satz der ist, bei dem der zu analysierende Fehler auftritt? Der Breakpoint hält immer an derselben Stelle im Quellcode vor dem Verarbeiten eines Satzes. Wenn Sie sich dann jedes Mal schrittweise mit (F5) bis zur Fehlerstelle durcharbeiten müssten, wäre dies außerordentlich aufwendig. Arbeiten Sie in diesem Beispiel hingegen mit einem Watchpoint, hält das System immer dann an, wenn der gelesene Feldinhalt mit dem gesuchten Feldinhalt übereinstimmt – egal, ob beim ersten oder beim tausendsten Satz der Tabelle.
Geben Sie den Namen des zu überwachenden Feldes und als Bedingung den Vergleichsoperator ein, und teilen Sie dem System mit, ob der Vergleichswert in einem Feld steht oder von Ihnen direkt angegeben wird (siehe Abbildung 6.13).
Abbildung 6.13 Beispiel für neuen Watchpoint
Überprüfen Sie Ihre Angaben, und bestätigen Sie diese mit der (¢)-Taste. Auf der Registerkarte Break-/Watchpoints sehen Sie in der Statuszeile unten, dass der Watchpoint erfolgreich angelegt wurde (siehe Abbildung 6.14).
Abbildung 6.14 Registerkarte »Break-/Watchpoints« • »Watchpoints«
Sie sehen im unteren Teil des Bildschirms eine Übersicht über die aktiven Beobachtungspunkte und ihre Vergleichswerte bzw. Vergleichsfelder. Die Watchpoints in der Debugger-Sitzung können mit einem logischen Und (AND) bzw. einem logischen Oder (OR) verknüpft sein. Mit (F8) setzen Sie die Programmausführung fort. Das System hält an, sobald der nächste Break- oder Watchpoint erreicht ist (siehe Abbildung 6.15).
Abbildung 6.15 Systemhalt bei Watchpoint
Der zuletzt erreichte Watchpoint wird mit einem gelben Pfeil gekennzeichnet. In aller Ruhe können Sie nun Systemzustand, Feldinhalte, Tabellenbereiche etc. analysieren. Selbstverständlich können Sie hierzu auf alle anderen Registerkarten des ABAP Debuggers umschalten, je nachdem, welcher Modus für welche Analyse am zweckmäßigsten ist.
6.3.4 Breakpoints-Modus 

Bisher haben Sie Breakpoints im ABAP Editor angelegt. Im ABAP Debugger selbst können Sie ebenfalls weitere Breakpoints setzen, indem Sie beispielsweise auf der Registerkarte Desktop 1 doppelt auf eine Anweisungszeile klicken. Auch vor dieser Zeile erscheint dann ein Stoppschild. Mit einem Doppelklick auf das Stoppschild wird der Breakpoint im Debugger zunächst deaktiviert, bei einem erneuten Doppelklick endgültig gelöscht.
[»] Dynamische Breakpoints im Debugger verwalten
Möchten Sie die Breakpoints nicht im ABAP Editor, sondern im ABAP Debugger verwalten, schalten Sie im Debugger über die Registerkarte Break-/Watchpoints und dort über die Registerkarte Breakpoints in den Arbeitsmodus für Breakpoints (siehe Abbildung 6.16). Dort können Sie alle notwendigen Aktivitäten für Breakpoints durchführen, d. h. Anlegen, Löschen etc.
Abbildung 6.16 Registerkarte »Break-/Watchpoints« • »Breakpoints«
Dass Sie im Rahmen dieses Buches nur Session-Breakpoints benötigen, wissen Sie bereits. Der Debugger kann nicht nur Variablen als Breakpoints verwenden, sondern auch ABAP-Anweisungen, Aufrufe von Funktionsbausteinen oder Unterprogrammen und vieles mehr. Dies soll hier allerdings nur als Hinweis dienen. Wirklich benötigen werden wir diese Vielfalt von Funktionen in diesem Buch nicht. Deshalb gehen wir auch nicht näher darauf ein.
Falls Sie einen Breakpoint nicht mehr benötigen, markieren Sie auf der Registerkarte Breakpoint den Zeilenkopf des relevanten Breakpoints, und löschen Sie ihn mit dem Button Breakpoint löschen ().
[»] Lebensdauer von Break- und Watchpoints
Wie erwähnt, »leben« im ABAP Debugger gesetzte Session-Breakpoints und Watchpoints nur, solange die Debugger-Sitzung läuft. Beim Verlassen des Debuggers werden sie gelöscht. Angenommen, Sie bleiben am System angemeldet und möchten den ABAP Debugger erneut starten, dann müssen Sie die im Debugger gesetzten Break- und Watchpoints erneut definieren. Für derartige Situationen besteht die Möglichkeit, vor Verlassen des ABAP Debuggers dynamische Break- und Watchpoints zu sichern, damit diese in derselben Sitzung weiter zur Verfügung stehen. Hierzu klicken Sie auf den Button Als Session BP sichern. Die so gesicherten Punkte bleiben erhalten, bis sie explizit gelöscht werden oder Sie sich vom System abmelden, d. h. die Sitzung schließen.
Um den ABAP Debugger zu beenden, können Sie als erste Möglichkeit Ihr Testprogramm vom System mit dem Button Weiter () bzw. mit (F8) bearbeiten lassen. Sie gelangen dann automatisch wieder auf die Ebene vor dem Debugger-Aufruf, in unserem Fall im rufenden Modus, beispielsweise dem ABAP Editor. Voraussetzung hierzu ist natürlich, dass das Programm auch ordentlich endet und keinen Laufzeitfehler erzeugt.
Als zweite Möglichkeit können Sie den Debugger über dem Menüpfad Debugger • Debugger beenden (Anwendung schliessen) beenden. Die Programmverarbeitung wird in diesem Fall sofort beendet, und Sie gelangen zurück zum Easy-Access-Menü des Systems.
Die dritte Möglichkeit besteht darin, den Debugger über den Menüpfad Debugger • Debugger beenden (Anwendung läuft weiter) zu schließen. Das Programm wird fortgesetzt und der Debugging-Modus geschlossen.
Im ABAP Editor können Sie ebenfalls dynamische Breakpoints verwalten. Über den Menüpfad Hilfsmittel • Breakpoints • Anzeigen erhalten Sie eine Übersicht über alle momentan vorhandenen dynamischen Breakpoints (siehe Abbildung 6.17).
Abbildung 6.17 Breakpoints im ABAP Editor verwalten
Das Dialogfenster zeigt die dynamischen Breakpoints. Hier können Sie Breakpoints markieren, um sie anschließend zu löschen. Klicken Sie hingegen doppelt auf einen Breakpoint der Liste, springen Sie zu der Zeile im Quellcode, vor der der Breakpoint steht. Über den Bestätigen-Button () oder die (¢)-Taste verlassen Sie das Dialogfenster.
In Tabelle 6.1 sind die Buttons des ABAP Debuggers und ihre Bedeutung sowie die zugehörigen Shortcuts zusammengefasst.
Button |
Bedeutung |
Shortcut |
---|---|---|
Einzelschritt |
(F5) |
|
Ausführen |
(F6) |
|
Return |
(F7) |
|
Weiter |
(F8) |
|
Schrittweite |
Debug-Schrittweite umstellen |
(Strg) + (ª) + (F10) |
Breakpoint bei Befehl, Methode anlegen |
(F9) |
|
Layout |
Layout sichern |
(Strg) + (ª) + (F3) |
Debugger-Layer konfigurieren |
Debugger-Layer konfigurieren |
(Strg) + (ª) + (F4) |
Watchpoint |
Watchpoint anlegen |
(ª) + (F8) |
Feldnamen löschen |
– |
|
Objekte ändern |
– |
Tabelle 6.1 Buttons im ABAP Debugger
6.3.5 Statische Breakpoints 

Kurz und der Vollständigkeit halber gehen wir noch einmal auf die ABAP-Anweisung BREAK-POINT ein. Für den Einstieg oder auch zu Testzwecken während einer aufwendigen Entwicklung kann es durchaus sinnvoll sein, diese Anweisung fest in den Quellcode einzubauen. Allerdings hält die Programmausführung jedes Mal an dieser Stelle an und schaltet in den Debugging-Modus um. Mit der Zeit kann dies recht störend werden.
[ ! ] Verblüffte Endanwender
Dynamisch gesetzte Breakpoints gelten nur für den jeweiligen Benutzer und nur während der aktuellen Anmeldung. Fest eingebaute Anweisungen gelten hingegen für alle Benutzer. Falls ein Anwender, z. B. aus einer Fachabteilung, zu Testzwecken dieses Programm ebenfalls startet, hält auch bei ihm die Programmausführung nach dem BREAK-POINT-Kommando an, und das System schaltet in den Debugging-Modus um. Wahrscheinlich dürfte ein Endanwender in diesem Moment ziemlich verblüfft sein, und Sie sollten ihm solche Schrecksekunden ersparen.