Workflow Engine: Wie Prozessmodelle kontrolliert ausgeführt werden

Was eine Workflow Engine ist

Die Engine ist damit nicht der Workflow selbst. Workflow-Modelle beschreiben Aktivitäten, Reihenfolgen, Verzweigungen und Abschlussbedingungen. Die Workflow Engine setzt eine solche Definition zur Laufzeit um und verwaltet den Zustand jedes konkreten Vorgangs.

Bei einer Produktionscharge können gleichzeitig viele Instanzen desselben freigegebenen Modells aktiv sein. Jede Instanz besitzt eigene Daten, Fristen, Aufgaben und Zustände. Eine Charge wartet auf ein Prüfergebnis, eine andere benötigt Nacharbeit, eine dritte ist bereits freigegeben. Die Engine hält diese Ausführungen getrennt und führt sie nach derselben versionierten Definition weiter.

Aus einer Definition entstehen viele Prozessinstanzen

Eine Prozessdefinition ist eine Vorlage. Erst ein fachlicher Auslöser erzeugt daraus eine Instanz: eine neue Charge, eine Abweichung, eine Materialprüfung oder ein Freigabeantrag. Die Instanz erhält eine eindeutige Identität und wird mit den betroffenen Objekten verbunden.

Die Workflow Engine speichert, welche Schritte abgeschlossen sind, welche parallel laufen, welche Daten vorliegen und worauf der Prozess wartet. Bei einem Neustart darf dieser Zustand nicht verloren gehen. Lang laufende Abläufe können Tage oder Monate dauern und technische Unterbrechungen überstehen.

Instanzdaten und fachliche Objektdaten sollten unterscheidbar bleiben. „Aufgabe Prüfung offen“ beschreibt den Ausführungszustand. Das Messergebnis, die geprüfte Charge und die verantwortliche Person sind fachliche Daten. Die Engine koordiniert deren Verarbeitung, ist aber nicht automatisch das führende System für jeden Datentyp.

Wartende Instanzen gezielt fortsetzen

Eine Instanz kann über Stunden auf einen Befund warten. Dafür müssen ihr Wartezustand, der erwartete Nachrichtentyp und die Zuordnungsmerkmale gespeichert sein. Eine offene Netzwerkverbindung ist kein Ersatz für diesen dauerhaften Zustand.

Die Chargen-ID allein reicht nicht immer: Zur selben Charge können mehrere Untersuchungsaufträge bestehen. Die Zuordnung muss den konkreten Auftrag und die erwartete Antwort unterscheiden. WS-BPEL verwendet dafür Korrelationsmengen aus Nachrichteneigenschaften.^[3]

Nach erfolgreicher Zuordnung ist gesondert zu prüfen, ob die Antwort im aktuellen Zustand noch erwartet wird. Ein verspätetes Ergebnis kann zu einem bereits abgebrochenen Auftrag gehören. Eine zweite Zustellung derselben Nachricht darf keine zweite fachliche Wirkung erzeugen. Zustandsprüfung, Speicherung und Umgang mit Wiederholungen müssen zusammenpassen.

Eine Antwort trifft nach dem Neustart zweimal ein

Im folgenden fiktiven Laufzeitbeispiel wartet Instanz P-17 auf den Laborauftrag L-08. Gespeichert sind die angewendete Modellversion, der Wartezustand und die Auftragskennung. Ein Serverneustart beendet zwar den ausführenden Programmprozess; die betriebliche Instanz muss anschließend aus ihrem gespeicherten Stand weitergeführt werden können.

Die Antwort R-52 nennt L-08. Die Laufzeit ordnet sie P-17 zu, prüft den noch offenen Empfang und speichert die Verarbeitung einschließlich des daraus folgenden Übergangs. Erst die Prozessdefinition entscheidet, ob das Ergebnis eine weitere Bewertung oder den nächsten Arbeitsschritt auslöst.

Wird R-52 erneut zugestellt, ist sie als bereits verarbeitet zu erkennen. Das ist ein anderer Fall als ein korrigierter Befund mit neuer Identität. Dieser kann eine fachliche Neubewertung verlangen und darf nicht lediglich als Duplikat verworfen werden.

