Transaktion SAAB (aktivierbare Checkpoints)

Aus SAP-Wiki
Wechseln zu: Navigation, Suche

Die Transaktion SAAB bietet ein paar sehr schöne einfache 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 dann einstellen, ob dieser Breakpoint angesprungen wird oder nicht, bzw. der Breakpoint aktiv ist oder nicht. Oder auch das Variablen protokolliert werden oder das Annahmen/Assertions geprüft werden.

Transaktion SAAB

Geben Sie einen Namen für die Checkpoint-Gruppe ein und drücken auf den Button Button Neu.jpg

SAAB1.jpg

Vergeben Sie eine Beschreibung und weisen Sie der Änderung ein Paket und einen Transportauftrag zu.

Checkpoint-Gruppe ändern

SAAB2.jpg

Nun können u. a. die Breakpoints aktiviert oder deaktiviert werden, die in Bezug auf diese Checkpoint-Gruppe im Coding angelegt wurden

SAAB3.jpg

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 SAAB1 2.JPG 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 (was sehr selten empfehlenswert sein 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.

SAAB1 1.JPG

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.

Arten einer Checkpoint-Gruppe

Die Transaktion teilt sich in drei Bereiche auf

  • Breakpoints
  • Logpoints
  • Assertions

SAAB2.jpg

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.

SAAB3.jpg

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.

SAAB4.jpg

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

SAAB5.jpg


Nach Doppelklick auf diese Zeile sieht man auch die Variableninhalte.

Protokollierung Strukturen und Tabellen

Es ist eingeschränkt möglich Strukturen und Tabellen zu protokollieren.

SAAB1 6.JPG


SAAB1 7.JPG


Die Strukturen werden nicht mit ihren eigentlichen Feldnamen, sondern mit COMP1, COMP2, etc. protokolliert.

SAAB1 8.JPG


Die Tabellen werden ebenso mit COMP1, COMP2, etc. protokolliert. Ferner werden lediglich maximal 3 Datensätze der Tabelle protokolliert.

SAAB1 9.JPG

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.

SAAB6.jpg

Nutzung Subkey

Möchte man alle Datensätze protokollieren, dann kann man tricksen, indem man den SUBKEY nutzt und für jeden Schleifendurchlauf unterschiedlich füllt.

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.

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.

SAAB7.jpg

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.

SAAB1 5.JPG

data: lv_datum  type datum.

 lv_datum = sy-datum.

 assert id /tup/aif_ber1reb_sfp
  fields lv_datum
  condition lv_datum <> sy-datum.

Ausgabe im Protokoll

SAAB1 3.JPG


SAAB1 4.JPG

Mehr in der SAP-Hilfe.

Checkpoint-Gruppen und Gefahrenquelle 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

Literatur