In den Händen eines Anfängers ist ein Lichtschwert bestenfalls eine Leselampe, in den Händen eines Meisters jedoch ist es eine mächtige Waffe.
Genauso verhält es sich auch mit dem ABAP Debugger. Doch keine Sorge, du musst keine jahrelange Jedi-Ausbildung absolvieren. Dieser Artikel bietet dir die Grundlagen, um deine ersten Schritte im ABAP Debugger zu machen. Egal ob Consultant, Anwender:in oder Entwickler:in, hier lernst du die Grundlagen, die dir helfen, den Einstieg in die Welt des Debbugens zu meistern. Bereit für deine Padawan-Ausbildung? Dann los!
Wir schauen uns zuerst die grundlegende Bedienung und den Aufbau des Debuggers an. Danach präsentiere ich dir effektive Strategien zum Erkennen und Lokalisieren eines Fehlers. Einmal gefunden, wollen wir das Problem natürlich beheben. Hierfür gebe ich dir hilfreiche Tricks mit, mit denen du mögliche Lösungen finden und testen kannst. Zum Schluss gibt es noch einen Troubleshooting-Teil mit Lösungsideen, falls du mal nicht mehr weiter kommst.
Was ist der ABAP Debugger?
Es handelt sich um ein ABAP Programm, welches speziell dafür entwickelt wurde, andere ABAP Programme zu analysieren und Schritt für Schritt auszuführen. Mit Hilfe von Haltepunkten, sogenannten Break-Points, kannst du an einer beliebigen Stelle im Programmcode anhalten und die aktuellen Umgebungsvariablen inspizieren.
Warum sollte ich den ABAP Debugger erlernen?
Das Debugging ermöglicht es dir Probleme wie fehlendes Customizing in einem SAP System schnell zu finden und zu beheben. Außerdem kannst du Prozessabläufe nachvollziehen, um diese beispielsweise deinen Fachkollegen zu erläutern. Du erlernst die Superkraft, hinter die Kulissen zu schauen.
Ready for Takeoff – dein Start ins Debugging
Die einfachste Möglichkeit den Debugger zu starten, ist im Transaktionsfeld der SAP GUI den Begriff /h und Enter einzugeben. Nun passiert erstmal nichts. Doch sobald einen Klick auf ein Feld oder eine andere Eingabe vornimmst, wird sich der Debugger öffnen.
Willst du an einem speziellen Punkt im Programm anhalten, öffne das Programm in der Transaktion SE80 oder SE24 und mache einen Rechtsklick auf den gelben Balken links neben dem Programmcode und wähle „Set Session Breakpoint”. Wenn du das Programm erneut ausführst, wird sich der Debugger öffnen und am Breakpoint anhalten.
Grundlegender Aufbau
Auf der linken Seite siehst du den ABAP Code, welcher als Nächstes ausgeführt wird. Der gelbe Pfeil markiert die Zeile, an der das Programm stehen geblieben ist. Der Pfeil zeigt immer auf die Zeile, die als Nächstes ausgeführt wird.
Auf der rechten Seite ist der Stack zu sehen. Mit dem Aufruf-Stack behältst du den Überblick über aktive Unterprogramme, Methoden oder Funktionen in einem Programm während der Laufzeit. Wird ein Unterprogramm, eine Methode oder Funktion aufgerufen, so wird ein neuer Eintrag auf dem Stack angelegt. Im Screenshot hat der Stack zwei Einträge. Der Pfeil am oberen Eintrag zeigt an, dass aktuell das Programm ZSK_FILL_TABLE ausgeführt wird. Ist das Programm abgearbeitet, wird der oberste Eintrag wieder vom Stack gelöscht und das darunter liegende Programm weiter ausgeführt. Mit einem Doppelklick auf die erste Zeile eines Stackeintrags, kannst du zum Quellcode des jeweiligen Programms wechseln.
Unter dem Stack ist die Variablen-Anzeige. Der ABAP Debugger unterscheidet hier zwischen den Abschnitten „Variables 1” und „Variables 2”, „Locals” und „Globals”. Die ersten beiden Abschnitte stehen für dich zur freien Verfügung. Hier kannst du dir die aktuellen Werte von Variablen anzeigen lassen. Das machst du, indem du entweder einen Doppelklick auf eine Variable im Code-Bereich machst, oder den Namen der Variable eintippst und Enter drückst. Dann siehst du außerdem den Typ und die Länge der Variable. Um Objekte und Listen genauer zu inspizieren, genügt auch dort ein Doppelklick. „Locals” und „Globals” bezeichnen die Bereiche, in denen lokale (im aktuellen Programm sichtbare) und globale (überall sichtbare) Variablen angezeigt werden.
Für den Anfang arbeiten wir mit der Standardansicht. Jedoch lassen sich die Debuggerfenster an den seitlichen Symbolen auch individuell anpassen. Je nach Vorliebe können auch die Ansichten „Desktop 1”, „Desktop 2” und „Desktop 3” genutzt werden.
Navigation
Ein ABAP Programm wird ausgeführt, indem eine Transaktion durch einen User oder ein automatischer Prozess – zum Beispiel durch ein externes System – ausgeführt wird. Hierbei ist es wichtig zu verstehen, dass die Codezeilen grundsätzlich Zeile für Zeile nacheinander ausgeführt werden. Wenn eine Codezeile des Unterprogramms eine Methode oder Funktion aufruft, wird ein neuer Stackeintrag erzeugt und dieser wird zuerst abgearbeitet, bevor es mit dem eigentlichen Programm weitergehen kann.
Hier kommen Navigationstasten ins Spiel. Am besten gewöhnst du dir gleich die Tastenkürzel F5, F6, F7 und F8 an.
Die wichtigsten Tasten beim Debugging
- F5 führt die aktuelle Codezeile aus und geht, wenn möglich in ein Unterprogramm, Methode oder Funktion hinein. Dies ist praktisch, wenn du einen Fehler in der Tiefe suchst. Diese Taste ist dein Suchscheinwerfer.
- F6 führt die aktuelle Codezeile aus und bleibt dabei im gleichen Programm. Dies hat den Vorteil, dass du schneller voran kommst, jedoch auch schneller etwas übersiehst. Es ist deine Turbo-Taste.
- F7 führt alle Codezeilen des aktuellen Programms aus und springt in aufrufende Programm im Stack. Hiermit kannst du wieder „auftauchen”.
- F8 führt alle Codezeilen bis zum Ende aus. Wenn du an keinen weiteren Breakpoints vorbeikommst, wird sich der Debugger schließen. Damit ist dein Flug zu Ende und du kannst wieder aussteigen.
Nachdem wir nun wissen, wie wir uns fortbewegen können, um Fehler zu finden, müssen wir erstmal wissen, woran wir einen Fehler überhaupt erkennen können.
Fehler richtig erkennen
Fehler in ABAP können vielschichtig sein. Viele Generationen von SAP Releases haben das System an vielen Stellen zu einer großen Software-Zwiebel heranwachsen lassen, in deren Schalen viele unterschiedliche syntaktische Codes und Technologien zum Einsatz kommen. Ich stelle dir die Klassiker vor, die du immer im Hinterkopf behalten solltest.
Sy-Subrc
Der grundlegendste Indikator für einen Fehler ist die Systemvariable Sy-Subrc. Die ist so wichtig, dass sie direkt im Debugging Cockpit eingebaut ist (rechts oben). Sie gibt dir darüber Auskunft, ob alles in Ordnung ist, oder ob ein Problem aufgetreten ist. Die Variable wird üblicherweise von Funktionsbausteinen und Datenbankzugriffen geändert – wenn Sy-Subrc den Wert null hat, dann war der Datenbankzugriff erfolgreich, du kannst dir also merken: Wenn Sy-Subrc Null ist, gab es Null Fehler – wenn Sy-Subrc den Wert vier hat, dann ist ein Problem aufgetreten. Die Bedeutung des tatsächlichen Wertes ist nicht einheitlich definiert und hängt vom Kontext ab. Dies bedeutet jedoch, dass du dir das SQL Statement oder den Funktionsbaustein genauer ansehen solltest.
Try – Catch
Bei dem syntaktischen Konstrukt Try-Catch handelt es sich um eine Fehlerbehandlung, die der Entwickler bereits beim Entwickeln berücksichtigt hat. Beispielsweise kann versucht werden, eine Zahl durch null zu teilen. Dies würde normalerweise zu einem Kurzdump (Absturz) führen und das ABAP Programm abbrechen. Ist es jedoch mit einem Try-Catch eingeklammert, wird im Fehlerfall der „Catch”-Block ausgeführt und der Fehler somit kontrolliert behandelt. Damit ist er wie ein Fallschirm, der das Programm im Notfall auf den sicheren Boden rettet. Siehst du also, dass ein Catch-Block ausgeführt wird, dann solltest du dir den Try-Inhalt genauer ansehen. Du solltest im Hinterkopf behalten, dass alle vorangegangenen Hinweise nicht zwingend bedeuten, dass ein Fehler oder ein Problem vorliegt. Oft ist das Programmverhalten vom Entwickler so gewollt und zusätzlich durch Sy-Subrc-Checks oder ein Try-Catch abgesichert.
Kurzdump
Ein Kurzdump in der SAP Welt ist das Äquivalent zum Blue Screen of Death bei Windows, den sicher jeder Windows User schon einmal erlebt hat. Der Kurzdump weist mit an Sicherheit grenzender Wahrscheinlichkeit auf ein Problem hin. Hier ist oft das Problem, dass das ABAP Programm mit falschen Daten befüllt wurde: Beispielsweise sind eingegebene Zeichen zu lang oder zu kurz, oder es wurde eine Zahl erwartet, aber eine Zeichenkette eingegeben.
Um den Fehler genauer zu identifizieren, kommt uns hier der post-mortem Debugger zur Hilfe. Dieser erlaubt uns, nachträglich an die Stelle zu springen, an der das Problem aufgetreten ist. Er ist vergleichbar mit einer Blackbox, die nach einem Absturz genauere Informationen über den Hergang des Unfalls liefert.
Welche Strategien gibt es, um Fehler zu finden?
Wie findet man am besten einen Sith Lord in der Galaxie? Jeden Stern und Planeten einzeln absuchen? Das dauert zu lange. Die Galaxie in Sonnensysteme unterteilen und stichprobenartig kontrollieren? Wahrscheinlich übersieht man dabei wichtige Hinweise.
Besonders effizient ist hier die binäre Suche. Teile den Code in zwei Hälften und setze in der Mitte einen Breakpoint. Tritt das Problem vorher bereits auf, sollte man sich den Code bis zu dieser Hälfte ansehen. Tritt das Problem danach auf, logischerweise den nachfolgenden Code. So hat man den Suchraum halbiert. Dies wiederholt man, bis sich das Problem eingrenzen lässt.
Wie sollte man vorgehen, wenn man gar nicht weiß, welcher Code ausgeführt wird? Hierbei helfen die nachfolgenden Strategien:
Aller Anfang ist leicht – mit diesem Tipp
Tritt der Fehler beim Ausführen oder Bedienen einer SAP Transaktion auf, so kann man wie bereits am Anfang beschrieben in der Transaktionsleiste /h eingeben, und dann die Eingabe wiederholen, um den Fehler zu reproduzieren. Nun startet der Debugger in der Verarbeitungslogik für die Benutzeroberfläche. Mithilfe der später erläuterten Deep Dive Technik können wir uns zu der darunter liegenden Anwendungslogik durcharbeiten.
Das Puzzle von den Ecken aus lösen
Woran wurde bemerkt, dass möglicherweise ein Fehler aufgetreten ist? Sind die Daten in einer Transaktion anders, als sie erwartet wurden? Wurde ein Kurzdump angezeigt? Fange bei dieser Strategie an, den Fehler vom Ende her zu identifizieren. Schauen wir uns ein konkretes Beispiel an. Beim Bedienen der Transaktion ist der im Screenshot sichtbare Fehler F5132 aufgetreten. Diese Meldung liegt also am Ende der Kausalkette, die zu dem Fehler geführt hat.
Nun arbeiten wir uns zur Fehlerursache vor, indem wir einen Message-basierten Breakpoint nutzen. Hierzu starten wir erneut den Debugger und erstellen den Breakpoint wie im Screenshot unten gezeigt.
Nun schließen wir den Debugger wieder und rufen die Transaktion mit der Fehlermeldung erneut auf. Anstatt der Meldung öffnet sich nun der Debugger an genau der Stelle, die die Meldung im ABAP Programm auslöst. Anhand des Aufruf-Stack können wir nun den vorher ausgeführten Code identifizieren. Ergänzend kann hier mit dem Verwendungsnachweis gearbeitet werden. Somit setzt sich das Puzzle nach und nach zusammen.
Den Spuren aufmerksam folgen – Variablen richtig überwachen
Genau wie ein Pilot seine Flughöhe, Geschwindigkeit und Anstellwinkel ständig überwachen muss, müssen wir im Debugger die für uns relevanten Variablen ständig im Blick behalten. Nur so fällt uns auf, wenn Daten verloren gehen oder fehlerhaft weitergegeben und gespeichert werden. Hier kommt die Variablenanzeige ins Spiel. Klickst du im Quellcode doppelt auf einen Variablennamen, wird der Variablenname, -typ und -wert automatisch in die Anzeige hinzugefügt. Handelt es sich um ein Literal (Zahl oder Zeichenkette), so wird der Wert direkt angezeigt. Bei Objekten, Referenzen und internen Tabellen ist ein zweiter Doppelklick auf den Wert in der Variablenanzeige erforderlich, um die einzelnen Einträge zu inspizieren.
Für den Anfang lohnt es sich, erstmal jede Variable anzusehen, die im Hauptspeicher angelegt ist. Aber welche Variablen sind besonders wichtig? Bei einem Funktionsaufruf gibt es Eingabe- und Ausgabe-Parameter. Diese haben meist einen Präfix namens „iv” (importing variable) oder „ev” (exporting variable). Vor einem Funktionsaufruf sollte man die Eingaben und nach einem Funktionsaufruf die Ausgabe überprüfen. Genauso wie man die Ein- und Ausgaben überprüfen sollte, wenn man seinen 12-jährigen Sohn mit 20 € zum Bäcker schickt und dieser statt Brot mit einer großen Tüte Süßigkeiten zurückkommt.
Deep-Dive
Beim Deep-Dive tauchst du so tief ab, wie du nur kannst. Durch den intensiven Einsatz der F5-Taste gehst du Zeile für Zeile durch, bis dir etwas auffällt oder komisch vorkommt. Der Vorteil an dieser Strategie ist, dass du nichts übersiehst. Diese Methode ist jedoch auch die zeitintensivste und du wirst dich schnell in SAP-Standard-Code oder Makros verlieren, die ungefähr so leicht zu entziffern sind wie ägyptische Hieroglyphen. Je näher du das Problem eingegrenzt hast, desto effektiver ist diese Technik.
Fehler gefunden? Lösungsideen probieren!
Mithilfe der bis jetzt genannten Techniken bist du in der Lage, Fehler und Unstimmigkeiten zu erkennen und zu isolieren. Jetzt beginnt die Suche nach einer Lösung. Eine Lösung kann das einfache Ausfüllen einer Customizing Tabelle, das Aktivieren eines BADIs oder das Vergeben von Berechtigungen sein. Sollte dies nicht ausreichen, verrate ich dir einige mächtige Tricks, die mit Bedacht eingesetzt werden müssen. Sie helfen dir dabei, mögliche Lösungen auszuprobieren und Szenarien zu Testen. Hinweis: Diese Praktiken sind ausschließlich in Entwicklungs- und Qualitätssicherungssystemen zu verwenden. In Produktivsystemen kann dessen Einsatz schwerwiegende Folgen haben.
Jedi Gedankentricks
Sturmtruppler: „Halt! Ihre Papiere bitte.“
Obi-Wan: „Das sind nicht die Droiden, die ihr sucht.“
Strumtruppler: „Das sind nicht die Droiden, die wir suchen.“
Obi-Wan: „Er kann passieren.“
Sturmtruppler: „Er kann passieren.“
Obi-Wan: „Weiterfahren.“
Sturmtruppler: „Weiterfahren, weiterfahren!“
So wie Obi-Wan hier die Gedanken der Sturmtruppler verändert hat, können wir im Debugger den Variablenzustand der aktuellen Laufzeitvariablen verändern. Somit können wir testen: Wie wäre der Prozess denn weitergelaufen, wenn unsere Datenbankabfrage das richtige Ergebnis geliefert hätte? Oder: Welches Ergebnis hätte der Funktionsbaustein zurückgeliefert, wenn wir ihm eine andere Hausnummer mitgegeben hätten? Deiner Kreativität sind hier (fast) keine Grenzen gesetzt.
Im folgenden Beispiel sehen wir, dass der Code mit einem leeren Wert für die Variable der Anschlussobjektnummer aufgerufen wird. Dies wird später im Prozess zu einem Fehler führen. Über einen Klick auf den Stift, lässt sich der Wert der Variablen einfach ändern. Nun können wir uns eine korrekte Anschlussobjektnummer aus dem System heraussuchen, diese einfügen und mit Enter Bestätigen.
Erwähnenswert ist an dieser Stelle, dass die Import-Variablen einer Methode nicht geändert werden können. Oft kann man hier als Workaround in der aufrufenden Methode die Übergabeparameter ändern, um diese Limitierung zu umgehen.
Code überspringen
Die Fähigkeit, Code zu überspringen, ist die mächtigste Berechtigung und darf nur in Test- und Qualitätssicherungssystemen genutzt werden. Im folgenden Beispiel ist wieder die Anschlussobjektnummer leer, was dazu führen wird, dass das Catch Statement und die Methode raise_exception ausgelöst wird. Dies wollen wir verhindern, daher gehen wir mit der Maus an das Ende des Abschnitts und wählen Rechtsklick, Springe zur Anweisung. Somit können wir den nachfolgenden Code weiter testen.
Hier ist jedoch auch Vorsicht geboten, da das Überspringen von Code Folgefehler erzeugen kann. Dies solltest du immer im Hinterkopf behalten.
Nachdem wir nun die Grundlagen des Debuggers beleuchtet haben, wird es Zeit, praktische Erfahrungen zu sammeln. Doch wie lassen sich die in diesem Artikel gelernten Techniken im Zusammenspiel anhand eines konkreten Beispiels umsetzen? Und was sind die üblichen Fallstricke, die es beim Debugging zu beachten gibt? Diese Fragen behandeln wir in kommenden Artikeln genauer.
Frag uns!
Solltest du nach all diesen Tipps und Tricks immer noch nicht weiter kommen, komm gerne auf unsere SAP-Profis von adesso orange zu. Mit unserer umfangreichen Projekterfahrung stehen wir dir und deinem Team zur Seite, um SAP erfolgreich zu implementieren.
