Zum Hauptinhalt springen

ABAP-Analyse: Aktivierbare Checkpoints (SAAB)

Review

Dieser Artikel wird noch kontrolliert. Dies ist eine Vorab-Version!

Bei den Checkpoints handelt es sich um Analyse- und Testwerzeuge die primär in der Entwicklungsphase eingesetzt werden. Im produktiven Umfeld sind diese dann eher unerwünscht, außer es kommt zu einer Fehleranalyse, dann sind diese Checkpoints Gold wert.

Aus diesem Grund werden Checkpint-Gruppen definiert und diese in den Programmen eingebaut. So können diese Gruppen im Bedarfsfall aktiviert werden. Inaktive Checkpoints werden beim Programmlauf ignoriert, bei aktiven Checkpoints erfolgt eine entsprechende Reaktion, indem entweder beim BREAK-POINT stehen geblieben wird, bei einem LOG-POINT ein Protokolleintrag erfolgt usw.

Checkpoint-Anweisungen ohne den Zusatz ID können nicht über eine programmspezifische Einstellung gesteuert werden, da solche Checkpoints immer aktiv sind.

Die Aktivierung erfolgt über die Transaktion SAAB.

Transaktion: SAAB​

In der Transaktion SAAB werden Checkpointgruppen angelegt und bearbeitet. Dies erfolgt im Entwicklungsmandanten und die Einstellungen werden dann über das Transportwesen in die anderes Systeme weitergegeben.

Checkpoint-Gruppe anlegen​

