Debugger (Ereignisbehandlung)

Mit Hilfe des Debuggers lassen sich Ereignisbehandlungen, Client-Workflows und Formular Verhalten/Aktionen an dedizierten Haltepunkten (engl. Breakpoint) pausieren und analysieren.
Dazu kann das aktuelle Eingabeobjekt, der momentane Zustand sämtlicher Variablen und das zugehörige Log eingesehen werden.
Tipp: An Haltepunkten wird auch im Testmodus einer Ereignisbehandlung angehalten.


Der Debugger ist über das Hauptmenü zu erreichen und ist wie folg aufgebaut:

images/download/attachments/78263619/image2021-9-22_9-41-25-version-1-modificationdate-1632303263453-api-v2.png

1

Startet/Pausiert den Debugger.
Ist der Debugger gestartet, wird automatisch die Möglichkeit aktiviert, Haltepunkte in Bausteinen von Ereignisbehandlungen hinzuzufügen.
Haltepunkte lassen sich in Bausteinen via Rechtsklick oder das "..." Menü aktivieren. Bausteine mit Haltepunkten werden entsprechend grafisch hervorgehoben.
Verhalten und Aktionen können einen Haltepunkt via images/download/attachments/78263619/image2021-9-22_11-44-51-version-1-modificationdate-1632303892627-api-v2.png Symbol setzen.

Wird der Baustein mit dem Haltepunkt als nächstes ausgeführt, pausiert der Debugger die Abarbeitung zu Analysezwecken.
Der Debugger rückt dabei automatisch in den Vordergrund.

Ist der Debugger pausiert, wird an keinem Haltepunkt mehr angehalten, die Haltepunkte bleiben jedoch unangetastet.

2

Listet sämtliche aktive Haltepunkte auf.
Die Namen der Haltepunkte setzen sich dabei aus einer abgekürzten Typbezeichnung (z.B. AEHC für Ereignisbehandlung), der ID der beinhaltenden Konfiguration und einem fortlaufenden Zähler zusammen (bei Verhalten der Verhaltensname).

3

Stoppt den Debugger und verwirft dabei sämtliche Haltepunkte.

Hinweis: Solange der Debugger nicht explizit gestoppt wird, bleiben sämtliche Haltepunkte erhalten, auch wenn der Client neu geladen wird. Erst ein explizites Ausloggen aus dem Client stoppt auch den Debugger automatisch.

4

Schränkt das Pausieren an Haltepunkten auf ausgewählte Sitzungen ein.

  • Auf eigene Sitzung einschränken (Standard) - Es wird nur pausiert, wenn der Haltepunkt innerhalb der eigenen Benutzersitzung erreicht wird

  • Auf Benutzer einschränken (greift nur bei Ereignisbehandlungen)

    images/download/attachments/78263619/image2021-9-22_9-30-39-version-1-modificationdate-1632303263455-api-v2.png



    Es wird nur pausiert, wenn der Haltepunkt innerhalb der Sitzung einer der angegebenen Benutzer erreicht wird. Dabei kann die eigene Sitzung zusätzlich ausgeschlossen werden, sollte mit einem der erwähnten Benutzer gedebugged werden.

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).
Durch das Auswählen eines anderen Sitzungseintrages zeigt der Debuggerdialog die entsprechenden Zustände (7) dieses Haltepunktes an.

6

Mit Hilfe dieser Funktionen kann granular entschieden werden, ob und wie an einer pausierten Stelle fortgefahren werden soll.

  • Fortfahren - Löst die Pausierung und hält erst wieder, wenn der nächste Haltepunkt erreicht wird

  • Einzelschritt - Führt die Ausführung bis zum nächsten Baustein auf selber Ebene fort

  • Mikroschritt - Springt in den pausierten Baustein hinein und pausiert beim nächsten untergeordneten Baustein

  • Alle fortfahren - Analog zu "Fortfahren", im Bezug auf alle momentan pausierten Haltepunkte (5)

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).

images/download/attachments/78263619/image2021-9-22_11-50-47-version-1-modificationdate-1632304249448-api-v2.png

In Verhalten und Aktionen

images/download/attachments/78263619/image2021-9-22_11-52-48-version-1-modificationdate-1632304370240-api-v2.png

Anwendungsbeispiel

Ein Portal soll einen numerischen Wert als Variable "n" an die Ereignisbehandlung eines eigenen Aktionsevents namens "Iterate" übergeben.

images/download/attachments/78263619/image2021-9-22_10-1-33-version-1-modificationdate-1632303263450-api-v2.png

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

images/download/attachments/78263619/image2021-9-22_10-18-59-version-1-modificationdate-1632303263448-api-v2.png

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:

images/download/attachments/78263619/image2021-9-22_10-23-11-version-1-modificationdate-1632303263446-api-v2.png

Der Baustein wird dann entsprechend visuell hervorgehoben.

images/download/attachments/78263619/image2021-9-22_10-24-3-version-1-modificationdate-1632303263443-api-v2.png

Als nächstes wird das Portal geöffnet, im Textfeld der Wert "5" eingetragen und dann auf den "Iterate" Knopf gedrückt.

images/download/attachments/78263619/image2021-9-22_10-29-29-version-1-modificationdate-1632303263442-api-v2.png

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.

images/download/attachments/78263619/image2021-9-22_10-33-43-version-1-modificationdate-1632303263439-api-v2.png

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.
images/download/attachments/78263619/image2021-9-22_10-53-19-version-1-modificationdate-1632303263435-api-v2.png

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.
images/download/attachments/78263619/image2021-9-22_10-56-42-version-1-modificationdate-1632303263433-api-v2.png

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:

images/download/attachments/78263619/image2021-9-22_10-59-27-version-1-modificationdate-1632303263415-api-v2.png

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.