SAP Debugging, Laufzeitfehler (Dumps) und ABAP-Debugger

Zu unterscheiden sind syntaktische Fehler, die bereits beim kompilieren aufgedeckt werden können, Laufzeitfehler und semantischen Fehler, welche spezifisches Fachwissen und Anwendertests (UATs) erfordern. Fokus sind hier insbesondere die Laufzeitfehler, welche in abfangbare und nicht abfangbare Laufzeitfehler untergliedert werden können. Können diese sinnvoll im Programm behandelt werden, so sind diese Fehler abfangbar (Catch System-Exceptions).

Debugger-Aufruf: SE38 [Debugging], /h, Breakpoints, via Key Words (Break-Point bzw. Break User) /hs (inkl. Systemaufrufe), JDBG (Job Debugging) oder TXT-File (Popupdebugging),

Ganz grob erläutert: Einzelschritte, grobe Schritte, Rückkehr ins Hauptprogramm und Ausführung bis Breakpoints/Programmende.

  • [F5]-Einzelschritt: Führt genau eine Programmanweisung inkl. Verzweigung in Unterprogramme/Funktionsbausteine aus.
  • [F6]-Step-Over-Ausführung: Man kann Details (Modularisierungseinheiten) überspringen und das Programm in groben Schritte durchlaufen.
  • [F7]-Weiterfunktion: So kann man auch aus der aktuellen Modularisierungseinheit (Loop, Funktionsbaustein, Insert, Methode etc.) rausspringen und ins über gelagerte Programm zurückkehren.
  • [F8]-Return-Funktion: Führt Programm bis zum Breakpoint bzw. Programmende aus. Man kann also z.B. irgendwo im Quellcode via Doppelklick einen Breakpoint setzen und dann via [F8] die Durchführung des Programms bis dahin veranlassen (z.B. um dort die Variablenwerte zu prüfen).
  • Menüpunkt „continue to curser“, damit kann man wieder zurückkehren.
  • [Gelber Pfeil] Dort wo man Breakpoints setzt, befindet sich auch ein gelber Pfeil über den man identifizieren kann, bis zu welchem Punkt das Programm derzeit ausgeführt wurde.
  • Navigationsbutton: Steuerung der Programmausführung
  • 12 Screens und 4 gleichzeitig via Toolbar rechts einblendbar
  • Desktop 3: Man kann globale und lokale Variablen anzeigen lassen. Zweitere sind nur in der Subroutine, in der Sie deklariert wurden, bekannt.
  • Tabellenreiter: Doppelklick auf Tabellennamen führt auch dahin
  • ABAP and Screen Stack: Über diese Tools kann man auch diesen Bildschirm auswählen, um die Modularisierungseinheiten zu sehen. Via Klick auf den linken Bildschirmrand, kann man den gelben Pfeil dort platzieren und zum Quellcodeabschnitt springen und ggf. bis dahin ausführen (Breakpoint und F8).
  • [SY-SUBRC]-Systemparameter: Dieser wird im Debugger oben rechts angezeigt und beim durchlaufen des Programms via [F5] gibt es einen Hinweis auf Fehler (insofern dort z.B. eine 4 steht).
  • SY-TABIX: Gibt einen Hinweis in welcher Quellcodezeile, der Wert/Eintrag gefunden wurde.
  • Breakpoint/Watchpoints: Dieser Reiter bietet eine Überblick über alle gerade verwendeten Breakpoints und Watchpoints. Dort kann man z.B. am Ende des Debuggings alle löschen.

Über den Stift lässt sich der Wert ändern. Im Screenshot ist ein Beispiel aufgeführt, wie man schnell zur Tabelle LWA_MARA das Feld MATNR ändern kann. Man muss nicht extra via Doppelklick in die Tabelle navigieren und dort weiter in eine Zeile, sondern kann den Feldnamen direkt inkl. Tabellenprefix eintragen und auf ändern wechseln. Einzelne Variablen können ohnehin dort direkt geändert werden. Falls mal der Button mit dem Stift fehlt, kann man auch via Vorwärtsnavigation z.B. in die Struktur und dessen Feldliste wechseln, um dort den Wert zu ändern.

