14 Evergreen ABAP-Debugger Tipps – heb‘ dich von der Masse ab.

Es gab Zeiten, wo Debugging bei SAP-Beratern als exotische Tätigkeit angesehen wurde, in der man sich nicht wirklich auskannte. Doch mittlerweile gehört das Debuggen von ABAP-Programmen fast zum Standardrepertoire eines SAP-Beraters – und die Herausforderungen bzgl. Debugging werden über die Jahre nicht weniger. Konkret gibt es mindestens 5 Gründe warum du als funktioneller SAP-Berater Debugging beherrschen solltest:

#1 Fast alle Unternehmen haben neben dem SAP-Standard eine nicht unerhebliche Menge an individuellen Entwicklungen, die man vielfach nur per Debugging verstehen und analysieren kann – leider ist eine gute Dokumentation oft Mangelware.

#2 Auch wenn man sich ausschließlich im SAP-Standard bewegt, gibt es in SAP viele Anwendungen, die nur per ABAP-Entwicklung umsetzbar sind – auch hier ist es mehr als hilfreich, wenn man sich im Debugging auskennt.

#3 Fehlermeldungen in SAP sind oft gut dokumentiert und aussagekräftig, aber trotzdem habe ich immer wieder Fehlersituationen erlebt, die ich nur per Debugger analysieren konnte.

#4 Wenn man zu Suchen weiß, findet man mittlerweile zu jeder SAP-Anwendung umfangreiche Dokus. Doch speziell bei neuen Anwendungen und Systemen (EWM, TM, …) fehlt solides Know How. Auch hier ist es gut, wenn man dem Debugging gegenüber nicht abgeneigt ist.

#5 Eine enge Zusammenarbeit zwischen Entwicklern und Beratern gehört heutzutage und gängigen Teamwork. Auch hier ist nicht von Nachteil, wenn man im Debugging bewandert ist, um sich auf Augenhöhe mit Entwicklerkollegen auszutauschen.

 

Im folgenden habe ich eine Reihe von Debugger Tipps zusammengestellt, die ich in den letzten Jahren kennen und schätzen gelernt habe:

 

14 Tipps zum ABAP-Debugger

#1 Der Klassiker /h

Natürlich ist der Klassiker um in den ABAP-Debugger einzusteigen, die Eingabe von /h ins Transaktionsfeld. Damit wird der Debugger-Modus aktiviert und mit jeder folgenden Aktion (Enter, ein Button, ein Doppelklick, …) springt das System in den Debugger-Modus.

# Im Einsteigsbild (Standardsicht) sieht der Debugger-Screen wie folgt aus:

## Im oberen Bereich ist dargestellt, in welchem Programm / Unterprogramm / Formroutine du dich befindest

## Links sieht du den ABAP-Code, der aktuell durchlaufen wird: Der kleine gelbe Pfeil, der ganz links positioniert ist, gibt an, in welcher Zeile sich die Abarbeitung aktuell befindet – übrigens: Die Spalte wird auch die Breakpointspalte genannt, da durch Doppelklick auf diese Spalte, an der jeweiligen Zeile ein Breakpoint gesetzt werden kann.

## Rechts oben ist der ABAP / Dynpro Stack dargestellt: Dies ist eine Liste von Programm, die bisher durchlaufen wurden – im Grunde eine Art Historie.

## Rechts unten können einzelne Variablen, Strukturen, … dargestellt werden. Der einfachste Weg sich den Wert einer Variable  anzuzeigen, ist es, einfach links im Code ein Doppelklick auf die Variable durchzuführen. Übrigens: Ganz rechts zur ersten Variable (SVBAK-TABIX) ist ein kleiner Stift zu sehen; sofern du die Berechtigung hast, kannst du den Wert dieser Variable verändern: Einfach auf den Stift klicken, neuen Wert eingeben und mit Enter bestätigen.

 

#2 Verstehe unbedingt F5, F6, F7 und F8

Im Debugger navigierst du recht einfach mit den 4 Funktionstasten: F5, F6, F7 und F8.