Um in einem Programm eine Checkpoint-Gruppe zu nutzen, muss diese angelegt sein. Fehlt diese, so wird bei der Aktivierung des Codes ein Fehler erzeugt. Dies ist möglich da der Name der Checkpoint-Gruppe nicht in Hochkommas (') angegeben wird, sondern direkt ähnlich eines Variablennamens.

Berechtigungsprüfung

Es wird das Berechtigungsobjekt S_DEVELOP mit dem Objekttyp ACID (Checkpoint-Gruppe) und folgenden Aktivitäten geprüft:

  • 01 - Anlegen
  • 02 - Ändern
  • 03 - Anzeigen
  • 06 - Löschen

Daher muss eine Checkpoint-Gruppe angelegt sein. Hierzu in die Transaktion SAAB gehen und im Block Checkpoint-Gruppe den Namen angeben. Bitte wie gehabt im Z-Namensraum. Anschließend auf den Button Neu

klicken und eine Beschreibung mitgeben. Anschließend muss die neue Checkpoint-Gruppe einem Paket zugeordnet werden und ein Transportauftrag erstellt/verwendet werden.
note

Im Gegensatz zur Checkpoint-Gruppe selbst sind die Aktivierungseinstellungen zu einer Checkpoint-Gruppe nicht transportierbar. Wenn eine neu angelegte Gruppe transportiert wird, ist sie im Zielsystem per Default inaktiv. Wenn eine existierende Gruppe geändert wird, bleibt der Aktivierungszustand in Zielsystem unverändert.

Danach ist die Checkpoint-Gruppe bereit und kann im Coding verwendet werden. Eine neu angelegte Checkpoint-Gruppe ist per Default inaktiv, da in diesem Fall noch keine entsprechende Aktivierungseinstellung erzeugt wurde.

Checkpoint-Gruppe ändern/aktivieren​

Die Ändern-Funktion einer Checkpoint-Gruppe ist missverständlich, da es nichts zu ändern gibt. Vielmehr ist mit dem Ändern die Aktivierung der Checkpoint-Gruppe gemeint.

Der Ändern-Modus ist nur im Entwicklungsmandanten möglich, in allen anderen Mandanten/Systemen muus die Aktivierungs-Funktion genutzt werden. Hierzu wieder in die Transaktion SAAB gehen. Dort den Namen der Checkpoint-Gruppe eingeben. Anschließend auf Button Aktivieren

klicken. Es öffnet sich ein neues Dynpro mit den Aktivierungsmöglichkeiten:

Sie können nun individuell entscheiden, was an den drei möglichen Checkpoints passieren soll.

Mehrere User auswählen​

Diese Einstellungen werden Standardmäßig für Ihren User vorgenommen. Sie können aber bei Bedarf die Einstellungen auch für weitere User vornehmen. Hierzu auf den Button Benutzer

klicken. Es öffnet sich ein Popup mit den vorgenommen Einstellungen (sprich Liste aller User). Mit dem Neu-Button im Popup können Sie weitere Benutzer aufnehmen zusätzlich noch die Aktivierungsart markieren und mit `Weiter` bestätigen:
Berechtigungsprüfung

Beim Aktivieren einer Checkpoint-Gruppe wird die Anzeigeberechtigung zum Debuggen geprüft. Soll ein Anwender in der Lage sein, eine Checkpoint-Gruppe für andere oder alle Benutzer zu aktivieren, wird die Änderungberechtigung zum Debuggen (Aktivität 02) benötigt. Zusätzlich wird das Berechtigungsobjekt S_ADMI_FCD (mit PADM) geprüft.

Server-Aktivierung auswählen​

Wenn Sie einen Server für die Aktivierung auswählen, so gehen Sie genauso vor, wie bei der Aktivierung zusätzlicher User.

caution

Wenn Sie einen Server aktivieren, so gelten die Einstellungen für alle Benutzer. Einstellungen für einzelne Benutzer werden ignoriert.

Aktivierung​

Die tatsächliche Aktivierung erfolgt erst mit dem Klick auf Speichern im Hauptdynpro der Transaktion SAAB. Hierbei muss die Dauer der Einstellungen definiert werden. Hierzu erscheint ein Popup. Nach Ablauf des Zeitraums werden alle Einstellungen des eigenen Users (sowie der von Ihnen definierten anderen Usern) zurück, sprich auf inaktiv gesetzt.

Haben Sie einen Server gewählt so werden die globelen Einstellungen für alle Benutzer auf dem Server eingestellt.

note

Im Gegensatz zur Checkpoint-Gruppe selbst sind die Aktivierungseinstellungen zu einer Checkpoint-Gruppe nicht transportierbar. Wenn eine neu angelegte Gruppe transportiert wird, ist sie im Zielsystem per Default inaktiv. Wenn eine existierende Gruppe geändert wird, bleibt der Aktivierungszustand in Zielsystem unverändert.

Checkpoints und Code-Snippets​

BREAK-POINT ID​

Ein Break-Point kann entweder ingnoriert werden oder man hält an. Anhalten bedeutet, dass das Programm im Debug-Modus anhält. Dies ist jedoch in folgenden Situationen nicht möglich:

  • Hintergrundverarbeitung
  • synchrone oder asynchrone Verbuchung
  • HTTP-Sitzungen ohne externes Debugging
"Hinweis: Checkpoint-Gruppe Z_BEISPIEL muss vorhanden sein ins TC: SAAB
BREAK-POINT ID z_beispiel.

Man kann beim Erreichen eines aktiven Break-Points in der Hintergundverarbeitung bzw. während der Verbuchung auch im Systemprotokoll einen Eintrag erzeugen. Hierbei wird der Text (max. 40 Zeichen, Typ string wird ignoriert) zwischen 'Breakpoint' und 'erreicht' geschrieben. Während der Dialogverarbeitung hat die Angabe des Textes keine Wirkung:

"Hinweis: Checkpoint-Gruppe Z_BEISPIEL muss vorhanden sein ins TC: SAAB
BREAK-POINT ID z_beispiel 'Text'.

LOG-POINT ID​

Variablen​

Hinter dem Zusatz FIELDS kann eine Liste beliebiger Werte, ausgenommen Referenzvariablen, angegeben werden, die in das Protokoll übernommen werden. Die Länge ist per Default auf 1.024 bytes begrenzt, kann aber im Profil geändert werden.

DATA 
     : lv_beispiel  TYPE TEXT100
     , lv_zwei      TYPE TEXT100
     .

lv_beispiel = 'Beispiel'.
lv_zwei     = 'Zweite Variable'.

"Hinweis: Checkpoint-Gruppe Z_BEISPIEL muss vorhanden sein ins TC: SAAB

"Eine Variable
LOG-POINT ID z_beispiel FIELDS lv_beispiel. 

"Mehrere Variablen
LOG-POINT ID z_beispiel 
      FIELDS lv_beispiel 
             lv_zwei
.

Im Protokoll werden dann die Variablennamen aufgelistet mit Ihren Feldwerten.

Strukturen und Tabellen​

Neben den einzelnen Variablen können auch ganze Strukturen und Tabellen übergeben werden. Allerdings mit der Einschränkung, dass einzelne Spalten nicht den tatsächlichen technischen Namen haben, sondern mit COMP1, COMP2 ... angegeben werden.

caution

Die Größe jedes der mit dem Zusatz FIELDS im Protokoll abgespeicherten Datenobjekte wird durch den Profilparameter abap/aab_log_field_size_limit begrenzt. Der Wert des Profilparameters gibt die Größe in Bytes an. Der voreingestellte Wert ist 1.024. Der Wert 0 bedeutet keine Beschränkung. Bei Erzeugen eines Protokolleintrags wird der Inhalt jedes Datenobjekts an dieser Grenze abgeschnitten, wobei bei internen Tabellen vollständige Zeilen entfernt werden.

Methoden​

Neben Variablen, Strukturen und Tabellen können auch funktionale Methoden aufgerufen werden. Diese werden nur aufgerufen, wenn der Log-Point aktiviert ist.

SUBKEY​

Standardmäßig wird dabei ein bereits vorhandener Eintrag der gleichen LOG-POINT-Anweisung überschrieben. Bei der Angabe von SUBKEY wird der Inhalt als Unterschlüssel im Protokoll abgelegt. Bereits vorhandene Protokolleinträge der gleichen LOG-POINT-Anweisung werden nur bei gleichem Inhalt des Unterschlüssels überschrieben. Ohne die Angabe von SUBKEY ist der Unterschlüssel initial.

Beim SUBKEY handelt es sich um eine zeichenartige Ausdrucksposition, von der die ersten 200 Zeichen ausgewertet werden. Ein dort angegebener Ausdruck oder eine dort angegebene Funktion werden nur ausgeführt, wenn der Logpoint aktiv ist.

ASSERT ID​

Bei Erreichen einer aktiven Assertion wird die zugehörige Bedingung ausgewertet. Bei Verletzung der Bedingung wird das Programm mit einem Laufzeitfehler abgebrochen, in den ABAP Debugger verzweigt oder ein Protokolleintrag erzeugt. Bei Zuordnung zu einer Checkpoint-Gruppe wird das Verhalten über die zugehörigen Aktivierungseinstellungen gesteuert, ansonsten wird das Programm abgebrochen. 

ASSERT ID z_beispiel
          CONDITION lv_beispiel IS NOT INITIAL.

SUBKEY​

Der Zusatz SUBKEY wirkt nur, wenn die Anweisung ASSERT Einträge in ein Protokoll schreibt. Bei der Angabe von SUBKEY wird der Inhalt als Unterschlüssel im Protokoll abgelegt. Bereits vorhandene Protokolleinträge der gleichen ASSERT-Anweisung werden nur bei gleichem Inhalt des Unterschlüssels überschrieben. Ohne die Angabe von SUBKEY ist der Unterschlüssel initial.

Beim INhalt von SUBKEY handelt es sich um eine zeichenartige Ausdrucksposition, von der die ersten 200 Zeichen ausgewertet werden. Ein dort angegebener Ausdruck oder eine dort angegebene Funktion werden nur ausgeführt, wenn die Assertion aktiv und der logische Ausdruck falsch ist.

Aktivierungsmöglichkeiten und ihre Auswirkungen​

protokollieren

Anlegen eines Eintrags in einem speziellen Protokoll und Fortsetzen der Programmausführung mit der auf ASSERT folgenden Anweisung. Die Protokolleinträge werden im Shared Memory gesammelt und von einem periodischen Hintergrund-Job in eine Datenbanktabelle geschrieben. Standardmäßig wird dabei ein bereits vorhandener Eintrag der gleichen ASSERT-Anweisung überschrieben. Bei jedem Schreiben eines Eintrags wird ein Zähler für den Eintrag erhöht.

anhalten / protokollieren oder anhalten / abbrechen

Verzweigen in den ABAP Debugger. In der Dialogverarbeitung verhält sich die Anweisung ASSERT dabei wie die Anweisung BREAK-POINT.
Für die Fälle, in der die Anweisung BREAK-POINT einen Eintrag in das Systemprotokoll schreibt, d.h. in Hintergrund, Verbuchungs-, ICF- und APC-Sitzungen ohne externes Debugging, wird die alternativ angegebene Einstellung verwendet.

abbrechen

Auslösen einer unbehandelbaren Ausnahme und Abbruch des Programms mit dem Laufzeitfehler ASSERTION_FAILED.