Checkpointgruppen für Breakpoints und Werteprotokollierung
Breakpoints können ein äußerst hilfreiches Mittel für die Fehlerfindung oder den Verständnisgewinn innerhalb von Funktionsbausteinen und Methoden sein. In diesem Beitrag möchte ich euch eine flexible Art der Breakpoints in Form der Checkpointgruppen näherbringen und euch zeigen, warum und wann ihr sie am besten nutzen solltet.
Gründe für die Nutzung von Checkpointgruppen
Die Verwendung von Breakpoints ist nicht nur im Formularumfeld von sehr wichtiger Bedeutung. Durch sie können Fehler oft sehr schnell identifiziert oder Funktionsweisen für unterschiedliche Werte überprüft werden. Zudem sind Breakpoints sehr schnell eingestellt. Die bekannteste Art ist durch einen Klick auf den gelben Rand links des ABAP Codings oder die Auswahl im oberen Menüband. Haltepunkte können aber auch direkt in einer Codezeile zusammen mit dem Nutzernamen angegeben werden:
Arten von Breakpoints
Und auch wenn die Funktionalität der Haltepunkte bereits sehr ausgereift ist, gibt es doch einige Szenarien, in denen sie sich nur schwer setzen lassen, übersprungen werden oder einfach der Einstieg erschwert ist. Grade im Formularumfeld wird oft mit Standarddruckprogrammen und -schnittstellen gearbeitet. Hier ist es oft schwer ein Fehlverhalten zu analysieren und identifizieren, wenn sich keine Zwischenschritte anzeigen lassen. Ein weiterer Nachteil bei Inline-Breakpoints ist, dass sie nur für den angegebenen Nutzer funktionieren und andere Nutzer von ihnen keinen Gebrauch machen können. Auch lassen sich diese Haltepunkte nicht deaktivieren und können die Arbeit manchmal etwas verlangsamen.
Für genau diese Fälle empfiehlt sich die Arbeit mit sogenannten Checkgruppen. Breakpoints die über Checkgruppen angelegt und eingebunden werden sind zunächst keinem Nutzer zugeordnet, können in den entsprechenden Systemen aktiviert und deaktiviert werden und besitzen noch weitere Vorteile, auf die ich weiter unten noch zu sprechen komme.
Wie verwende ich Breakpoints aus Checkpointgruppen
Zuständig für alle Einstellung bezüglich der Checkpointgruppen ist die Transaktion SAAB. Hier können sie ihre Gruppen anzeigen, anlegen, bearbeiten, löschen und aktivieren:
Transaktion SAAB
Nach der Auswahl eines geeigneten Namens können Sie hier direkt eine Gruppe anlegen und gelangen zum Einstellungsbildschirm, welcher den Funktionsumfang von Checkpointgruppen direkt deutlich macht. Die Hauptfunktionalitäten neben Breakpoints sind noch Logpoints und Assertions, welche ich etwas später noch erklären werde.
Wie nutze ich jetzt diese Breakpoints aus meiner Checkpointgruppe?
Ganz einfach: Ähnlich wie bei Inline-Breakpoints wird eine Codezeile an der entsprechenden Stelle eingebunden:
Breakpoint über Checkpointgruppen
Bevor ihr jetzt aber glaubt, dass dieser Haltepunkt für alle Nutzer gültig ist, kann ich euch beruhigen: In der Transaktion SAAB kann festgelegt werden, für welche Nutzer und auch in welchem Zeitraum der Breakpoint aktiv sein soll. Über die Schaltfläche 
könnte Ihr genau diese Einschränkungen vorgeben und speichern. Anschließend sollte beim Ausführen der Anwendungen, in dem der Checkpoint eingebunden wurde, der Debugger wie gewohnt starten.
Weitere Funktionen und Vorteile
Checkpointgruppen unterteilen sich in drei Arten. Die Funktionalität von Breakpoints haben wir bereits im oberen Abschnitt kennengelernt. Der Vorteil dieser Art von Haltepunkt ist die Flexibilität: Der so eingestellte Breakpoint kann systemübergreifend genutzt werden, also auch auf beispielsweise Produktivsystemen (solange dort Debuggingrechte vorhanden sind). Auch sind sie einfach für andere Nutzer zu aktivieren und dies auch selbstständig, sodass die Benutzung sehr unabhängig passieren kann.
Log-Points
Als zweite Funktion bieten die Checkpointgruppen Log-Points. Mit ihnen lassen sich Informationen über Variablen des ausführenden Programms in einem Protokoll speichern. Automatisch wird hier zusätzlich festgehalten in welchem Entwicklungsobjekt die Variablen ausgeführt wurden. Diese Funktion ist vor Allem dann hilfreich, wenn ein Ablauf im Hintergrund ausgeführt wird und nicht gedebuggt werden kann. Die Werte werden hier sogar beim einem eventuellen Rollback persistiert, da sie bereits weggeschrieben werden, bevor der Rollback durchgeführt wird. Als kleines Beispiel hier eine vereinfachte Verwendungsmöglichkeit:
Log-Point im Coding
Als Ergebnis wird im Reiter Protokoll eine sehr detaillierte Übersicht dargestellt:
Checkpointgruppenprotokoll
Hier wird auch ein erster kleiner Nachteil der Logfunktion sichtbar: Nicht alle Variablen werden korrekt dargestellt. Bei Strukturen werden, wie hier zu sehen, keine Feldbeschreibungen angezeigt und bei Tabellen nur bis zu drei Einträge gespeichert. Nichtsdestotrotz halte ich diese Funktion für sehr hilfreich und sie ist oft schneller eingebaut als das SAP-Standard Anwendungslogging.
Assertions
Als dritte Funktion bieten die Checkpointgruppen noch Assertions. Diese bilden eine Verbindung aus Logging und Breakpoints, in dem sie zusätzlich eine Kondition besitzen und anhand dieses Vergleichs ein Protokoll oder Haltepunkt darstellen. Diese Funktion kann erneut recht simpel veranschaulicht werden. Dieser Assert wird nur durchgeführt, wenn lv_date nicht dem aktuellen Datum entspricht:
Assertion in Checkpointgruppen
In der Transaktion SAAB kann für diesen Punkt jetzt entschieden werden, was bei Nichteinhaltung der condition passieren soll:
Assertion-Optionen
Bei inaktiv passiert für diesen Assertionpoint nichts. Dies Auswahl anhalten verhält sich wie ein Breakpoint. Beim Anwählen kann sogar gewählt werden, was getan werden soll, wenn der Assertionpoint im Hintergrund angelaufen wird. Über protokollieren werden die angegebenen Felder wie oben beschrieben persistiert und mit abbrechen kann sogar der ganze Ablauf abgebrochen werden (empfiehlt sich allerdings in den wenigsten Fällen, diese Option zu verwenden).
Häufige Einsatzgebiete und Stolperfallen
Checkpointgruppen lassen sich prinzipiell überall einfügen, wo auch Code geschrieben werden kann: Reports, Methoden, Schnittstellen, User-Exits, BAdIs, Enhancement Points, uvm. Dies sind grundsätzlich auch Stellen, an denen normale (Session-)Breakpoints und Anwedungslogging sehr einfach genutzt werden können, warum also diese umständliche Lösung?
Speziell im Formularumfeld ist die Code-Initialisierung bei Smartforms- und Adobeformularen die einzige Stelle, an der Entwicklungen durchgeführt werden können. Dort lassen sich beispielsweise über die bekannten Methoden keine Haltepunkte setzen. Zwar funktionieren Inline-Breakpoints, diese sind dann allerdings nutzerspezifisch und lassen sich nicht deaktivieren. An diesen Stellen kommen alle oben genannten Vorteile ins Spiel: Der Breakpoint lässt für beliebe Nutzer de-/aktivieren und das auch für bestimmte Zeiträume. Super praktisch und sehr schnell eingerichtet.
Vorsicht ist bei der Nutzung trotzdem geboten. Grade beim Transport der Checkpointgruppen treten gerne kleinere Fehler (Returncode 8) auf. Es empfiehlt sich, die Checkpointgruppen separat im Vorfeld zu transportieren, bevor die Reports/Schnittstellen transportiert werden, damit die Gruppen im Zielsystem bereits bekannt sind. Selbiges gilt für das Löschen der Gruppen, dabei muss darauf geachtet werden, dass alle Nutzungen aus den entsprechenden Anwendungen entfernt werden, da es sonst zu Laufzeitfehlern kommen kann.
Ich finde Checkpointgruppen sind in einigen Situationen eine hilfreiche und flexible Alternative zu Standardbreakpoints im SAP, grade im Formularumfeld. Haben Sie bereits Erfahrungen mit Checkpointgruppen gemacht oder noch Fragen zu meinem Artikel? Lassen Sie es mich über die Kommentare wissen und wir werden uns schnellstmöglich mit Ihnen in Verbindung setzen.