Das Beispiel beschreibt ein Entwurfsziel. Ob ein konkretes System es erreicht, ist mit Neustart-, Doppelzustellungs- und Fehlerfällen zu prüfen. Insbesondere ein Absturz zwischen externer Buchung und interner Bestätigung erfordert eine abgestimmte Behandlung in beiden beteiligten Komponenten. Bei der Auswahl von Compliance-Software sollten solche Wiederanlauf- und Doppelzustellungsfälle Teil der Produktdemo sein, damit die beobachtete Wirkung mit den betrieblichen Anforderungen verglichen werden kann.

Fehler, Wiederholungen und Kompensation benötigen eigene Regeln

Technische Aufrufe können fehlschlagen oder mehrfach bestätigt werden. Eine Engine muss unterscheiden, ob ein Schritt sicher wiederholt werden darf, ob ein manueller Eingriff nötig ist oder ob eine bereits ausgeführte Wirkung kompensiert werden muss.

Idempotente Operationen erzeugen bei einer Wiederholung nicht versehentlich eine zweite fachliche Wirkung. Eine erneut zugestellte Nachricht darf beispielsweise nicht zwei Materialbuchungen erzeugen. Dafür benötigt der aufgerufene Dienst eine eindeutige Vorgangskennung und eine kontrollierte Behandlung bereits verarbeiteter Befehle.

Eine Kompensation ist kein technisches Zurückdrehen der Zeit. Wurde Material physisch verbraucht oder eine Entscheidung kommuniziert, kann der frühere Zustand häufig nicht einfach wiederhergestellt werden. Der Prozess benötigt dann einen ausdrücklichen Gegen- oder Korrekturvorgang.

Laufende Instanzen und neue Modellversionen müssen zusammenpassen

Wird eine Prozessdefinition geändert, stellt sich die Frage, was mit bereits laufenden Instanzen geschieht. Eine neue Version kann nur für künftig gestartete Vorgänge gelten. Alternativ können ausgewählte Instanzen migriert werden, wenn Ausgangs- und Zielzustand eindeutig aufeinander abbildbar sind.

Eine unkontrollierte Umschaltung kann dazu führen, dass erwartete Schritte verschwinden, neue Pflichten ohne passenden Ausgangszustand entstehen oder bereits ausgeführte Aktivitäten nochmals aktiviert werden. Jede Migration benötigt daher Regeln, Prüfungen und eine dokumentierte Entscheidung.

Zur späteren Auswertung muss erkennbar bleiben, unter welcher Definition eine Instanz begonnen und welche Version tatsächlich auf sie angewendet wurde. Erst dann lassen sich unterschiedliche Ausführungswege und Ergebnisse korrekt einordnen.

Bei der Einführung von Workflow-Software ist neben der technischen Migration die betriebliche Umstellung zu organisieren: Wer übernimmt offene Vorgänge, und wie werden Alt- und Neusystem abgeglichen?

Ausführbare Modelle benötigen eindeutige Semantik

Eine anschauliche Prozessgrafik genügt nicht. Die Engine muss eindeutig bestimmen können, wann ein Schritt aktiviert wird, wie Verzweigungen ausgewertet werden und wann parallele Pfade wieder zusammenlaufen. Ereignisse, Timer, Fehler und Endzustände benötigen ebenfalls definierte Bedeutung.

BPMN 2.0.2 definiert innerhalb der Prozessmodellierung die Konformitätsunterklassen Descriptive, Analytic und Common Executable. Sie beschreiben unterschiedliche Umfänge unterstützter Modellelemente und Attribute. Die Spezifikation legt außerdem Ausführungssemantik fest, unter anderem für Aktivitäten, Ereignisse, Gateways und Sequenzflüsse.^[2]

Nicht jedes formal gültige Modell ist betrieblich gut ausführbar. Sehr komplexe Verzweigungen, unklare Abbruchbedingungen oder versteckte Seiteneffekte erschweren Prüfung und Wartung. Die Definition sollte deshalb so präzise wie nötig und so verständlich wie möglich bleiben.

Orchestrierung verbindet menschliche und technische Arbeit