# F5 – Ein Schritt weiterhoppeln: Die aktuelle Anweisung wird ausgeführt, die Variablen angepasst und der gelbe Pfeil wandert zur nächsten Anweisung

# F6 – Eine Anweisung wird ausgeführt ohne in die Details zu springen: Bspw. ist im oberen Screen ein Unterprogrammabsprung in Zeile 19 definiert; wenn du an dieser Stelle mit F6 weitergehst, wird der Perform ausgeführt, aber Debugger springt nicht in die Detail des Unterprogramms ab.

# F7 – Rücksprung aus einer Anweisung: Falls du doch per F5 ins Unterprogramm abgesprungen sein solltest und merkst, dass sich im Unterprogramm nichts Interessantes tut, dann kannst du per F7 das Unterprogramm verlassen. Anschließend gelangst du wieder an die Stelle direkt nach dem Aufruf des Unterprogramms.

# F8 – Zu letzt kannst du mit F8 das Programm ausführen und verlässt quasi den Debugger – es sein denn, du hast in weiteren Schritten Breakpoints definiert; in diesem Fall hält der Debugger beim nächsten Breakpoint.

 

* Übrigens: Du kannst die Funktionen auch mit den 4 Icons bedienen, die oben links in der Icon-Leiste des Debugger-Fensters angeordnet sind.

 

#3 Einfaches Setzen von Breakpoints

Sinnvolles Debuggen erfolgt im SAP gezielt, d.h. innerhalb einer Transaktion /h einzugeben und den Code durchzugehen, bietet keinen richtigen Mehrwert. Mit dem Debugger will man gezielt eine Codingstelle analysieren und das Systemverhalten ermitteln. Bspw. könnte folgende Fragestellung anstehen: Auf einem Lieferschein wird ein bestimmtes Feld nicht angedruckt. Nun willst du das Druckprogramm analysieren. Hier ist es nicht möglich bei der konkreten Verarbeitung des Druckprogramm ein /h einzugeben. Und genau hier helfen Breakpoints: In unserem Beispiel rufst du per SE38 das Druckprogramm auf und setzt eine Stelle, die du dir im Debugger anschauen willst, einen Breakpoint.

 

# Den Breakpoint kann man auf 2 Arten setzen:

##1 Einfach auf die Breakpointspalte (ganz links) neben der Zeile doppelklicken, in der man den Breakpoint setzen will

##2 Den Mauszeiger auf die entsprechende Zeile setzen und oben in der Icon-Leiste auf Breakpoint-Icon klicken

Jetzt kannst du aus einem Lieferbeleg (VL02N) den Lieferschein drucken. Beim Ausführen des Druckprogramms wird das System beim Breakpoint anhalten, und du kannst Schritt für Schritt das Druckprogramm analysieren.

 

#4 Dynamisches Setzen von Breakpoints

80% meiner Debuggingaktivitäten beziehen sich auf Debuggen von Fehlern. Ich will ein Beleg oder ein Stammdatum anlegen/ändern und das System gibt mir eine mehr oder weniger verständliche Fehlermeldung aus. Wenn das passiert, kannst du mit einem dynamischen Breakpoint dem Fehler aus die Schliche kommen.

# Eine Fehlermeldung im SAP-GUI wird normalerweise unten links in der Statusleiste dargestellt.

# Wenn du hierhin ein Doppelklick machst, öffnet sich das Detailfenster zur Fehlermeldung. Hier kannst du Meldungsnummer ermitteln – bspw. VL141 – die letzten drei Stellen bilden die Nachrichtennummer (141) und die Zeichen davor sind die Nachrichtenklasse (VL).

# Jetzt startest du wieder die Transaktion, in der du den Fehler erhalten hast. Bevor du zu der Stelle kommst, an dem der Fehler auftrat, aktivierst du den Debugger – /h in die Transaktionsleiste eingeben – bei der nächsten Aktion ruft das System den Debugger auf.

# So jetzt kommt das gezielte Setzen des Breakpoints an der richtigen Stelle – was wir erreichen wollen: der Debugger soll genau an der Stelle anhalten, wo die Fehler ausgegeben wird.

