Transaktion SAAB (aktivierbare Checkpoints)
Siehe Fehlerbehandlung.
Siehe Debugger.
Die Transaktion SAAB bietet ein paar einfache, aber sehr nützliche Möglichkeiten, um das Verhalten von Programmen während der Laufzeit zu analysieren und das Verhalten des Debuggers zu steuern.
In der Transaktion SAAB lässt sich einstellen, ob ein Breakpoint angesprungen wird oder nicht, bzw. ob der Breakpoint aktiv ist oder nicht. Es können auch (begrenzt) Variablen protokolliert werden oder Annahmen/Assertions geprüft werden.
Der Vorteil der SAAB-Checkpoints liegt insbesondere daran, dass man die Checkpoints ins Programm einbauen und ins Produktivsystem transportieren kann, ohne das es dadurch z. B. zur Gefahr kommt, dass bei bestimmten Usern (mit Debuggingberechtigung) ungewollt das Programm unterbrochen wird und der Debugger mit dem Breakpoint aufgerufen wird. Es kann fein eingestellt werden für welchen User der Breakpoint angesprungen wird, es zeitlich limitieren und das Verhalten des Checkpoints in der Transaktion SAAB dann auch im Produktivsystem einstellen/ändern kann.
Transaktion SAAB
Geben Sie einen Namen für die Checkpoint-Gruppe ein und drücken auf den Button 
.
Anschließend eine Beschreibung pflegen und der Entwicklung ein Paket und einen Transportauftrag zuweisen.
"Checkpoint-Gruppe" klingt etwas sperrig, aber ein bedingter Breakpoint trifft es auch nicht korrekt, da mit den Checkpoint-Gruppen auch Variablen protokolliert werden können. In der Praxis spricht man doch meist von einem "bedingten Breakpoint" oder einem "SAAB-Breakpoint", da es in aller Regel darum geht nur unter bestimmten Bedingungen und temporär einen Breakpoint auszulösen im SAP-System.
Checkpoint-Gruppe ändern
Nun können u. a. die Breakpoints aktiviert oder deaktiviert werden, die in Bezug auf diese Checkpoint-Gruppe im Coding angelegt wurden
Standardmäßig gilt der gesetzte Break-Point/Log-Point/Assert für den aktuellen Benutzer und den aktuellen Tag. Es lassen sich über die Schaltfläche 
aber auch zusätzliche Benutzer definieren, für die der Checkpoint gezogen wird oder es mit "Globale Aktivierung" für alle Benutzer mit Debuggingberechtigung aktivieren. Der letzte Fall bietet sich an, wenn man ein Verhalten eines Programms im Produktivsystem analysieren will, wo man vorher nicht weiß, welcher User/System-User dieses Programm ausführen wird.
Auch die Gültigkeit der Aktivierung kann länger als den aktuellen Tag gewählt werden. Hier ist die Defaulteinstellung auf den aktuellen Tag aber meist völlig ausreichend.
Checkpoint-Gruppe im Programmcoding
Wenn die Checkpoint-Gruppe ZTEST vorher im Dialogbildschirm aktiviert wurde, wird der Debugger an der Stelle von "break-point id ztest" anhalten.
START-OF-SELECTION. break-point id ztest.
Existiert die Checkpoint-Gruppe ZTEST noch nicht, kann sie auch per Doppelklick/Vorwärtsnavigation angelegt werden.
Arten einer Checkpoint-Gruppe
Die Transaktion teilt sich in drei Bereiche auf
- Breakpoints
- Logpoints
- Assertions
Breakpoints (Dynamische Breakpoints)
Setzt man in das Programm diesen Befehl
break-point id ZTEST.
Dann kann man durch Setzen des Befehls Breakpoints
- "anhalten" den Break-Point aktiv schalten (für Default 1 Tag)
- "inaktiv" wieder abschalten.
So kann man während der Programmentwicklung dynamisch durch diesen Setzen dieses Schalters das Programm anhalten und in den Debugger springen lassen oder auch durchlaufen lassen.
Logpoints (Protokollierung Variablen)
Mit aktivierten Logpoints lassen sich Informationen über Variablen in einem Protokoll speichern. Automatisch wird hier auch festgehalten in welchem Entwicklungsobjekt die Variablen ausgeführt wurden.
Die Protokollieren bietet sich z. B. an, wenn ein Programm im Hintergrund läuft und man es nicht direkt debuggen kann. So kann man die relevanten Variablen auswählen und protokollieren lassen für deren Analyse.
Die Logpoints werden auch fortgeschrieben, wenn in dem zu protokollierenden Prozess ein Rollback vorgenommen wird, da die Fortschreibung der Logpoints in einem separaten Workprozess erfolgt.
Protokollierung Variablen
Im Programm werden hier nun zwei Variablen GV_2-VBELN Und GV_2-POSNR protokolliert.
gv_2-vbeln = '0000000001'.
gv_2-posnr = 10.
LOG-POINT id ZTEST
fields gv_2-vbeln
gv_2-posnr.
In der SAAB klickt man nun auf den Reiter "Protokoll" und man sieht alle Protokolle, die für diese Checkpoint-Gruppe erfasst wurden. Hier nur eine. Programmnamen ZREBTEST, Ereignis START-OF-SELECTION und die Programmzeile werden ausgegeben
Nach Doppelklick auf diese Zeile sieht man auch die Variableninhalte. Hier bei einem anderen Beispiel.
lv_repid = sy-repid. LOG-POINT id Z_SD_01 fields lv_repid.
Protokollierung Strukturen und Tabellen
Es ist eingeschränkt möglich Strukturen und Tabellen zu protokollieren.
Die Strukturen werden nicht mit ihren eigentlichen Feldnamen, sondern mit COMP1, COMP2, etc. protokolliert.
Die Tabellen werden ebenso mit COMP1, COMP2, etc. protokolliert. Ferner werden lediglich maximal 3 Datensätze der Tabelle protokolliert.
Wird über eine Tabelle geloopt
Loop at itab into wa.
LOG-POINT id ZTEST
fields wa-feld1
wa-feld2.
endloop.
Dann sieht man nur den letzten Eintrag in den Feldern WA-FELD1 und WA-FELD2. Angenommen es würden 3 Datensätze in der Tabelle ITAB stehen, dann würde im Protokoll "Zähler = 3" stehen, aber es wird nur der letzte Datensatz protokolliert mit seinem Inhalt.
Nutzung Subkey
Möchte man alle Datensätze von Variablen innerhalb einer Schleife protokollieren, dann kann man tricksen, indem man den SUBKEY nutzt und für jeden Schleifendurchlauf unterschiedlich füllt. Andernfalls bei der Nutzung vom gleichen Subkey (bzw. ohne Subkey) würde von einer Schleife nur der letzte Datensatz protokolliert.
Data: lv_subkey type RTM_SUBID. "char200 Loop at itab into wa. add 1 to lv_subkey. LOG-POINT id ZTEST subkey lv_subkey fields wa-feld1 wa-feld2. endloop.
Nutzung LOG-POINT mit Methodenaufruf
Man kann auch eine komplette Methode im Log-Point aufrufen.
Ein Beispiel aus dem Solution Manager (Komponente ST, Release 720, Kurzbeschreibung: SAP Solution Manager Tool) aus Klasse CL_SMUD_SEARCH_QUERY, Methode: SEARCH_INTERNAL):
log-point id smud_search_query subkey 'SEARCH_INTERNAL'
fields search_internal_logpoint( exporting
it_querydata = lo_trex_query->data
io_esh_search_response_nodes = eo_esh_search_response_nodes ).
In der Methode "search_internal_logpoint" werden umfangreiche Protokolle und weitere Prüfungen durchgeführt. Die Methode "search_internal_logpoint" wird nicht durchlaufen, wenn der Log-Point "smud_search_query" nicht aktiviert ist.
Assertions (Variablenwerte prüfen)
Eine Assertion ist eine Prüfung im Coding auf eine Bedingung.Wenn die Bedingung unter "Condition" NICHT erfüllt ist, dann kann man in der Transaktion SAAB einstellen, ob er in den Debugger springt, ob Variablen protokolliert werden sollen oder ob an der Assertion-Stelle das Programm mit einem Laufzeitfehler abbrechen soll.
Der Gedanke ist also, dass man davon ausgeht, dass im Allgemeinen die Bedingung erfüllt ist. Aber wenn sie nicht erfüllt ist, will man wissen warum und dann protokolliert man z. B. Variablen.
Ist der Assert-Befehl auf "inaktiv" gesetzt, dann wird der Assert-Befehl im Coding ignoriert.
ASSERT ID ZREBTEST
FIELDS gv_2-vbeln
gv_2-posnr.
CONDITION gv_2-vbeln = lv_vbeln.
Hier ist die Checkpoint aktiv zur Protokollierung.
data: lv_datum type datum. lv_datum = sy-datum. assert id ../aif_ber1reb_sfp fields lv_datum condition lv_datum <> sy-datum.
Ausgabe im Protokoll
Vorsicht: Checkpoint-Gruppen und Transporte
- Speziell bei Transporten ins Produktivsystem sind Transportabbrüche mit einem Returncode 8 ärgerlich und für alle Beteiligten stressig. Checkpoint-Gruppen sind hier auch eine mögliche Gefahrenquelle.
- Wenn die Checkpoint-Gruppe im Zielsystem nicht vorhanden ist und nicht im aktuellen Transport enthalten ist, wird das entsprechende Objekt (Programm, Funktionsbaustein, Methode, Smart Forms, etc.) sich nicht syntaxfrei im Zielsystem generieren lassen und der Transport wird auf einen Fehler laufen (Returncode 8). Diese Fehlerquelle kann man minimieren, indem man Checkpoint-Gruppen in einen separaten Transport speichert und schnell ins Produktivsystem transportiert.
- Wenn man eine Checkpoint-Gruppe löscht, ist dies eine weitere Gefahrenquelle. Beim Löschen bekommt man nicht immer einen Hinweis, dass diese Checkpoint-Gruppe noch in einem Programm verwendet wird. Dies ist mir kürzlich passiert, als eine Checkpoint-Gruppe in einem Smart Forms angesprochen wurde und ich die Checkpoint-Gruppe anschließend löschte und annahm, dass sie nicht mehr verwendet wird. Der Verwendungsnachweis der Checkpoint-Gruppe weist nicht auf Fundstellen in einem Smart Forms hin. Daher kann dann ein Smart Forms im Produktivsystem, was seit Monaten/Jahren problemlos läuft, auf einmal einen Syntaxfehler generieren, wenn die angesprochende Checkpoint-Gruppe nicht mehr existiert. Daher sollte sehr sorgfältig erwogen werden eine Checkpoint-Gruppe zu löschen und im Zweifel lieber nicht löschen, da eine unbenutzte Checkpoint-Gruppe auch nicht stört.
- Eine Checkpoint-Gruppe sollte nicht lokal angelegt werden. Die Verweise auf eine solche Checkpoint-Gruppe müssten vor einem Transport entfernt werden und das ist häufig kaum sicher zu überblicken für einen Entwickler, wo überall Checkpoint-Gruppen verwendet werden. Hier würde der Fehler schon beim Transport ins Q auffallen. Aber trotzdem sollten Checkpoint-Gruppen auch immer ins Produktiv transportiert werden.
Einsatz Checkpoint-Gruppe
Start-of-Selection
- Oft macht es Sinn in einem Report einen Breakpoint direkt nach dem Ereignis "Start-of-Selection" zu setzen, um dann diesen Breakpoint bei Bedarf schnell aktivieren zu können und das ganze Coding von den Ereignissen "Initialization", "At-Selection-Screen", "At-Selection-Screen on <field>" und "At selection-screen output" überpringen zu können.
- Man sollte der Checkpoint-Gruppe den gleichen Namen geben wie den Report, damit man sich den Namen gut merken kann.
****************************************** * --------- START-OF-SELECTION --------- * ****************************************** start-of-selection. BREAK-POINT id ZREBTEST.
Vor Formularaufruf (Smart Forms und Adobe Forms)
- Direkt vor dem Formularaufruf (in Smart Forms oder Adobe Forms) sind alle Daten im Rahmenprogramm gefüllt. Hier kann man dann schnell feststellen, ob z. B. bei bei einem fehlerhaften/nicht vorhandenen Wert im Formular das Problem in der Datenversorgung des Druckrahmenprogramms liegt oder im Formular.
- Es bietet sich durchaus an für SAPscript, Smart Forms und Adobe Forms die gleiche Checkpoint-Gruppe zu nehmen. So muss man bei einem Formularaufruf gar nicht wissen welche Formulartechnologie hinter einem Formularaufruf steckt.
BREAK-POINT ID ZFORM.
call function lv_fm_name
EXPORTING
/1bcdwb/docparams = ls_docparams
bil_prt_com = gs_interface
IMPORTING
/1bcdwb/formoutput = ls_pdf_file
EXCEPTIONS
usage_error = 1
system_error = 2
internal_error = 3
others = 4.
In Schnittstelle
- Die Schnittstelle vom Adobe Forms-Formular wird man auch sehr häufig debuggen wollen.
- Man kann die gleiche Checkpoint-Gruppe in jede Formularschnittstelle einbauen und auch die gleiche Checkpoint-Gruppe wie in der Initialisierungsroutine eines Smart Forms verwenden..
Es bietet sich auch an, hier gleich im Kommentar die relevanten Schnittstellenparameter hinzuzufügen. So können Sie gleich per Doppelklick im Debugger angezeigt werden. Das eine Leerzeichen nach dem " ist dabei wichtig. Sonst erkennt der Debugger nicht die Variable beim Doppelklick (z. B. auf IT_VERTRAGSDATEN).
BREAK-POINT id ZFORM_INIT. " IT_VERTRAGSDATEN
" IS_FORMPARAM
Initialisierungsroutine eines Smart Forms
- Jedes Smart Forms-Formular hat eine Initialisierungsroutine, wo Coding hinzugefügt werden kann. Hier kann man sehr gut die Schnittstelle des Smart Forms einsehen und wichtige Programmroutinen debuggen.
BREAK-POINT id ZFORM_INIT.
Web-Links
- SAP-Hilfe: Checkpoints
- Tricktresor: Log-Points zur Performancemessung
- SAP-Hilfe: Schlüsselbefehl Assert
- Tricktresor: Aktivierungen in Tabelle AAB_ID_ACT
Literatur
- ABAP - Fortgeschrittene Techniken und Tools, Band 2, von Andreas Blumenthal, Horst Keller, S. 443 ff
- ABAP Workbench - 100 Tipps & Tricks, von Christian Assig, S. 235 ff.