Eine Workflow Engine kann unterschiedliche Arbeitstypen koordinieren. Menschliche Aufgaben werden einer Rolle oder Person angeboten. Service-Aufgaben rufen Anwendungen auf. Nachrichten warten auf ein externes Ereignis. Timer setzen Fristen oder lösen Eskalationen aus. Regeln wählen einen zulässigen Pfad.

Weske unterscheidet in der Workflow-Architektur zwischen System-Workflows und Human-Interaction-Workflows. Bei System-Workflows ruft die Engine die im Modell vorgesehenen Anwendungen auf. Bei Human-Interaction-Workflows verbindet dieselbe Laufzeit automatisch aufgerufene Anwendungen mit menschlichen Interaktionen; organisatorische Informationen wie Verfügbarkeit und Eignung können dabei für die Zuweisung von Arbeit genutzt werden.^[6]

Bei der Orchestrierung bestimmt eine zentrale Prozessinstanz, welche Interaktion als Nächstes erwartet wird. WS-BPEL beschreibt beispielsweise ausführbare Geschäftsprozesse, die Webservice-Interaktionen zu einer zustandsbehafteten Prozesslogik verbinden.^[3] Das unterscheidet Orchestrierung von einer bloßen Folge unabhängiger API-Aufrufe.

Technische Automatisierung und menschliche Verantwortung bleiben dabei trennbar. Die Engine kann Daten vorbereiten, Zuständigkeiten prüfen und den nächsten Schritt anbieten. Eine fachliche Prüfung oder Freigabe wird dadurch nicht automatisch zu einer Maschinenentscheidung.

Aufgabenstatus und Prozessfortsetzung verbinden

Die Engine muss erkennen, ob eine erwartete menschliche Aufgabe ein verwertbares Ergebnis geliefert hat, fehlgeschlagen ist oder zurückgezogen wurde. Übernahme und Delegation gehören zum Aufgabenlebenszyklus, wie ihn etwa WS-HumanTask beschreibt.^[4] Für die Laufzeit ist entscheidend, welcher dieser Zustände einen Übergang erlaubt.

Digitale Arbeitsanweisungen können die Durchführung unterstützen. Die Bestätigung ihres letzten Schritts setzt die Prozessinstanz aber nur dann fort, wenn der vereinbarte Ergebnistyp und die zugehörigen Voraussetzungen erfüllt sind. Ein geschlossenes Browserfenster liefert kein solches Ergebnis.

Entscheidungslogik und Prozesssteuerung sind nicht dasselbe

Gateways und Bedingungen wählen zwischen modellierten Pfaden. Eine einfache Bedingung kann lauten: Wenn die Messung innerhalb des freigegebenen Bereichs liegt, folgt die Dokumentationsprüfung; andernfalls entsteht eine fachliche Bewertung.

Komplexe Entscheidungsregeln sollten nicht unkontrolliert im Prozessdiagramm verborgen werden. Sie können als versionierte Entscheidungstabellen oder getrennte Regelmodelle gepflegt werden. Die Engine ruft die Entscheidung auf, speichert Eingaben und Ergebnis und setzt anschließend den ausgewählten Pfad fort.

Die technische Auswertung einer Bedingung ersetzt nicht die fachliche Entscheidung, wenn diese einem Menschen zugewiesen ist. Bei Human in the Loop muss die Engine deshalb das Ergebnis der vorgesehenen Prüfung oder Freigabe berücksichtigen, bevor sie den davon abhängigen Schritt fortsetzt.

Ausführungszustand und Prozesshistorie erfüllen verschiedene Zwecke

Die Engine benötigt einen aktuellen Zustand, um den nächsten Schritt zu bestimmen. Für Nachvollziehbarkeit reicht dieser Zustand allein nicht aus. Ebenso wichtig ist die Historie: wann eine Instanz gestartet wurde, welche Aufgabe wem angeboten war, welches Ergebnis einging und warum ein Pfad gewählt wurde.

Event Sourcing ist ein mögliches Architekturprinzip, bei dem Zustände aus gespeicherten Ereignissen abgeleitet werden. Eine Workflow Engine muss jedoch nicht zwingend vollständig event-sourced implementiert sein. Entscheidend ist, dass fachlich relevante Vorgänge nachvollziehbar erhalten bleiben und technische Laufzeitdaten nicht mit einem vollständigen Auditnachweis verwechselt werden.

