Benutzer-Rückfrage
Ereignisaktion - Kurzfassung
Zweck: Zeigt im Client einen benutzerdefinierten Ja/Nein-Dialog und unterbricht die Ereignisverarbeitung bis der Anwender eine Auswahl getroffen hat oder eine definierte maximale Wartezeit (Timeout) überschritten ist
Die Ereignisaktion Benutzer Rückfrage zeigt im Client einen benutzerdefinierten Ja/Nein-Dialog (s. Screenshot) und unterbricht die Ereignisverarbeitung bis der Benutzer eine Auswahl getroffen hat oder eine definierte maximale Wartezeit ("Timeout") überschritten ist.
Danach wird die Ereignisverarbeitung abhängig vom Ergebnis in einem von drei Zweigen einer Fallunterscheidung fortgesetzt.
|
|
|
►WICHTIG◄ Der Timeout-Zweig ist besonders relevant, falls die Ereignisaktion nicht nur interaktiv, sondern z. B. auch durch Ereignisse im Kontext eines Import-Jobs ausgelöst werden kann. Das kann z. B. passieren, wenn Arbeitsstatuswechsel via Schnittstelle veranlasst werden können und ein bestimmter Zielstatus eine Ereignisbehandlung auslöst, die eine Benutzer Rückfrage beinhaltet. In diesem Fall gibt es keinen Adressaten, der auf die "Rückfrage" reagieren könnte. Effektiv wartet der Import-Job (auf dem Lobster_data-System) einfach ab bis die Wartezeit abgelaufen ist. Danach werden die ggf. im Timeout-Zweig konfigurierten Ereignisaktionen ausgeführt.
Konfiguration
Ausgabetexte für die Parameter Titel und Text können wahlweise (s. Beispiel unten) per Direkteingabe oder als Rückgabewert eines Wertauflösers erfolgen. Der Wertauflöser Wert aus Sprachverwaltung kann dabei auch Lokalisierungseinträge aus der Sprachverwaltung bzw. Firmenspezifische Sprachanpassungen einbeziehen, so dass die "Rückfrage" entweder in der Sprache des angemeldeten Benutzers oder ggf. auch in einer gezielt davon abweichenden Sprache erscheint.
Der Parameter maximale Wartezeit (s) beinhaltet eine statische Ganzzahl, die angibt für wie viele Sekunden der Dialog mit der "Benutzer-Rückfrage" im Client maximal angezeigt wird, wenn keine Reaktion des Benutzers erfolgt. Als Standardwert werden 30 Sekunden vorgeschlagen.
►WICHTIG◄ Wenn für die maximale Wartezeit (s) ein Wert von 0 Sekunden angegeben wird, wird dies als "unendliche" Wartezeit interpretiert. Der Dialog wird dann nie automatisch geschlossen. Diese Einstellung sollte nur vorgenommen werden, wenn hinreichend sicher ist, dass die Ereignisbehandlung unter keinen Umständen durch eine Schnittstelle (z. B. einen Import-Job) ausgelöst wird, da die Schnittstelle sonst ggf. "ewig" auf einen Timeout wartet.
Unterhalb der Parameter können optional in jedem der Zweige der Fallunterscheidung (Yes, No und Timeout) Ereignisaktionen per Klick auf das 
-Symbol hinzugefügt werden.
Zur Laufzeit wird abhängig von der Reaktion jeweils genau einer der Zweige der Fallunterscheidung abgearbeitet. Danach wird die Ereignisverarbeitung - unabhängig vom abgearbeiteten Zweig - "unterhalb" der Ereignisaktion fortgesetzt, sofern nicht eine Abbrechen ausgeführt wird oder ein Fehler auftritt.
Beispiel
Bevor die Daten einer Sendung per "Export" an eine Schnittstelle zu einem anderen System übergeben wird, soll von dem Benutzer, der diese Übergabe interaktiv ausgelöst hat, eine ausdrückliche Bestätigung für diesen Schritt eingeholt werden.
Dabei ist zu berücksichtigen, dass der entsprechende Auslöser (z. B. ein Wechsel zu einem bestimmten Arbeitsstatus) auch durch eine Aktualisierung der Sendungsdaten per Schnittstelle ausgelöst werden kann. Dann soll der Export automatisch ausgeführt werden.
Konfiguration:
|
Die Benutzer Rückfrage wird für diesen Zweck innerhalb einer Ereignisbehandlung für die betreffende Sendung eingefügt und wie rechts abgebildet parametriert:
|
|
|
Zur Laufzeit erscheint die Rückfrage als Dialog mit den Schaltflächen "Ja" und "Nein" unter Berücksichtigung von konkreten Sendungsdaten z. B. so wie rechts abgebildet, wenn der Vorgang interaktiv ausgelöst wurde. Geht der Vorgang dagegen auf einen Import per Schnittstelle zurück, dann wird der Export (nach 30 Sekunden Wartezeit) automatisch ausgeführt. |
|
►ANMERKUNGEN◄
In der Praxis soll soll bei einem Timeout entweder die Zustimmung oder die Ablehnung zur Rückfrage angenommen werden. Technisch müssen dann die betreffenden Ereignisaktionen redundant konfiguriert sein, da es keine Möglichkeit gibt, vom Timeout-Zweig auf einen der anderen Zweige "umzuleiten". Im Beispiel beschränkt sich die Redundanz dabei auf die Ereignisaktion Eigenes Aktionsevent auslösen (Aktion), über die dann jeweils derselbe Prozess in einer anderen Ereignisbehandlung ausgelöst wird.
Alternativ kann es auch sinnvoll sein, das Ergebnis der Rückfrage mit einer "Setze Wert"-Aktion in jedem Ergebniszweig in einer Variable zu speichern (z. B. als Booleschen Wert) um die eigentliche Fallunterscheidung anschließend in einer Wenn Dann Sonst-Ereignisaktion ausgehend vom Wert der Variablen abzuhandeln. Dann kann bei einem Timeout einfach der Wert (true oder false) gesetzt werden, der dem Yes- oder No-Zweig entspricht.