Break-Points

Aus SAP-Wiki
Zur Navigation springenZur Suche springen

Siehe Kategorie: Fehlerverarbeitung.

Siehe Debugger.

Siehe Kategorie:Fehlerverarbeitung.

Siehe Kategorie:Debugging.

Es gibt verschiedene Möglichkeiten bei der Programmausführung in den Debugger zu wechseln.

Programmdebugging mit "/h"

  • "/h" im Kommandofenster eingeben. Der Debugger wird sofort am Anfang des Programms ausgeführt. Empfehlenswert, wenn das Programm vom Programmstart an debuggt werden soll.
/h

Systemdebugging mit "/hs"

break <benutzername>

  • break <benutzername> im Coding schreiben.
  • Das Programm stoppt nur beim SAP-Benutzer <benutzername>. Empfehlenswert, wenn das Programm an einer bestimmten Stelle in den Debugger springen soll und man selber das Programm debuggen will. Hier ist es auch meist unproblematisch, wenn man vergisst den Breakpoint bei einem Transport zu löschen, da bei anderen SAP-Usern der Sprung in den Debugger nicht erfolgt.
break eberstein.
  • Diesen Befehl im Coding wird man so häufig verwenden, dass es sich lohnt diesen Befehl als SAP-Codingvorlagen im Editor abzuspeichern und z. B. mit einem Shortcut "break+" oder "bp+" das Coding schneller einzufügen.

break-point

  • break-point. Hier springt das Programm bei jedem SAP-Benutzer mit Debuggerberechtigung in den Debugger. Es ist dringend zu empfehlen diesen Befehl in aller Regel nicht zu nutzen !!! Es ist störend und wirkt unprofessionell, wenn im Entwicklungs-, Qualitäts- oder Produktivsystem andere Benutzer oder gar der Fachwender mit Debuggerberechtigung ungewollt in den Debugger springen. Hier ist z. B. "break <benutzername>" vorzuziehen.
  • Vor jedem Transport ins Qualitätssystem und besonders in Produktivsystem sollte das Code um diese Breakpoints „break-point“ bereinigt werden. Noch besser ist es sie gar nicht zu verwenden. Dann kann es auch nicht vergessen werden sie zu löschen.
break-point.

break-point id <checkpoint> / Transaktion SAAB

  • Transaktion SAAB. Der Breakpoint lässt sich flexibel in der Transaktion SAAB aktivieren oder deaktivieren, sofern der Entwickler die Berechtigung für die Transaktion SAAB hat.
break-point id testcheckpoint.

Session-Breakpoint im Editor

  • Setzen eines Session-Breakpoint im Editor. Hier muss der Breakpoint im gleichen Mandanten gesetzt werden. Dies ist ein gewisser Nachteil, da häufig die Entwicklung in einem Entwicklungsmandanten vorgenommen wird und das Ausführen des Programms mit Daten in einem anderen Mandanten.
  • Klick auf die entsprechende Zeile im Editor (z. B. Transaktion SE38 oder SE80) in der beigen Leiste. Auch während der Programmausführung im Debugger kann hier ein Modus-Breakpoint gesetzt werden. Wird im Debugger der Modus-Breakpoint gelöscht durch Doppelklick auf den Breakpoint, wirkt sich das zunächst nur für den aktuellen Programmlauf aus. Soll der Modus-Breakpoint auch bei erneuter Ausführung des Programms gelöscht bleiben, muss im Debugger der/die Modus-Breakpoints durch DebuggerNew11.jpg gespeichert werden.

DebuggerNew9.jpg

Das Programm stoppt an der entsprechenden Stelle.

DebuggerNew10.jpg

Externen Breakpoint im Editor

  • Setzen eines Externen Breakpoints im Editor mit dem Button Breakpoint1.JPG.
  • Über den Session-Breakpoint hinaus kann ein Externer Breakpoint gesetzt werden, um z. B. von einem externen RFC-Funktionsbaustein auch in den Debugger zu springen

Debugger-Breakpoint

  • Setzen eines Breakpoints im Debugger. Hier wird der Breakpoint allerdings nur für den aktuellen Debugginglauf gesetzt, es sei denn, man speichert den Breakpoint mit strg+s oder dem Diskettensymbol DebuggerNew11.jpg. Dann wandelt sich der Debugger-Breakpoint in einen Session-Breakpoint um und bleibt während der ganzen SAP-Anmeldung im System erhalten, sofern er nicht wieder gelöscht wird.
  • Wird der Schreibcursor im Debugger im Programmablauf nach der aktuellen Programmzeile gesetzt, so stoppt das Programm auch an dieser Stelle. Man spart sich so das Löschen des Breakpoints, wenn eine Codingstelle nur einmal angesprungen werden soll.

Breakpoint setzen mit "Breakpoint bei .."

  • Man ruft den Debugger zunächst ganz normal über einen dynamischen Breakpoint, "/h" oder den Schlüsselbefehl eines Breakpoints.

BreakpointBei1.JPG


Hier kann man weitere Breakpoints setzen über das Stopp-Zeichen im Menü des Debuggers.

BreakpointBei2.JPG


Im Coding wird nun nach jeder Fundstelle des Schlüsselbefehls "message" gesucht und ein Breakpoint gesetzt.

BreakpointBei3.JPG


Die 2 Codingstellen mit dem Schlüsselbefehl "message" sind nun mit einem Breakpoint versehen.

BreakpointBei4.JPG

Nützlich ist es u. a. beim Aufruf einer Form-Routine oder beim Methodenaufruf zu stoppen.

Web-Links

Es lohnt sich, einmal die verschieden Reiter zu testen, was man hier setzen kann und wo das Programm dann zur Laufzeit stoppt. Diese Möglichkeit das Programm bei den verschiedenen Messages, Funktionen, Methoden etc. zu stoppen kann viel Zeit sparen, wenn einen diese Codingstellen interessieren und man sonst schrittweise zu diesen interessanten Stellen debuggen würde. Man spart Zeit und Konzentration, die beim Debuggen meist ih hohem Maße erforderlich ist.

Literatur