Protokolle der Engine können technische Details enthalten, aber fachliche Begründungen auslassen. Umgekehrt gehört nicht jede interne Wiederholung eines technischen Aufrufs in die fachliche Prozesshistorie. Beide Ebenen benötigen eine klare Zuordnung.

Die Laufzeit hat eine andere Aufgabe als der Editor

Die Trennung zwischen Modellierung und Laufzeit ist mehr als eine Oberflächenfrage. Weske unterscheidet bei Workflow-Management-Systemen zwischen Build Time und Runtime: In der Build Time wird das Workflow-Modell um die für die Ausführung nötigen technischen Informationen ergänzt. Zur Runtime entstehen daraus konkrete Workflow-Instanzen, deren Ausführung die Engine kontrolliert.^[6]

Eine Modellierungsoberfläche bearbeitet damit die Ablaufdefinition. Die Laufzeit verwaltet dagegen die bereits gestarteten Instanzen. Aufgabenclients und angebundene Fachanwendungen interagieren mit dieser Laufzeit, erfüllen aber andere Funktionen.

Diese Aufteilung ist auch im Workflow Reference Model erkennbar, das die OMG-Spezifikation zur Workflow Management Facility wiedergibt: Prozessdefinition, Ausführung, aufgerufene Anwendungen, Aufgabenclients und Administration werden unterschieden.^[5] Die historische WfMC-Fassung ist ergänzend im Literaturverzeichnis aufgeführt.

Ein Produkt kann diese Komponenten gemeinsam anbieten. Ihre gedankliche Trennung hilft, Änderungen gezielt zu bewerten. Sie verhindert jedoch nicht von selbst, dass ein Administrator fachliche Daten verändert; dafür braucht es tatsächlich durchgesetzte Rechte und nachvollziehbare Eingriffe.

Workflow Engine, Zustandsautomat und Aufgabensteuerung abgrenzen

Ein Zustandsautomat beschreibt zulässige Zustände und Übergänge eines einzelnen Objekts. Eine Workflow Engine koordiniert typischerweise mehrere Aktivitäten, Beteiligte und Objekte über einen längeren Verlauf. Sie kann intern Zustandsautomaten verwenden, ist aber nicht mit ihnen identisch.

Task Orchestration konzentriert sich enger darauf, Aufgaben abhängig von Ergebnissen zu erzeugen und weiterzuführen. Ein Approval Workflow beschreibt den spezifischen Fluss aus Prüfung, Freigabe, Ablehnung und Nacharbeit. Beide können durch eine Workflow Engine ausgeführt werden, decken aber nicht deren gesamte Laufzeitverantwortung ab.

Auch eine Warteschlange ist keine Workflow Engine. Sie transportiert oder puffert Nachrichten. Erst Prozessdefinition, Instanzzustand, Übergangslogik, Korrelation und kontrollierte Fortsetzung ergeben die Orchestrierung eines vollständigen Ablaufs.

Was eine Workflow Engine nicht allein leistet

• Sie garantiert keine Datenqualität. Eingaben, Geräteschnittstellen und Zuordnungen müssen gesondert kontrolliert werden.
• Sie erzeugt nicht automatisch Compliance. Anforderungen müssen korrekt in Prozess, Rollen und Kontrollen übersetzt sein.
• Sie ist kein vollständiges Fachsystem. Materialien, Dokumente und Stammdaten können in anderen führenden Komponenten liegen.
• Sie verhindert keine unbeherrschte Komplexität. Zu viele Sonderpfade und versteckte Regeln erschweren Betrieb und Prüfung.

Der entscheidende Test liegt in der Unterbrechung

Eine Demonstration des Normalwegs zeigt noch nicht, ob eine Engine einen langfristigen Vorgang zuverlässig fortsetzt. Aussagekräftiger sind die Unterbrechungen: ein Neustart während des Wartens, eine verspätete Antwort, eine wiederholte Zustellung oder ein Versionswechsel bei offenen Schritten.

An diesen Fällen wird sichtbar, ob gespeicherter Zustand, Nachrichtenzuordnung und Übergangslogik dieselbe Geschichte erzählen. Erst dann lässt sich erklären, weshalb eine konkrete Instanz genau an dieser Stelle weiterläuft.