Client Workflow

Die Verhaltensweise Client Workflow ermöglicht die Konfiguration von clientseitig ausführbaren Abläufen unter Verwendung der ansonsten strikt serverseitig zuzuordnenden Methodik der Ereignisbehandlungen.

Die Konfiguration des eigentlichen "Client Workflows" orientiert sich am Aufbau von Ereignisbehandlungen, insoweit als der logische Rückgabewert einer "Prüfenden Regel" entscheidet, ob die "unterhalb" konfigurierten Ereignisaktionen ausgeführt werden. Für diese beiden Ebenen stehen nur ausgewählte der insgesamt verfügbaren Ereignisaktionen, Regeln und Werte zur Verfügung, nämlich die Komponenten, die technisch für den clientseitigen Einsatz überhaupt in Frage kommen.

images/download/attachments/177914067/image-2024-9-26_11-22-59-version-1-modificationdate-1727342579018-api-v2.png

Im Unterschied zu Ereignisbehandlungen kennt die Konfiguration im "Client Workflow" keine "Auslösenden Ereignisse", da der Kontext der Verhaltensweise die "Auslösung" impliziert.

Für Abläufe, die ...

  1. ... ausgehend vom Kontext eines bestimmten Formulars angestoßen werden sollen, ...

  2. ... mit Komponenten aus dem Kontext der Ereignisbehandlungen (Regeln, Wertauflöser, Ereignisaktionen) konfigurierbar sind, aber ...

  3. ... ohne Serverkommunikation auskommen, also "rein clientseitig ausführbar" sind, ...

... stellt die Verhaltensweise Client Workflow eine schlankere Alternative zur herkömmlichen Vorgehensweise dar, ein Eigenes Aktionsevent zu definieren und eine entsprechende Ereignisbehandlung über die Verhaltensweise Eigenes Aktionsevent auslösen (Formulardesigner) auszulösen.

images/download/attachments/177914067/image2020-4-21_10-24-37-version-1-modificationdate-1727342509084-api-v2.png

Hinsichtlich der Peripherie für den Aufruf des Workflows orientiert sich die Verhaltensweise stark an Form und Logik der Verhaltensweise Eigenes Aktionsevent auslösen (Formulardesigner):

  • Im Kontext einer Erfassungsmaske stehen die zugehörigen Objektdaten der betreffenden Entität (z. B. ein Geschäftsobjekt) automatisch per Ereignisvariable entity im Workflow zur Verfügung.

  • Die Eingabedaten des Verhaltens ($input) werden per Standard (s. Screenshot) über den Parameter value in die entsprechende Ereignisvariable übergeben.

  • Weitere Parameter können analog hinzugefügt werden, um per Ausdruck (s. Berechnungsausdruck) Ereignisvariablen mit demselben Namen für den Workflow zu befüllen.

  • Der optionale Ergebnisausdruck (s. Berechnungsausdruck) definiert ggf. die an die Aktionen des Verhaltens weitergegebenen Daten. Er kann sich direkt auf die Felder des Variablen-Storage beziehen und somit auch direkt auf Ereignisvariablen zugreifen.

    • Ist kein Ergebnisausdruck definiert, dann hängt das Rückgabeverhalten von den Eingabedaten für das Verhalten ab:

      • Wird eine Entität (über die Ereignisvariable entity) übergeben, werden deren Daten - ggf. in manipuliertem Zustand - zurückgegeben.

      • Anderenfalls wird automatisch versucht die Ereignisvariable formData zu lesen.

    • Der Ergebnisausdruck kann sich auf der Grundlage der selben Fallunterscheidung ebenfalls auf die Ereignisvariablen formData und entity beziehen.

Der Button Bearbeiten öffnet den grafischen Editor für die Konfiguration des eigentlichen Workflows (s. Screenshot ganz oben), der weitgehend analog zur Konfiguration von Ereignisbehandlungen funktioniert.

Beispiel

Ein einfaches Beispiel soll das Grundprinzip des Client-Workflows zeigen:
Der Inhalt eines Textfeldes soll an den Client-Workflow übergeben und verarbeitet werden. Anschließend soll die Antwort des Programms in ein zweites Textfeld zurückgeschrieben werden.

images/download/attachments/177914067/image2020-4-21_11-53-5-version-1-modificationdate-1727342509104-api-v2.png

Beim Klicken auf den "Senden" Knopf soll der Inhalt des Textfeldes "Nachricht" als Workflow-Variable "message" an den Client-Workflow übergeben werden.
Der Wert, welcher nach dem Terminieren des Workflows in der Variable "answer" steht, soll dann mit der Aktion "Wert setzen" auf das Textfeld "Antwort" geschrieben werden.

Als Workflow Programm soll einfach nur geprüft werden, ob der Wert von "message" mit dem Wort "hello" beginnt.
Wenn ja, soll "Hello as well!" und wenn nein, soll "Wrong input!" in die Variable "answer" geschrieben werden.

images/download/attachments/177914067/image2020-4-21_12-0-15-version-1-modificationdate-1727342509106-api-v2.png

Dieses sehr einfache Beispiel soll lediglich einen sehr simplen, wenn auch sinnfreien Ansatz zeigen, denn die Kombinations- und Anwendungsmöglichkeiten sind nahezu unbegrenzt und beliebig komplex.

Das Beispiel in Aktion:

Eingabe

Ausgabe

images/download/attachments/177914067/image2020-4-21_12-2-24-version-1-modificationdate-1727342509108-api-v2.png

images/download/attachments/177914067/image2020-4-21_12-2-42-version-1-modificationdate-1727342509111-api-v2.png

images/download/attachments/177914067/image2020-4-21_12-4-10-version-1-modificationdate-1727342509113-api-v2.png

images/download/attachments/177914067/image2020-4-21_12-4-31-version-1-modificationdate-1727342509115-api-v2.png


Weitere Details und Beispiele: Siehe Eigenes Aktionsevent auslösen (Formulardesigner).