6.4    Schicht für Schicht: Layer-aware Debugging 

Stellen Sie sich vor, Sie nutzen den Debugger, um ein Programm eines anderen Entwicklers zu analysieren. Das Programm, das Sie debuggen, enthält aber nicht nur dessen eigene Programmablauflogik, sondern darüber hinaus zahlreiche Aufrufe fremden Codes, der in anderen Programmen liegt – beispielsweise in Bibliotheken des SAP-Standards zur Bildschirmanzeige von Tabellen.

Während Sie versuchen, im Debugger Schritt für Schritt die betriebswirtschaftliche Logik des Programms Ihres Entwicklerkollegen nachzuvollziehen, kann es geschehen, dass Sie tiefer und tiefer in einen Strudel von immer verwirrenderen Systemklassen hinabgezogen werden.

Der Ablauf kann auch umgekehrt sein: Immer größere Anteile der ABAP-Entwicklung erfolgen im Rahmen sogenannter Frameworks, wie beispielsweise Web Dynpro ABAP. Dabei wird der Code, der die eigentliche betriebswirtschaftliche Anwendungslogik enthält, nicht direkt vom Anwender gestartet und bildet damit die höchste Ebene der Aufrufkette, sondern es wird zunächst das Framework (z. B. das Web-Dynpro-Rahmenwerk) aufgerufen. Dieses durchläuft sehr viel technischen Framework-Code, bis es endlich die betriebswirtschaftliche Funktionalität aufruft, um die es Ihnen geht.

Würden Sie manuell durch all den Framework-Code navigieren, würde die Debugging-Sitzung viel zu viel Zeit in Anspruch nehmen, und aufgrund der Unübersichtlichkeit des Codes wäre bei einem solchen Vorhaben die Gefahr groß, dass Sie ausgerechnet den wesentlichen – aber im Vergleich zum Ganzen kleinen – Programmteil versehentlich überspringen.

Das Problem ist in jeder komplexen Anwendungssoftware das gleiche: Zahlreiche Komponenten, die unterschiedliche Teilaufgaben wie Datenbankzugriffe, Berechnungen, Dialoganzeigen und Schnittstellen lösen, spielen zusammen und bilden gemeinsam eine Gesamtlösung. Beim Ablauf des Programms, dem Sie im Debugger Schritt für Schritt folgen, werden all diese Komponenten durchlaufen, obwohl Sie sich nicht für jede von ihnen interessieren – möglicherweise haben Sie eine Vermutung, in welchem Bereich sich der Fehler verbirgt, den Sie gerade suchen, und möchten die Komponenten, die damit nichts zu tun haben, am liebsten ausblenden bzw. ihren Code im Debugger überspringen.

Hierfür bietet der ABAP Debugger seit dem Release 7.0 EHP 2 die Möglichkeit des Layer-aware Debuggings, sprich das gezielte Debugging bestimmter Softwareschichten. Dabei können Sie die unerwünschte Software, die Sie nicht im Debugger untersuchen möchten, einfach ausblenden. Sie wird dann zwar prozessiert, aber »dunkel« – der Debugger zeigt Ihnen keinen der Schritte in den ausgeblendeten Softwareschichten an und meldet sich erst wieder bei Ihnen, wenn ein Quelltext-Bereich erreicht ist, den Sie auch tatsächlich debuggen möchten.

In Listing 6.1 sehen Sie eine geringfügig modifizierte Version des Programms Z_TEILNEHMERLISTE01. Auch wenn es bis zu diesem Listing am Ende des Kapitels noch ein wenig hin ist: Blättern Sie ruhig einmal zu Abschnitt 6.5, »Codebeispiel zum Layer-aware Debugging«, vor und schauen Sie sich das Programm kurz an. Fallen Ihnen schon die Unterschiede zur Vorgängerversion auf? Wir werden sie gleich Schritt für Schritt gemeinsam durchgehen.

Das Programm, das ursprünglich eine einfache Liste aufruft, wurde um den Aufruf des SAP-Standardbausteins REUSE_ALV_GRID_DISPLAY ergänzt, der eine im Hauptspeicher des aufrufenden Programms existierende interne Tabelle komfortabel darstellt. Dabei stehen Funktionen zum Filtern, Exportieren, Ändern des Layouts und weitere Komfortfunktionen zur Verfügung – stellen Sie sich vor, diese Ergänzung hätte ein hilfreicher Kollege vorgenommen, aber nicht ausreichend dokumentiert.