Tabellenzeile löschen, ändern oder hinzufügen: Tabellenreiter, Zeile markieren, rechts das Werkzeugsymbol wählen und im Menü löschen, hinzufügen oder ändern der Tabellenzeile auswählen. Beginnt die Tabelle mit IT, ist es eine interne Tabelle die zur Laufzeit des Programms gültig ist. Dort können Zeilen gelöscht werden. Bei permanenten Tabellen, sollte man sich der Auswirkung bewusst sein. Beim hinzufügen ist zwischen „Einfügen“ („insert“; hinter der zuvor markierten Zeile) und „Anhängen“ (append) zu unterscheiden; was auf den Tabellenindex unterschiedliche Auswirkungen hat. Der Index aller nachgelagerten Zeilen, wird beim Einfügen angepasst.

SAP-Tabellen in SE16N ändern: SE16N im Selektionsbildschirm /h eintragen und im Debugger die Variablen „gd-sapedig“ und „gd-EDIT“ eintragen, um diese schließlich via ändern jeweils mit dem Wert X zu versehen. Jetzt [F8] drücken und danach sind die Tabellenwerte änderbar. Ein Zeile zu kopieren, Zeile einfügen zu wählen und dann die kopierten Werte einzutragen, ist oft effizient und besser als die Zeilenkopierfunktion zu nutzen (Primärschlüssel sind dann nämlich nicht änderbar).

  • Breakpoints: Setzt man um Variablenwerte bzgl. obiger Datentypen zu einem bestimmten Haltepunkt anzuzeigen. Im Quellcode z.B. einfach BREAK <User> eingeben.  Breakpoint vom Entwickler angucken, dann einfach Desktop 3 Variable SY-UNAME ändern auf Entwickler-User. Alternative wäre auch generell BREAK-POINT möglich, aber i.d.R. ist die benutzerspezifische Setzung sinnvoller.
  • Watchpoints: Um das Programm anzuhalten, sobald eine Variable einen bestimmten Wert annimmt.
    • So möchte ich z.B. eine unendliche Schleifenanzahl beim Lesen einer Tabelle vermeiden und lasse das Programm daher irgendwann stoppen. Reiter Break./Wachtpoints, Condition in Zeile Session Breakpoint und im Popup sy-tabix = 40 eingeben.
    • Berechtigungsprüfung finde und überspringen. [Stop-Symbol], ABAP-Befehle, ABAP-Statement „AUTHORITY-CHECK“ und unter Funktionen FuBa „AUTH_CHECK_TCODE“. EndFunktion anklicken und im Mausmenü „Springen zur Anweisung wählen und damit die Berechtigungsprüfung überspringen. Damit könnte man die fehlende SU01-Berechtigung umgehen und sich selbst SAP_ALL zuteilen. Mehrmals muss man dann gewisse Anweisungen analog überspringen.
    • Analog kann ich das Programm für einen Variablenwert anhalten, um dann genau die Codestelle zu finden wo dieser gesetzt wurde.
    • Ich kann auch ein ABAP-Statement (z.B. Select), für die Breakpointsetzung definieren und dann via [F8] jede Select-Anweisung anspringen. Analog kann ich auch Methoden-/Funktionsaufrufe oder eine Message aufspüren.
  • Dynamischer Breakpoint/Session Breakpoint: Menü/Hilfsmittel/Breakpoints/Setzen. Diese Breakpoints verschwinden automatisch bei Abmeldung des Users vom System. Ein Doppelklick auf die richtige Quellcodezeile bewirkt ebenso die Setzung eines dynamischen Breakpoints. Dieser wird bereits beim Verlassen des aktuellen Debugging-Vorgangs gelöscht. Man setzt diesen gerne, um schnell via [F7] an eine Codestell springen zu können und bis dahin alles auszuführen.
  • Externer Breakpoint: Beispielsweise, wenn das Programm über eine Fiori-App oder WebServices aufgerufen wird.
  • Reverse Breakpoint: Menüpunkt „continue to curser“, damit kann man wieder zurückkehren.
  • Reiter Breakpoint/Wachtpoints, Breakpoint-Erstellung, Reiter Message und dort Messageklasse und Nachricht aus dem Popup (z.B. Klasse SAPBADDEMOS Nummer 001 & Typ I=Information/Warnung/Fehler) eingeben. So finde ich im Quellcode den Ursprung des Popups.
  • Alternative über Systemparameter: Reiter Breakpoint/Wachtpoints, Reiter „Watchpoint“, Erstellen-Button und Systemvariable SY-MSGID eingeben. Via [F8] wandere ich jetzt jeweils zum Quellcode, wo gerade diese Systemvariable befüllt wird.
  • Datentypanzeige: [Felder] mit Auswahl eingebauter Datentyp bzw. Struktur (Standard) oder Tabellentyp. Danach bis zu 8 Datentypen oder eine Tabelle manuell bzw. via Doppelklick eintragen. Man kann hier dem Programm auch neue Variablenwerte mitgeben. Interne Tabellen können ebenso geändert werden (neue Zeile bzw. Werte). Systemparameter kann ich natürlich auch anzeigen.

