Prozesse automatisieren mit iTWO Workflows

iTWO 4.0 ist eine Cloud-basierte Plattform, die Bauunternehmen dabei unterstützt, ihr Management zu digitalisieren. So ermöglicht iTWO 4.0 etwa (u. a.) die Verwaltung und Verknüpfung von Personal, Verträgen, Nachunternehmern und Maschinen. Zwecks Automatisierung von wiederkehrenden Prozessen (wie etwa dem Erstellen von Vertragsdruckvorlagen basierend auf hinterlegten Daten) können Workflows erstellt werden.

In iTWO 4.0 gibt es zwei Module, die uns beim Erstellen, Bearbeiten und Managen von Workflows unterstützen: Der Workflow Designer und die Workflow Administration. Im Workflow Designer legen wir neue Workflows an und testen (und ggf. debuggen) diese, bevor wir sie für die Verwendung durch den Endanwender (sprich über die ‚normale‘ UI) freigeben. Die Verwaltung der ausgeführten Workflows erfolgt im zweiten Modul, der Workflow Administration, welches in einem gesonderten Eintrag betrachtet wird. In diesem Teil schauen wir uns Aufbau des Workflow-Designers und verfügbare Funktionen an. In der Standardkonfiguration befindet sich das Modul “Workflow Designer” auf der zweiten Seite des Arbeitsbereichs in der Gruppe “Administration”. Alternativ kann das Modul auch über den Schnellstart geöffnet werden.

Hinweis: Die folgende Beschreibung bezieht sich auf iTWO in der Spracheinstellung ‚Englisch‘.

Die Ansicht kann über „Edit Views“  (Klick auf 3-Punkte-Icon‘) angepasst werden. Wir empfehlen eine Ansicht mit 4 Bereichen: 3 horizontal ausgerichtete Container und an der rechten Seite der Debug-Container, der die gesamte Höhe des Bildschirms ausnutzt. Im linken Bereich befinden sich die übrigen 3 Container: Oben link der Container Workflow  /Workflow Templates: Dieser Container zeigt – im Reiter Workflow Templates  - alle verfügbaren Workflows Templates (WFs) bzw. sämtliche Versionen des ausgewählten Templates (Reiter Workflow Templates Versions) sowie verknüpfte, übergeordnete Events (Reiter Subscribed Events). Subscribed Events werden wir in einem zukünftigen Beitrag betrachten. Jeder WF verfügt unter anderem über eine ID, die automatisch vergeben wird, ein Beschreibungsfeld (Description) zur möglichst präzisen Aufgabenbeschreibung des WFs sowie ein Entity Feld (für die ggf. zugeordnete Tabelle in der Datenbank). Die weiteren Felder ignorieren wir. Die Entity beeinflusst, welche Informationen mit dem Workflow Start automatisch abgerufen werden. Diese Informationen werden uns in der Debugging Konsole – im Container Debug – angezeigt und werden als „Context“ bezeichnet.

Zu jedem WF können Versionen angelegt werden. Diese erreichen wir über den Reiter ‚Workflow Templates Versions‘. ID und Version werden automatisch erzeugt. Das Feld ‚Lifetime‘ ignorieren wir. In den Felder ‚Comment‘ und ‚Help Text‘ können wir Information zur WF Version angeben. Ich persönlich halte es da wie mit GIT Commit Comments – im Comment werden in englischer Sprache, im Präsens, kurz und prägnant Änderungen in Bezug auf die vorherige Version beschrieben. Eine WF Version bleibt editierbar (Stift Icon links neben der ID-Spalte) bis sie durch Klicken auf ‚Change Status‘ auf AKTIV gestellt wird. Der Stift wird durch eine leuchtende Glühbirne ersetzt. Änderungen an der WF Version sind nun nicht mehr möglich, jedoch kann über ‚Copy Version‘ eine neue, editierbare Version der aktiven Variante erzeugt werden. WF Versionen können des Weiteren validiert, importiert, lokal gespeichert (exportiert) und natürlich gelöscht werden.   