Wenn Sie das Programm Z_TEILNEHMERLISTE01_DEBUG ausführen, erscheint statt der bekannten Listausgabe die Tabellendarstellung der Teilnehmerliste, die Sie in Abbildung 6.18 sehen. Diese Tabellendarstellung wird SAP List Viewer, ALV Grid oder auch kurz ALV genannt und begegnet Ihnen in zahlreichen SAP-Dialogen.

Abbildung 6.18    Ausgabe des Bausteins REUSE_ALV_GRID_DISPLAY

Experimentieren Sie ein wenig mit den verschiedenen Funktionen der Listausgabe, und probieren Sie die Icons oberhalb der Tabelle aus. Hier finden Sie u. a. Funktionen zum Sortieren (, ), Filtern (), Exportieren (, , , , ) und Verwalten von Layouts (). Bei einem Doppelklick auf eine Tabellenzeile erscheint ein Nachrichtendialog (siehe Abbildung 6.19).

Abbildung 6.19    Nachricht bei Doppelklick auf eine Tabellenzeile

Wenn Sie die Nachricht mit einem Klick auf Weiter () bestätigen, gelangen Sie zurück zur Tabellendarstellung. Ein Klick auf Zurück () oder die Taste (F3) bringt Sie zur bekannten Listausgabe des Programms, wie in Abbildung 6.20 zu sehen ist. Verlassen Sie anschließend auch die Listausgabe mit Zurück () oder (F3).

Abbildung 6.20    Listausgabe des Programms

Was ist geschehen? Falls Sie den Programmcode von Listing 6.1 aufmerksam gelesen haben, ist Ihnen vielleicht aufgefallen, dass es das Unterprogramm CALLBACK_USER_COMMAND gibt, das für die Ausgabe der Nachricht verantwortlich sein könnte. Dieses Unterprogramm wird allerdings in unserem Programm nirgendwo aufgerufen. Trotzdem wird es offensichtlich durchlaufen, denn die Nachricht erscheint bei einem Doppelklick auf eine Tabellenzeile im Bildschirm. Wie ist das möglich?

Die Antwort: Hier wird eine sogenannte Rückruffunktion verwendet, auch Callback genannt. Dabei übergibt ein rufendes Programm dem gerufenen Programm (hier dem Baustein zur Tabellenanzeige) eine Funktion (hier das Unterprogramm CALLBACK_USER_COMMAND), die dieses zum passenden Zeitpunkt aufruft. Das gerufene Programm ruft demnach zurück und führt eine Funktion seines Aufruferprogramms aus.

Solche Konstrukte trifft man häufig dort an, wo Frameworks und Servicebausteine als allgemeine Lösungen für wiederkehrende Aufgaben geschaffen werden. Denn so sehr die wiederkehrende Aufgabe auch standardisiert werden kann – es gibt dabei immer wieder die Notwendigkeit, anwendungsspezifischen Code in den Ablauf einzubetten. So auch hier: Unser Programm ruft den Standardbaustein, und zu einem ganz bestimmten Zeitpunkt ruft der Standardbaustein eine Funktion unseres Programms, bevor er die Kontrolle über den Programmablauf zurückerhält und seine Arbeit fortführt.

Starten Sie das Programm nun erneut – aber diesmal im neuen Debugger. Klicken Sie im Debugger auf Debugger-Layer konfigurieren, wie in Abbildung 6.21 gezeigt. Es erscheint ein Pop-up-Dialog, in dem Sie das schichtenorientierte Debugging konfigurieren können (siehe Abbildung 6.22). Aktivieren Sie hier das Ankreuzfeld Layer-aware Debugging aktiv. Daraufhin wird der untere Bereich des Fensters eingabebereit.

Standardmäßig ist die Option Direkte Definition der sichtbaren Objektmenge (Layer) ausgewählt. Dies ist für unsere Zwecke ausreichend – wenn Sie den Debugger später regelmäßig verwenden, können Sie hier auch Profile abspeichern, auf die Sie bei Bedarf immer wieder zurückkommen können.