Zwei Systemparameter werden direkt im ABAP Debugger oben rechts angezeigt und bieten Ihnen wertvolle Informationen zur auftretenden Fehlern und Datenursprüngen. Diese sollten Sie kennen und den Rest kann man hier im Bedarfsfall nachgucken. Parameter sind hingegen die Daten, die man im Dialog mit dem Anwender durch seine Eingabe abfragt und erhält.

  • SY-SUBRC: Über den Parameter können bei der schrittweise Programmdurchführung Fehler aufgespürt werden. Wird zum Beispiel zu einem Primärschlüssel kein passender Wert in einer Tabelle zur Selektion gefunden, so wird 4 als Fehler ausgegeben. Wenn dort 0 steht, ist alles OK.
  • SY-TABIX: Gibt einen Hinweis in welcher Quellcodezeile, der Wert/Eintrag gefunden wurde. Bspw. wurde er dort deklariert und direkt mit einem Wert initialisiert oder aber aus einer Tabelle selektiert und in die Variable übertragen.
  • SYST: Wenn man das eingibt und darauf Doppelklick ausführt, kann man direkt alle Systemvariablen anzeigen.
  • SY-TABIX: Wenn ohne Bedingungen über Tabelle geloopt wird, dann erhält man die Schleifenzahl. Wenn über eine Tabelle geloopt wird mit Bedingungen, dann ist SY-TABIX gleich dem Index der gefundenen Datensätze der internen Tabelle.
  • SY-LANGU: Einstelliger Sprachschlüssel bspw. D und E.
  • SY-DYNGR & SY-DYNNR: Bildgruppe des aktuellen Dynpros und Dynpronummer.
  • SY-REPID: So identifiziert man z.B. das Rahmenprogramm indem die Prozedur implementiert wurde. Man muss also via Breakpoint und [F8] an diese Stelle wandern und dann diesen Systemparameter abfragen.
  • SY-INDEX: Damit kann ich rausfinden, wie oft bereits die Schleife durchlaufen wurde. Sinnvoll, falls ich z.B. gerade einen aktuell laufenden Job debugge und rausfinden will, warum der so lange läuft.

Feld

Kurzbezeichnung

SY-BATCH

Batch-Markierung; hat bei einem im Hintergrundprogramm laufenden Programm ein X.

     

SY-CALLD

Call Modus aktiv (X)

     

SY-DATUM

