Neuer ABAP Debugger: Vorteile der Zwei-Prozess-Architektur

Der Klassische Debugger läuft im gleichen internem Modus (Rollbereich) desselben Hauptmodus (externer Modus) wie die zu analysierende Anwendung, wogegen der Neue ABAP Debugger einen zusätzlichen Hauptmodus belegt und in einem eigenem Fenster des SAP GUI angezeigt wird (Zwei-Prozess-Architektur). Die zu testende Anwendung (der Debuggee) wird dabei vom ABAP Debugger gesteuert.

Die Nutzung eines gemeinsamen Modus hat gewisse Vorteile bei der Bedienung wie auch beim Ressourcenverbrauch, jedoch überwiegen bei Weitem die Nachteile, die durch diese enge Kopplung von Applikation und Debugger entstehen:

• Es gibt zwangsläufig Wechselwirkungen zwischen Anwendung und Debugger, wodurch nur sehr eingeschränkte Möglichkeiten bei der Gestaltung der Benutzeroberfläche im Klassischen Debugger bestehen. Die Benutzeroberfläche des Neuen Debugger ist dagegen frei konfigurierbar, so dass der Benutzer sich eine Oberfläche nach seinen Wünschen gestalten kann.

• Mit dem Klassischen Debugger können keine Programmeinheiten analysiert werden, die direkt vom ABAP Kernel gerufen werden. Ein solcher Aufruf erfolgt zum Beispiel bei jedem Konvertierungsexit .

• Der Klassische Debugger analysiert einen Rollbereich, dessen Beendigung auch den Klassischen Debugger selbst beendet. Daher verschwinden alle bestehenden Einstellungen wie die Anzeige von Variablen im Klassischen Debugger, sobald die Grenzen eines Rollbereichs zum Beispiel durch Aufruf der Anweisungen SUBMIT oder CALL TRANSACTION überschritten werden. Dagegen analysiert der Neue Debugger einen externen Modus. So lange dieser externe Modus aktiv ist, bleibt auch der Debugger geöffnet und kontrolliert diesen Modus.

Daher wechselt der Benutzer im Verlauf einer Debugger-Sitzung zum Beispiel vom Debugger- in das Anwendungsfenster, wenn die Anwendung eine Benutzeraktion erfordert, wobei das Debugger-Fenster in diesem Zustand nicht eingabebereit ist. Ist die Eingabe auf Seiten der Anwendung abgeschlossen und das Programm läuft weiter, dann wird das Debugger-Fenster wieder eingabebereit, sobald die nächste Unterbrechung erreicht wird. Wechselt der Eingabe-Focus vom Debugger auf die Anwendung und umgekehrt, so wird das eingabebereite Fenster vom Graphical User Interface (GUI) automatisch in den Vordergrund gestellt.

In der folgenden Abbildung wird der Debugger durch Eingabe von /h gestartet und ist danach so lange aktiv, bis die Kontrolle in Folge einer Benutzeraktion wieder an die Anwendung übergeht. Der Debugger bekommt erneut die Kontrolle, wenn ein Breakpoint erreicht wird oder wenn die Anwendung den Debugger explizit durch /h aktiviert. Der Modus der Anwendung unterliegt dann so lange der Kontrolle des Debugger-Modus, bis der Anwendungs-Modus geschlossen oder der Debugger-Modus explizit durch /hx beendet wird.

Dieses Verhalten ist insbesondere dann von Vorteil, wenn rollbereichsübergreifende Programme im Debug-Modus analysiert werden. Obwohl ein neuer Rollbereich eröffnet wird, bleibt dieselbe Instanz des Debuggers geöffnet und alle Einstellungen, wie Anordnung der Werkzeuge oder die Liste der angezeigten Variablen, bleiben unverändert.

Nachteilig könnte dieses Verhalten dann sein, wenn man den Debugger nicht explizit schließen will, sondern möchte, dass das Schließen des Debuggers am Ende eines Rollbereiches automatisch passiert, etwa nachdem F8 (Weiter) als Debugger-Kommando abgesetzt wurde (so verhält sich der Klassische Debugger). Im Neuen ABAP Debugger kann man dieses Verhalten über das Hauptmenü einstellen:  Einstellungen   Debugger Einstellungen    Weiter nach F8 und Rollbereichsende .

Siehe auch: Neuer und Klassicher ABAP Debugger: Hautptunterschiede