# Um dies zu erreichen musst du ein Breakpoint genau bei der Fehlermeldung anlegen – die Meldungsnummer hatten wir im Vorfeld ermittelt: VL141:

## Über die Menüleiste den Punkt „Breakpoints“ -> „Breakpoint bei“ -> „Breakpoint bei Message“ anklicken

## Hier im Feld ID die Nachrichtenklasse (VL), im Feld Nummer die Nachrichtennummer (141) eingeben und mit Enter bestätigen -> damit ist der Breakpoint gesetzt.

## Jetzt den Debugger mit F8 weiterlaufen lassen; wenn alles gut geht, wird der Debugger bei der Meldung anhalten und du kannst die Fehlerstelle analysieren.

 

 

#5 Was ist eigentlich ein Externer Breakpoint

Ist dir eigentlich aufgefallen, dass es in der Icon-Leiste des ABAP-Editor (SE38) zwei Icons für Breakpoints gibt?

Mit dem ersten kannst du Session Breakpoint setzen, d.h. bei diesem Breakpoint hält das System innerhalb deiner Anmeldung (Session). Mit dem zweiten Breakpoint kannst du einen externen Breakpoint setzen, d.h. hier springt der Debugger auf, wenn ein anderer User diese Stelle passiert. Natürlich ist es hier nicht der Sinn, dass du einen Kollegen debuggst, sondern dass du RFC, HTTP Requests debuggst. Beispielsweise habt Ihr eine 2 Systemlandschaft mit einem ERP und einem EWM System. Das EWM sendet qRFC-Nachrichten, die per RFC-User (bspw. RFCUSER) abgearbeitet werden. Dann kannst an die Stelle im Coding, die dich interessiert, einen externen Breakpoint setzen und noch bestimmen für welchen User externe Breakpoint gelten soll -> beim nächsten Aufruf der entsprechenden Codingstelle durch User RFCUSER springt nun bei dir der Debugger auf.

# Setzen den externen Breakpoint: Per SE38 das entsprechende Coding sich anzeigen lassen; Zeile markieren und auf das Icon externer Breakpoint klicken

# User bestimmen, für den der externe Breakpoint gültig sein soll: In der Menüleiste des ABAP-Editors auf Hilfsmittel -> Einstellungen klicken; Reiter ABAP-Editor -> Debugging: Benutzer-Option aktivieren und den entsprechenden User setzen (bspw. RFCUSER)

 

 

#6 Was ist Systembedugging bzw. Verbuchungsdebugging

Systemdebugging

Im SAP-ABAP gibt neben Anwendungsprogramm (bspw. das Programm zu einer Transaktion) auch sogenannte Systemprogramme. Beispielsweise kann man in jeder beliebigen Transaktion (bspw. MM02) in die Transaktionsleiste %_GCADDF eingeben, um diese Transaktion  automatisch in deinen Favoriten zu speichern. Und diese Funktion wird per Systemprogramm gesteuert. Wenn du den Debugger per Eingabe von /h aktivierst, dann startet der Debugger ab der Stelle eines Anwendungsprogramms – Systemprogramme werden übersprungen. Falls du aber auch in Systemprogrammen debuggen willst, dann musst du dies wie folgt aktivieren:

# In der Menüleiste des Debugger-Screens: Einstellung -> Systemdebugging ein/aus

 

Verbuchungsdebugging

Kennst du den Effekt, wenn du einen Warenausgang zu einer Auslieferung per VL02N buchst und direkt  wieder per VL02N in die Lieferung einsteigen willst, und System sagt dir, die Auslieferung wird von dir gesperrt? Was hier passiert ist recht einfach: Das System hat zunächst für den User offensichtlich seine Arbeit erledigt, doch im Hintergrund arbeitet das System noch weiter, nämlich in einem Verbuchungsmodus. Beim Debuggen gelangst du normalerweise nicht in den Verbuchungsmodus; es sei denn, du aktivierst den Verbuchungsdebugging:

# In der Menüleiste des Debugger-Screens: Einstellung -> Debugger Profil / Einstellungen ändern klicken

# Hier im Bereich „Debug Modi“ das Verbuchungsdebugging aktivieren

 

#7 Wie kann ich ein Pop-Up debuggen

Es gibt in SAP immer wieder Situationen, wo innerhalb eines Pop-Ups eine Fehlersituation entsteht mit einer wenig hilfreichen Meldung. Ein schönes Beispiel ist hier die Anlage einer neuen Batch-Input Aufzeichnung (LSMW): Wenn du hier innerhalb des Pop-Ups als Aufzeichnungsname ZZ_AUFZEICHNUNG eingibst, kommt folgende Meldung:

 

Da du hier nicht die Transaktionsleiste rankommst, kannst du den Debugger nicht per Eingabe von /h aktivieren. Hier kannst den Debugger mit folgendem kleinen Trick aktivieren:

# Leg dir auf deinem Desktop ein txt-Datei mit folgendem Inhalt an – meine Datei habe ich debug.txt genannt:

 

# Jetzt ziehe die Datei per „Drag&Drop“ in das Pop-Up-Fenster und prompt wird der Debugger-Modus aktiviert.

 

* Übrigens: Hier konnte ich per Debugger ermitteln, dass Aufzeichungsname mit einem Unterstrich dieser Stelle nicht zulässig sind.

 

#8 Und wie funktioniert das Debuggen eines Jobs

Falls du vor der Bredouille stehst einen abgebrochen Job debuggen zu müssen, kannst du einfach wie folgt vorgehen:

# Starte die Transaktion SM37 und selektiere, den Job der dich interessiert (bspw. nach Jobname, Programm, Datum) und führe die Selektion aus

# In der folgenden Jobliste (dein Selektionsergebnis) solltest du den Job, den du debuggen willst, markieren und anschl. in die Transaktionsleiste jdbg und Enter drücken – prompt springt das System in den Debuggermodus

# Hier noch ein kleiner Trick: Nachdem du im Debugger bist, solltest du ein paar mal F7 drücken, damit du die ganze Jobsteuerung überspringst und an die interessanten Stellen zu gelangen.

 

#9 Der Zauberstab des Debugging – „Springe zur Anweisung“

Eine sehr interessante Option im ABAP-Debugger ist die Funktion „Springe zur Anweisung„. Mit dieser Funktion kannst du während des Debuggens Vor- und Zurückspringen – klingt zunächst nicht spektakulär, ist aber sehr hilfreich.

