Debugger (Ereignisbehandlung)
Der Debugger ist über das Hauptmenü zu erreichen und ist wie folg aufgebaut:
1 |
Startet/Pausiert den Debugger. Wird der Baustein mit dem Haltepunkt als nächstes ausgeführt, pausiert der Debugger die Abarbeitung zu Analysezwecken. |
2 |
Listet sämtliche aktive Haltepunkte auf. |
3 |
Stoppt den Debugger und verwirft dabei sämtliche Haltepunkte. |
4 |
Schränkt das Pausieren an Haltepunkten auf ausgewählte Sitzungen ein.
|
5 |
Zeigt sämtliche Haltepunkte an denen gerade pausiert wird. Der Name eines Eintrags setzt sich dabei aus der abgekürzten Typbezeichnung (z.B. AEHC für Ereignisbehandlung), der ID der beinhaltenden Konfiguration und einem fortlaufenden Zähler, sowie dem Benutzernamen der Sitzung und einer Quelle zusammen (bei Verhalten der Verhaltensname). |
6 |
Mit Hilfe dieser Funktionen kann granular entschieden werden, ob und wie an einer pausierten Stelle fortgefahren werden soll.
|
7 |
Zeigt den Zustand der Eingabedaten (Ergebnis), sämtlicher Variablen und die aktuellen Lognachrichten. Hinweis: Bei Verhalten zeigt der "Variablen" Reiter keine Einträge und der Reiter "Log" zeigt lediglich die Element-ID des auslösenden Elements und die Art der Interaktion an (z.B. MANUAL_CHANGED, wenn der Benutzer selbst ein Verhalten angestoßen hat). |
Achtung: Während ein Haltepunkt in einer Ereignisbehandlung aktiv ist, wird ein Server-Thread und i.d.R. eine Datenbanktransaktion komplett blockiert. Daher sollte auf Live-Systemen nur in Notfällen länger gedebugged werden.
Dies trifft nicht für Client-Workflows und Verhalten zu.
Haltepunkte setzen
In Bausteinen von Ereignisbehandlungen und Client-Workflows:
Rechtsklick oder "..." Menü eines Bausteins (Regel oder Aktion).
In Verhalten und Aktionen
Anwendungsbeispiel
Ein Portal soll einen numerischen Wert als Variable "n" an die Ereignisbehandlung eines eigenen Aktionsevents namens "Iterate" übergeben.
Beim Klicken auf den "Iterate" Knopf wird das eigene Aktionsevent "Iterate" ausgelöst und zusätzlich wird der Wert des numerischen Textfeldes als Parameter "n" übergeben.
Eine zugehörige Ereignisbehandlung soll zunächst prüfen, ob der Parameter "n" >= 0 ist und wenn ja, wird eine Schleife n Mal durchlaufen und fügt dabei den Index des Durchlaufs zu einer Liste "entries" hinzu
Das soll nun Schritt für Schritt mit dem Debugger überprüft werden.
Beispiel 1:
Der Debugger wird geöffnet und gestartet.
Danach wird ein Haltepunkt in der prüfenden Regel gesetzt:
Der Baustein wird dann entsprechend visuell hervorgehoben.
Als nächstes wird das Portal geöffnet, im Textfeld der Wert "5" eingetragen und dann auf den "Iterate" Knopf gedrückt.
Der Debugger rückt nun automatisch in den Vordergrund und zeigt den Zustand der Ereignisbehandlung zum Zeitpunkt VOR der Ausführung der Regel.
Im Reiter "Variablen" können nun alle zum jetzigen Zeitpunkt gültigen Variablen eingesehen werden.
Hier deutlich zu sehen, der Parameter "n" als Variable mit dem Wert 5.
Mit einem "Einzelschritt" im Debugger (6) kann die weitere Logik nun Baustein für Baustein "durchgeschrittet" werden.
Der aktuell besuchte Baustein wird ebenfalls entsprechend visuell hervorgehoben.
Beispiel 2:
Die einzelnen Iterationen der Schleife sollen analysiert werden. Daher wird ein Haltepunkt im "Liste modifizieren" Baustein gesetzt.
Ausgehend vom letzten Zustand aus Beispiel 1 können nun mit der "Fortfahren" Funktion im Debugger (6) die einzelnen Schleifendurchläufe analysiert werden.
Ein Blick in den Zustand der Variablen zeigt, dass die Schleifenvariablen nun ebenfalls verfügbar sind:
Durch wiederholtes Drücken auf den "Fortfahren" Knopf kann beobachtet werden, wie die Variable "$index" hochzählt und Einträge zur "entries" Liste hinzugefügt werden.
Unten stehende Tabelle zeigt den Zustand der beiden Variablen für jeden pausierten Haltepunkt.
Durchlauf |
entries |
$index |
0 |
< key xsi:type = "xsd:string" >entries</ key > < value xsi:type = "list" ></ value > |
< key xsi:type = "xsd:string" >$index</ key > < value xsi:type = "xsd:int" >0</ value > |
1 |
< key xsi:type = "xsd:string" >entries</ key > < value xsi:type = "list" > < entry xsi:type = "xsd:int" >0</ entry > </ value > |
< key xsi:type = "xsd:string" >$index</ key > < value xsi:type = "xsd:int" >1</ value > |
2 |
< key xsi:type = "xsd:string" >entries</ key > < value xsi:type = "list" > < entry xsi:type = "xsd:int" >0</ entry > < entry xsi:type = "xsd:int" >1</ entry > </ value > |
< key xsi:type = "xsd:string" >$index</ key > < value xsi:type = "xsd:int" >2</ value > |
3 |
< key xsi:type = "xsd:string" >entries</ key > < value xsi:type = "list" > < entry xsi:type = "xsd:int" >0</ entry > < entry xsi:type = "xsd:int" >1</ entry > < entry xsi:type = "xsd:int" >2</ entry > </ value > |
< key xsi:type = "xsd:string" >$index</ key > < value xsi:type = "xsd:int" >3</ value > |
4 |
< key xsi:type = "xsd:string" >entries</ key > < value xsi:type = "list" > < entry xsi:type = "xsd:int" >0</ entry > < entry xsi:type = "xsd:int" >1</ entry > < entry xsi:type = "xsd:int" >2</ entry > < entry xsi:type = "xsd:int" >3</ entry > </ value > |
< key xsi:type = "xsd:string" >$index</ key > < value xsi:type = "xsd:int" >4</ value > |
Dieses vereinfachte Beispiel zeigt, dass insbesondere im Bezug auf Schleifen, der Einsatz des Debuggers eine Fehlersuche oder Algorithmusanalyse erheblich erleichtern kann.