Datum des Applikationsservers, während SY-DATLO das lokale Datumsformat des Benutzers angibt. 

     

SY-DBCNT

Datenbank-Zeilen

     

SY-FDPOS

Fundstelle in Feld

     

SY-INDEX

Schleifenindex

     

SY-LANGU

Sprachenschlüssel

     

SY-MANDT

Mandant

     

SY-MSGNO

Nachrichtennummer

     

SY-MSGTY

Nachrichtentyp

     

SY-MSGV1

Nachrichtenvariable

     

SY-MSGV2

Nachrichtenvariable

     

SY-MSGV3

Nachrichtenvariable

     

SY-MSGV4

Nachrichtenvariable

     

SY-SPONO

Spoolnr. bei Druck

     

SY-SUBRC

Rückgabewert = 0, dann kein Fehler.

     

SY-SYSID

SAP-System-ID

     

SY-TABIX

Tabellenzeile

     

SY-TCODE

Transaktionscode

     

SY-UCOMM

Funktionscode

     

SY-UNAME

Benutzername

     

SY-UZEIT

Uhrzeit des Applikationsservers, während SY-TIMLO die lokale Uhrzeit des Benutzers angibt. 

     

Laufzeitfehler (ST22)

  • Kurztext
  • Lösungsvorschläge
  • Anzeige aller Systemparameter
  • Fehlerursache im Quellcode via Symbole (>>>>>) hervorgehoben

Programmausführung (SE38)

  • Programm – Prüfen – Erweiterte Programmprüfung, um z.B. auch die Parameterübergabe an externe Programme oder Funktionsbausteine zu prüfen usw.
  • [F8] Laufzeitfehler erzeugen. Über Symbole (>>>>>) wird die Fehlerursache im Quellcode hervorgehoben. Außerdem ist oben der Kurztext hilfreich.
  • Menü einschalten und dort Lösungsvorschläge sehen

Txt-File mit

Diese Datei auf das Popup ziehen und damit den Debugger einschalten. Über das Tool ABAP and Screen Stack, kann man zwischen den Modularisierungseinheiten navigieren und bekommt z.B. einen guten Überblick über das Programm. So kann man sich einen Überblick verschaffen und findet z.B. ein BADI, welches den Namen Popup hat. Via Klick auf den linken Bildschirmrand, kann man den gelben Pfeil dort platzieren und zum Quellcodeabschnitt springen und ggf. bis dahin ausführen (Breakpoint und F8). Beim Öffenen des Debuggers springt dieser ggf. bereits an die richtige Stelle; z.B. Zeile 71 Message i004 (zmm)1.

SM37, in das Eingabefeld JDBG eingeben (statt /h), mehrmals [F7], bis man im Job gelandet ist (dessen Programmnamen muss man vorher nachgucken). Debugging aktiver Jobs erfolgt via SM50 z.B. bei langer Laufzeit. Job markieren, Administrator/Programm/Debugging im Menü wählen und man landet dann genau dort, wo das Programm gerade ist/hängt (und identifiziert z.B. eine unendliche Schleife). Man könnte dann z.B. im Menü Debugger/Exit wählen bzw. diesen in SM37 beenden ([Stop] und [Delete]) und das Programm zunächst korrigieren.

Transaktion im Änderungsmodus öffnen, /h eingeben und z.B. [Speichern] anklicken. Im Menü „Breakpoints“ die Menüpunkt „Breakpoint at Statement“ wählen, um dann im Popup den ABAP-Befehl (Command) „call customer“ einzugeben. Danach kann man die Programmausführung via [F8] bis zum Customer oder User Exit veranlassen und eine Analyse einleiten. Im Bildschirm „ABAP and Screen Stack“ findet man bisher ausgeführten Modularisierungseinheiten und kann sich dort jeweils die „Function“ und „Includes“ genauer angucken, um das relevante User Exit zu finden. In einem Funktionsbaustein ist ggf. das User Exit als „Include“ enthalten.