Beispiel zum Zurückspringen: Du hast wie oben (#4) beschrieben einen dynamischen Breakpoint an einer Fehlermeldung gesetzt, und das System hat promt an der Meldung den Debugger gestartet. Doch diese Stelle ist zum Debuggen nicht wirklich relevant, da die Situation, die zum Fehler führt, vorher durchlaufen wurde. Jetzt kannst du wie folgt vorgehen um die richtigen Stellen zu debuggen:

# Scroll im Debuggerfenster hoch und schau dir das Coding an.

# Platziere den Mauszeiger an eine Stelle, die dir interessant erscheint

# Gehe anschließend über die Menüleiste: Debugger -> Springe zur Anweisung (oder STRG+12)

# Nun kannst du an dieser Stelle weiter debuggen und analysieren, wie es zum Fehler kam

Beispiel zum Vorspringen: Mit der Funktion „Spring zur Anweisung“ kannst du auch ABAP-Zeilen überspringen, ohne dass sie prozessiert werden. Dies kannst du beispielsweise nutzen um eine Berechtigungs- oder Einstellungsprüfung zu überspringen.

 

* Übrigens: „Springe zur Anweisung“ kannst du auch mit der Maus bedienen: STRG+SHIFT+Klicke in der Breakpointspalte auf die jeweilige Zeile -> promt springt der Debugger an die Stelle.

 

#10 Es gibt mehr als /h – /hs, /ha, /hx

Neben der /h gibt es folgende Funktions-Codes, mit denen der Debugger gesteuert werden kann:

# /hs – Mit dieser Option wird der Debugger direkt im Systemdebuggingmodus gestartet

# /ha – Der Start des Debuggers mit /ha überspringt die Dynprosteuerung

# /hx – Wenn man den Debugger startet und anschließend per F8 den Debugger wieder verlässt und zurück zur Anwendung gelagt, dann beleibt das Debuggerfenster in einem anderer Session besteht – mit /hx kann man den Debuggermodus komplett verlassen

 

#11 Endlos-Schleife debuggen

Auch in ABAP ist eine Endlos-Schleife schnell mal passiert – falls dir mal so unterkommt und du dies debuggen willst, geht das so:

# Starte die Transaktion SM50 und ermittle  den Prozess, der in einer Endlos-Schleife läuft, und markiere diesen

# Jetzt starte den Debugger über die Menüleiste: Administration -> Programm -> Debugging

 

#12 Den Code in einem separaten Fenster öffnen

Während einer Debug-Session kann es sinnvoll sein, das aktuelle Programm im ABAP-Editor zu öffnen, um sich bspw. einen Überblick zum Programm zu verschaffen oder im sich im Rahmenprogramm umzuschauen:

# Während der Debug-Session: Menüleiste -> Springen -> Navigieren zum Quellcode

 

#13 Code nicht verstanden … hier gibt es massive Hilfe

Debuggen setzt voraus, dass man ABAP – wenigstens – in Grundzügen versteht. SELECT, IF … ELSE, WHILE, DO, CASE, CHECK, … sollten auch für einen funktionellen SAP-Berater keine böhmischen Dörfer sein. Aber natürlich wird man nicht an den Erfahrungsschatz eines ABAP-Entwicklers herankommen. Wenn du beim Debuggen einen bestimmten Befehl nicht verstehen solltest, kannst du wie folgt auf die sehr umfangreiche ABAP-Dokumentation zurückgreifen:

# Starte die Transaktion SE38 und rufe ein Programm im Anzeige-Modus auf

# Platziere deinen Mauszeiger auf einen Befehl, zu dem du die Dokumentation aufrufen willst

# Nun klickst du auf das i-Icon (Hilfe zu …), das oben in der Mitte der Icon-Leiste platziert ist

# Jetzt erscheint ein Suchfenster, wo der markierte Befehl direkt als Suchbegriff vorgeschlagen wird – hier einfach per Enter bestätigen

# Im folgenden Fenster bekommst du eine wirklich umfangreiche Beschreibung zum Befehl

 

 

#14 Ein paar Systemvariablen, die man kennen sollte …

Im ABAP gibt es eine Reihe von Systemvariablen, mit denen man den Programmverhalten beeinflussen bzw. aus denen man Informationen ermitteln kann. Die berühmteste Variable ist der „sy-subrc“; diese Variable ist ein Rückgabewert, der von vielen ABAP-Anweisungen gesetzt wird. Im Allgemeinen bedeutet sy-subrc=0, dass die Anweisung ohne Probleme ausgeführt wurde. Im folgenden ein kleine Liste von Systemvariablen, die häufig Verwendung finden:

# sy-batch – sy-batch=x, wenn das ABAP-Programm im Hintergrund ausgeführt wird

# sy-index – Anzahl der bisherigen Schleifendurchläufe in DO- oder WHILE-Schleifen (inkl. aktueller Durchgang)

# sy-langu – Sparchschlüssel (einstellig) für die aktuelle Textumgebung

# sy-mandt – Mandantenkennung

# sy-repid – Name des aktuellen ABAP-Programms

# sy-subrc – Rückgabewert der letzten ABAP-Anweisung (sy-subrc=0 -> alles OK)

# sy-tabix – Zeilennummer des Tabellenindex einer internen Tabelle

# sy-tcode – Aktueller Transaktionscode

# sy-title – Titelbalken-Text des Dynpros erscheint.

# sy-uname – aktueller Benutzer

# sy-uzeit – Systemzeit

 

cu, Isa.