Flows sind mÀchtig. Ich kann mir einfache Benachrichtigungsflows bauen, aber auch komplexe Prozesse erstellen, die mir im Minutenzyklus aus mehreren Systemen Daten aggregieren und selbst aus mehreren Teilflows bestehen.
Wie behalte ich aber einen Ăberblick ĂŒber alle meine Flow-LĂ€ufe? Ich meine das hier nicht technisch. Dass ein einzelner Flow auf einen Fehler lĂ€uft ist leicht zu erkennen. Was ist aber, wenn ein Flow, der hĂ€tte laufen sollen, nicht gelaufen ist?
WEnn ich mit einem komplexen Geflecht von Workflows zu tun habe, erstelle ich mir normalerweise noch zusĂ€tzlich ein paar Listen im Dataverse, in denen ich dann zusĂ€tzliche Informationen zu FlowlĂ€ufen hinterlege. Das sind normalerweise die drei Tabellen âProcess-Runsâ,âSub-Process-Runsâ,âProcess-Messagesâ.
In der Tabelle âProcess-Runsâ hinterlege ich beim Start der Hauptprozesses alle relevanten Informationen
| Spalte | Beschreibung |
|---|---|
| Process-Name | Der Name des Prozesses, der angestoĂen wurde |
| Process-Params | Die Relevanten Parameter, die dem Prozess ĂŒbergeben wurden |
| Process-Run-ID | Eine beim Start zufÀllig erzeugte guid |
| Process-Start | Der Zeitpunkt, an dem der Flow gestartet wurde |
| Process-End | Der Zeitpunkt, an dem der Flow beendet wurde |
| Process-LastModified | Der Zeitpunkt, an dem aus dem Flow das letzte Mal eine Aktualisierung an diese Liste geschrieben wurde |
| Process-State | Ein TextFeld, welches von innerhalb des Prozesses aktualisiert wird und mit den aktuellen Status anzeigt (z.B. âInitialisierungâ,âDatenanlagephaseâ,âEndeâ etc.) |
In diese Liste schreibe ich nun einen neuen Eintrag, sobald der Hauptprozess gestartet wurde und setzte den Status und das Start_Datum. Wann immer der Flow eine bestimmte Phase durchlaufen hat, aktualisiere ich diesen Eintrag in der Tabelle, bis der Flow beendet ist.
Damit habe ich schon mal eine gute Grundlage zur Dokumentation und Ăberwachung meines Flows. Mittels dieser Tabelle kann ich nun recht einfach erkennen, ob ein Flow gestartet wurde und sich nicht innerhalb einer halbwegs erwarteten Zeit wieder beendet hat. Das kann ich zum Beispiel durch einen weiteren Flow ĂŒberprĂŒfen lassen, den ich zeitgesteuert regelmĂ€ssig ausfĂŒhre.
Manchmal macht es Sinn, einzelne Blöcke eines Flows in Child-Flows auszulagern. Oder wir iterieren in einer SchleiĂe ĂŒber viele Elemente und wollen jeden einzelnen Schleifenablauf einzeln dokumentieren. Dazu benutze ich dann die Tabelle âSub-Process-Runsâ
| Spalte | Beschreibung |
|---|---|
| Sub-Process-Name | Der Name des Prozesses, der angestoĂen wurde |
| Sub-Process-Params | Die Relevanten Parameter, die dem Prozess ĂŒbergeben wurden |
| Process-Run-ID | Die Guid des ĂŒbergeordneten Flows |
| Process-State | Der Status des ĂŒbergeordneten Flows, zu dem dieser Childflow gehört |
| Sub-Process-Run-ID | Eine beim Start zufÀllig erzeugte guid |
| Sub-Process-Start | Der Zeitpunkt, an dem der Flow gestartet wurde |
| Sub-Process-End | Der Zeitpunkt, an dem der Flow beendet wurde |
| Sub-Process-LastModified | Der Zeitpunkt, an dem aus dem Flow das letzte Mal eine Aktualisierung an diese Liste geschrieben wurde |
| Sub-Process-State | Ein TextFeld, welches von innerhalb des Prozesses aktualisiert wird und mit den aktuellen Status anzeigt (z.B. âInitialisierungâ,âDatenanlagephaseâ,âEndeâ etc.) |
Die Tabelle ist analog zur âProcess-Runâ Tabelle aufgebaut. Hier ist nur das Feld âProcess-Run-IDâ zusĂ€tzlich vorhanden, mit dem ich auf den aufrufenden Flow in der âProcess-Runâ Tabelle verweise.
Wenn ich nun einen Childflow starte oder in einer Schleife Elemente bearbeite, erstelle ich immer einen Eintrag in dieser Tabelle und setzte entsprechend Statuswerte und Zeitstempel um, wenn es erforderlich wird.
SchlieĂlich erstelle ich noch die letzte Tabelle âProcess-Messagesâ
| Spalte | Beschreibung |
|---|---|
| Process-Run-ID | Die Guid des ĂŒbergeordneten Flows |
| Sub-Process-Run-ID | Die Guid des ĂŒbergeordneten Child Flows (leer, wenn die Nachricht aus dem Hauptflow geschrieben wird) |
| Process-Message-Date | Der Zeitpunkt, an dem die Nachricht geschrieben wurde |
| Process-Message-Type | Der Typ der Nachricht, zum Beispiel âPROCESSING_ITEMâ |
| Process-Message-Params | Die Parameter der Nachricht, zum Beispiel eine Item ID |
In diese Liste schreibe ich nun Nachrichten, wenn ich bestimmte Phasen in meinen Workflows durchlaufe. Im Prinzip resultiert das ganze dann in einer Log-Datei ĂŒber mehrere Flow Aufrufe nur fĂŒr meinen aktuellen Process-Run.
Die ganzen Daten stehen dann als Werte im Dataverse und ich könnte Sie da auswerten. Das ist aber ein wenig mĂŒhselig, weswegen ich mir normalerweise nun eine kleine PowerApp baue, in der ich mir die Daten visualisiere.
ZunĂ€chst erstelle ich einen Screen, in auf dem ich alle âProcess-Runsâ zu einem komplexen Workflow darstelle:
Wenn ich auf einen konkreten Run klicke gelange ich auf einen Detailscreen zu diesem Run. Darauf stelle ich von links nach rechts alle möglichen Phasen des Workflows dar. Zu jeder Phase liste ich die durchlaufenden Childflows aus der Tabelle âSub-Process-Runsâ zu diesem Flow auf.
Ăber einen Klick auf einen der Pfleile nach rechts gelangt man auf eine Ansicht, in der ich alle Log-EintrĂ€ge aus der Tabelle âProcess-Messagesâ darstelle.
Ăber diese App kann ich mir nun einfach den Status meines Workflows live anzeigen.