Umfangreiche Analyse eines Programms

  • SE24 globale Klassen (cl; mit Methoden und Attributen)
  • SE80 Methoden (spezifiziert in lokalen/globalen Klassen)
  • SE80 Subroutinen (Formerstellung direkt in Programmen)
  • SE37 Funktionsbausteine (Aufruf via diverser Programme)
  • SE38 lokale Klassen (lcl, nur im deklarierten Bereich gültig)
  • SE80 Prozeduren (Unterprogramme inkl. Schnittstelle mit lokalen Datenbereich. Diese können in irgendeinem Programm definiert und dann aus anderen Programmen aufgerufen werden.)
  • SE38 Includes (für Widerverwendbarkeit bzw. Modifikation von Standardprogrammen und via Funktionsmodule in Programme eingebunden)
  • SE38 Verarbeitungsblöcke: Ergebnisblöcke, Dialogmodule und Prozeduren

In den Klammern finden Sie Hinweise zur Syntax bzw. übliche Namenskonventionen bzgl. des Prefix. Zweiteres kann abweichen und erfordert daher eine Transferleistung.

Zu den Klassen werden Objekte (Instanzen) referenziert/erstellt, die dann für die aktuelle Programmausführung via Methoden und Daten (Attributwerte) verwendet werden. Via Vorwärtsnavigation auf den Objektnamen, findet man die zugehörige Klasse. Anhand des Klassenprefix identifiziert man, ob es eine lokale (lcl) oder globale (cl) Klasse ist. Zweitere ist nicht nur dort gültig, wo sie deklariert wurde. Diese wird in SE37 definiert. Bei der Vererbung können Oberklassen in Unterklassen genauer spezifiziert bzw. sogar Methoden/Attribute überlagert werden. Eine Oberklasse könnte z.B. ein Auto sein (Methode zum Lenken, Attribut Farbe & Attribut Setzanzahl), während ein Roadstar eine Unterklasse des Autos ist und dort Details weiter konkretisiert werden (Sitzanzahl immer 2).

Funktionsbausteine werden mit Input-Parametern aufgerufen, es läuft eine gewisse Programmlogik ab und diese liefern Output-Parameter zurück. Das aufrufende Programm/der Entwickler, muss also ggf. nicht die Implementierungsdetails kennen.

Konstanten: Diese Datenobjekte haben im Gegensatz zu Variablen einen festen Wert.

Datenelement: Elementarer Datentyp im ABAP-Dictionary, welcher die technischen Eigenschaften (Domäne: Datentyp, Länge und Wertebereich) und die semantische Bedeutung umfasst.

Interne Tabellen werden ebenso in lokale (li) und globale Tabellen (it) untergliedert. Diese dienen der Speicherung von Daten zur Programmlaufzeit, daher kann man dort auch mal (im nicht-produktiven System!) Daten löschen, hinzufügen und ändern. Während dies in SAP-Standardtabellen deutlich mehr Sorgfalt und Expertise voraussetzt. Dies ist ein Datenobjekt, dass aus einer Folge von Zeilen gleichen Datentyps besteht.

Struktur: Neben den internen Tabellen, gibt es auch noch die Struktur als komplexen Datentypen (nicht elementar). Diese lassen auch detaillierte Zugriffe zu, können jedoch auch als Ganzes behandelt werden. Während interne Tabellen aus einer Folge von Zeilen gleichen Datentyps bestehen, können hier unterschiedliche Datenobjekte/-typen zusammengesetzt und gespeichert werden (String-Datenelemente, mehrere Tabellen, Referenzvariablen usw.).

View: Virtuelle Tabelle im ABAP Dictionary (SE80) mit anwendungsorientierte Sicht auf mehrere Datenbanktabellen.

Schnittstelle: Öffentliche Schnittstelle einer Klasse.

  • SE91 Nachrichtenanzeige (Nachrichtenklasse und Nachrichtennummer)