Guten Morgen,
ich habe für mein Framework eine _einfache_ Workflow-Engine entwickelt. Diese basiert im Prinzip lediglich auf einer Workflow-, einer Node- und einer Thread-Klasse.
Dem Workflow werden per Konfiguration oder manuell die Knoten und ihre Reihenfolge zugewiesen. Ein "Thread" übernimmt sowohl Ausführung als auch Unterbrechen (und Speichern des aktuellen Status) als auch das wiederaufnehmen.
Wobei ich jetzt allerdings seit Tagen hänge und wo ich mir nicht sicher bin, was das beste ist, ist die Fortführung eines mehrteiligen Vorgangs mit Benutzerinteraktion, wobei auch ein Zurückspringen möglich sein soll.
Kurz zum Prinzip meines Frameworks, damit meine Ansätze unten verständlicher sind: Das Framework basiert auf HMVC-"Nodes" (Diese haben erst mal nichts mit den Workflow-Nodes zu tun), die vergleichbar mit Controller-Actions aus MVC-Frameworks sind und z. B. per URL angesprochen werden können, z. B. .../cms.page/page/1 Dies soll hier aber nicht zur Diskussion stehen.
Meine Gedanken bis jetzt (Anhand einer mehrteiligen Registrierung - Adressdaten A, Benutzerdaten B, AGB C):
Es gibt eine HMVC-Node "Start", die den Workflow startet. Dazu wird im ersten Schritt das Formular für die Adressdaten angezeigt). Die Action dieses Formulars zeigt ebenfalls auf "Start", so dass beim Abschicken erneut die Node A des Workflows aufgerufen wird. Sind die eingegebenen Daten valide, kommt Workflow-Node B, für den wieder ein Formular für die entsprechenden Daten angezeigt wird. Darauf hin folgt wieder serverseitig die Validierung und ggf. der Schritt zu Workflow-Node C.
Etwas einfacher dargestellt (Workflow-Node: "WN"):
1. Anzeige WN A
2. Verarbeitung Daten in WN A
3. Bei korrekten Daten weiter zu 4. ansonsten zurück zu 1.
4. Anzeige WN B
5. Verarbeitung Daten in WN B
...
Jetzt stehe ich erst mal prinzipiell vor der Entscheidung, wie der Status des Workflows aufrecht erhalten werden sollte: per URL oder serverseitig (z. B. per DB oder Session).
Vorteil URL:
- Man kann per History zurück gehen
- Man kann leichter einen "Abbruch"-Mechanismus implementieren
Nachteil URL:
- Vielleicht kommt es zu Integritätsproblemen innerhalb des Workflows, wenn man nicht aufpasst
Vorteil serverseitig:
- Man hat die volle Kontrolle über den Ablauf
- Man kann z. B. per Ajax leichter mit dem Client kommunizieren
Nachteil serverseitig:
- Man kann nur schlecht einen Abbruch-Mechanismus implementieren
- Der User kann nicht "Zurück" zum vorher gehenden Schritt gehen.
Dazu sei noch gesagt, dass die Workflow-Nodes eine Art Verify-Mechanismus implementieren können, mit dem sie prüfen, ob sie anhand des vorhandenen Workflow-Zustandes überhaupt ausgeführt werden dürfen.
Das sind die beiden Möglichkeiten, die mir bis jetzt in den Sinn gekommen sind. Was haltet ihr für den besseren Weg? Vielleicht hat ja noch jemand eine ganz andere Idee...
ich habe für mein Framework eine _einfache_ Workflow-Engine entwickelt. Diese basiert im Prinzip lediglich auf einer Workflow-, einer Node- und einer Thread-Klasse.
Dem Workflow werden per Konfiguration oder manuell die Knoten und ihre Reihenfolge zugewiesen. Ein "Thread" übernimmt sowohl Ausführung als auch Unterbrechen (und Speichern des aktuellen Status) als auch das wiederaufnehmen.
Wobei ich jetzt allerdings seit Tagen hänge und wo ich mir nicht sicher bin, was das beste ist, ist die Fortführung eines mehrteiligen Vorgangs mit Benutzerinteraktion, wobei auch ein Zurückspringen möglich sein soll.
Kurz zum Prinzip meines Frameworks, damit meine Ansätze unten verständlicher sind: Das Framework basiert auf HMVC-"Nodes" (Diese haben erst mal nichts mit den Workflow-Nodes zu tun), die vergleichbar mit Controller-Actions aus MVC-Frameworks sind und z. B. per URL angesprochen werden können, z. B. .../cms.page/page/1 Dies soll hier aber nicht zur Diskussion stehen.
Meine Gedanken bis jetzt (Anhand einer mehrteiligen Registrierung - Adressdaten A, Benutzerdaten B, AGB C):
Es gibt eine HMVC-Node "Start", die den Workflow startet. Dazu wird im ersten Schritt das Formular für die Adressdaten angezeigt). Die Action dieses Formulars zeigt ebenfalls auf "Start", so dass beim Abschicken erneut die Node A des Workflows aufgerufen wird. Sind die eingegebenen Daten valide, kommt Workflow-Node B, für den wieder ein Formular für die entsprechenden Daten angezeigt wird. Darauf hin folgt wieder serverseitig die Validierung und ggf. der Schritt zu Workflow-Node C.
Etwas einfacher dargestellt (Workflow-Node: "WN"):
1. Anzeige WN A
2. Verarbeitung Daten in WN A
3. Bei korrekten Daten weiter zu 4. ansonsten zurück zu 1.
4. Anzeige WN B
5. Verarbeitung Daten in WN B
...
Jetzt stehe ich erst mal prinzipiell vor der Entscheidung, wie der Status des Workflows aufrecht erhalten werden sollte: per URL oder serverseitig (z. B. per DB oder Session).
Vorteil URL:
- Man kann per History zurück gehen
- Man kann leichter einen "Abbruch"-Mechanismus implementieren
Nachteil URL:
- Vielleicht kommt es zu Integritätsproblemen innerhalb des Workflows, wenn man nicht aufpasst
Vorteil serverseitig:
- Man hat die volle Kontrolle über den Ablauf
- Man kann z. B. per Ajax leichter mit dem Client kommunizieren
Nachteil serverseitig:
- Man kann nur schlecht einen Abbruch-Mechanismus implementieren
- Der User kann nicht "Zurück" zum vorher gehenden Schritt gehen.
Dazu sei noch gesagt, dass die Workflow-Nodes eine Art Verify-Mechanismus implementieren können, mit dem sie prüfen, ob sie anhand des vorhandenen Workflow-Zustandes überhaupt ausgeführt werden dürfen.
Das sind die beiden Möglichkeiten, die mir bis jetzt in den Sinn gekommen sind. Was haltet ihr für den besseren Weg? Vielleicht hat ja noch jemand eine ganz andere Idee...
Kommentar