Abbildung 6.21    Programm Z_TEILNEHMERLISTE01_DEBUG im Debugger

Abbildung 6.22    Konfigurationsdialog für Layer-aware Debugging

Unser Ziel ist es, den Programmablauf zu debuggen, aber dabei nur den Code im Programm Z_TEILNEHMERLISTE01_DEBUG selbst anzeigen zu lassen. Der Code des SAP-Standardbausteins, der bei der Programmausführung ebenfalls durchlaufen wird, soll ausgeblendet werden.

Geben Sie dazu im Feld Programme den Programmnamen Z_TEILNEHMERLISTE01_DEBUG ein, und aktivieren Sie das Ankreuzfeld Halte beim Eintritt. (Achten Sie darauf, dass das Ankreuzfeld Halte beim Austritt deaktiviert ist.) Bestätigen Sie den Dialog anschließend mit Weiter (, siehe Abbildung 6.22).

Zurück im Debugger erkennen Sie an dem neuen Button Nächste Objektmenge, dass das Layer-aware Debugging aktiv ist (siehe Abbildung 6.23). Sie können nun zunächst ganz normal einige Programmschritte debuggen, um sich davon zu überzeugen, dass die regulären Funktionen des Debuggers weiterhin zur Verfügung stehen.

Abbildung 6.23    Debugger mit aktivem Layer-aware Debugging

Sie erinnern sich, dass Sie im Konfigurationsdialog angegeben haben, dass Sie das Programm Z_TEILNEHMERLISTE01_DEBUG jeweils bei Eintritt debuggen möchten. Ein Klick auf den neu erschienenen Button Nächste Objektmenge bewirkt, dass das System die Programmausführung fortsetzt – bis zum nächsten Punkt im Programmablauf, auf den diese Definition zutrifft, d. h. bis zum nächsten Wiedereintritt in das Programm Z_TEILNEHMERLISTE01_DEBUG.

Klicken Sie nun auf den Button Nächste Objektmenge. Interessanterweise verlassen Sie den Debugger und sehen die Tabellendarstellung der Teilnehmerliste. Warum? Auch beim Debuggen bleiben die interaktiven Funktionen eines Programms erhalten, und Dialogausgaben werden selbstverständlich nicht unterdrückt. Die Verarbeitung wird nun regulär fortgesetzt, bis der nächste zu debuggende Punkt im Ablauf erreicht ist, nämlich der nächste Wiedereintritt in unser Programm.

Sie können nach Herzenslust sortieren, filtern und exportieren, ohne dass dabei der Debugger erscheint, weil all der Programmcode, der bei diesen Funktionen durchlaufen wird, außerhalb der von uns gewünschten Objektmenge liegt.

Erst wenn Sie auf eine Tabellenzeile doppelklicken, erinnert sich der SAP-Standardbaustein zur Tabellenanzeige an unsere Rückruffunktion und verzweigt in das Unterprogramm CALLBACK_USER_COMMAND des Programms Z_TEILNEHMERLISTE01_DEBUG. Nach unserer Definition sollte damit auch unsere Debugging-Sitzung fortgesetzt werden, denn wir sind an allem interessiert, was in diesem Programm (und nur in diesem) geschieht.

Und tatsächlich führt der Doppelklick auf die Tabelle geradewegs zurück in den ABAP Debugger. Wie Sie in Abbildung 6.24 sehen können, gibt das System dabei die Meldung aus, dass die gewählte Objektmenge betreten wurde – das System hat registriert, dass die Ausführung wieder das Programm Z_TEILNEHMERLISTE01_DEBUG erreicht hat, das Sie debuggen möchten.

Abbildung 6.24    Eintritt in das Callback-Unterprogramm

Die Ausführung ist beim Unterprogramm CALLBACK_USER_COMMAND angelangt, das dem SAP-Baustein REUSE_ALV_GRID_DISPLAY zuvor als Rückruffunktion übergeben wurde.

Sie können nun weiter Schritt für Schritt den Programmablauf im Debugger verfolgen oder mit einem Klick auf Nächste Objektmenge das System anweisen, das Debugging erst beim nächsten Wiedereintritt in das Programm fortzusetzen.