Workflows (WFs) werden über das logische Verknüpfen von grafischen Codeblöcken (Actions) erstellt. Der Hersteller stellt hierzu teils vorkonfigurierte Actions bereit, unterteilt in Kategorien, z. B. für Datenbankaufrufe, zur Erstellung von interaktiven Webformularen, zum Versand von Emails oder zum logischen Verknüpfen von Actions. Eine umfangreiche Doku zu den von RIB bereitgestellten Actions erreicht man über das Fragezeichen-Icon in der Workflow Designer Ansicht unter Administration -> Workflow Designer. Beispielsweise könnte ein WF zur Erzeugung eines Vertragsdokuments erstellt werden, indem man Actions zur Erzeugung eines Webformular (im Designer: Extended User Action) und eines PDF-Dokuments (Report Action) mit Datenbank Actions (für CRUD Operationen - also zum Erstellen, Laden, Aktualisieren und ggf. Löschen) kombiniert. Für CRUD stellt der Designer diverse Actions bereit.  

Achtung: Bei der Entwicklung von Workflows empfiehlt sich die Verwendung von Testdatensätzen, da einige Actions Auswirkungen auf die in der Datenbank hinterlegten Einträge haben, wie beispielsweise das Anlegen von neuen Datensätzen oder das Überschreiben von Feldern.

Wir erstellen zunächst ein neues Workflow Template, nennen es dem Zweck entsprechend – zum Beispiel – „Cancel_SalesContract_Inform_Clerk“. Wir müssen nun die passende Entity zuweisen. Im Fall von Sales Verträgen ist dies die „OrdHeaderEntity“. Nun wechseln wir in den Reiter „Workflow Template Versions“ und fügen im „Designer“ (Container 2) zunächst die Action „Change Status“ hinzu. In „Action Parameters“ (Container 3, unten links) im Reiter „Action Parameters“ weisen wir nun ‚Object Id‘ die ID des zu stornierenden (Sales) Vertrags zu. Hier wollen wir natürlich keine ID festlegen, sondern das Ganze dynamisch gestalten. Als Wert geben wir daher eine Variable an, welche die VerstragsId enthält (also jene ID, unter welcher der Vertrag in der OrdHeaderEntity gespeichert ist). Eine solche Entity-Id wird in Workflows immer als Context.Entity.Id abgelegt. Ein als „Context“ bezeichnetes Objekt wird beim Start sämtlicher WFs angelegt. In Inputfeldern von Actions müssen Expressions immer in doppelt geschweiften Klammern „ {{}} „ angebenen werden (wie bei Variablen in HTML Templates von AngularJS auf dem der WF Designer basiert).

Wir weisen Object Id also {{Context.Entity.Id}} zu.

Unter „Status Name“ wählen wir per Dropdown Menü „ORD_HEADER – salescontract – ORD_STATUS” aus. “New Status” setzen wir auf „Storniert“. Für dieses Beispiel ignorieren wir die übrigen Optionen aber setzen unter Output Parameters „New Status“ auf Context.newStatus. So wird bei Ausführung der „Change Status“ Action die interne ID des „Storniert“ Status an Context.newStatus übergeben.

Nun speichern wir alles und fügen eine weitere Action hinzu, die „Mail Action“. Einfachheitshalber verzichten wir hier auf dynamische Werte und vergeben statische Werte für Betreff (Subject) und Emailadressen unter Input Parameters und Receivers. Etwa: „Vertrag storniert“ bei „Input Parameters -> Subject“, no-reply@mycompany.org bei „Input Parameters -> From“ und sales@mycompany.org bei „Receivers -> Key“ (hinzuzufügen über das ‚Folder +‘ Icon). Wie zuvor ignorieren wir die übrigen Params aber spezifizieren eine Output-Variable unter „Output Parameters -> Document Id“: Context.emailOut.

Wir speichern wieder und starten den Workflow: Im Debug Container klicken wir „Debug“ (Icon mit PLAY-Zeichen vor grünem Hintergrund). Nun müssen wir die Id eines Vertrags angeben, den wir stornieren möchten (Obacht: Gegebenenfalls vorher einen Testvertrag über das WebInterface anlegen). Wir beobachten im Debug Container, wie das Context Object erstellt wird und mit Daten befüllt wird. Mit dem ‚Größer als‘ (>) Button klicken wir uns durch den WF. Bei „Change Status“ wird Context.newStatus mit der StatusId befüllt. Nach Aktivierung der „Mail Action“ wird ebenso die Email(dokument)Id an Context.emailOut übergeben. Der Workflow ist durchgelaufen, hat den gewählten Vertrag auf ‚storniert‘ gesetzt und den Vertrieb (Sales Abteilung) per Email darüber informiert.