Eine Automatisierung kann an einen Punkt gelangen, an dem sie ohne eine Entscheidung, eine Information oder eine Prüfung nicht fortfahren sollte. Beispielsweise kann vor der Bestätigung eines sensiblen Vorgangs eine Genehmigung erforderlich sein oder es werden Informationen benötigt, die nur eine Person bereitstellen kann. In solchen Fällen muss das System einen wiederherstellbaren Zustand bewahren und erklären, was noch fehlt, statt lediglich die aktuelle Ausführung anzuhalten.
Eine PHP-Automatisierung so zu gestalten, dass sie pausiert und fortgesetzt werden kann, bedeutet, den Prozesszustand von der Ausführung der Arbeit zu trennen. Die Pause muss beabsichtigt, dauerhaft gespeichert und nachvollziehbar sein; beim Fortsetzen muss geprüft werden, ob der Prozess noch gültig ist und bereits ausgeführte Effekte nicht wiederholt werden. Das unterscheidet sich vom Entwurf einer Prüfwarteschlange: Hier stehen der Lebenszyklus des Workflows und seine sichere Fortsetzung im Mittelpunkt.
Eine Pause von einem Warten oder Fehler unterscheiden
Nicht jeder Prozess, der nicht vorankommt, ist pausiert. Ein API-Aufruf, auf dessen Antwort noch gewartet wird, ist ein externes Warten. Ein Netzwerkfehler kann einen erneuten Versuch rechtfertigen. Eine nicht behebbare Ausnahme kann den Prozess als fehlgeschlagen beenden. Eine absichtliche Pause bedeutet dagegen, dass der Workflow eine bekannte Grenze erreicht hat und eine ausdrückliche Bedingung erfüllen muss, bevor er fortgesetzt oder beendet werden kann.
Unterschiedliche Zustände für jede Situation verhindern falsche operative Entscheidungen. Eine Aktion erneut auszuführen, während sie auf eine Genehmigung wartet, kann eine unnötige Anfrage wiederholen; eine legitime Pause als Fehler zu behandeln, kann unpassende Warnmeldungen oder Wiederherstellungsrichtlinien auslösen. Definiere mindestens getrennte Zustände für Ausführung, externes Warten, erforderliche Intervention, abgeschlossen, abgebrochen und fehlgeschlagen. Füge einen Ablaufzeitpunkt hinzu, wenn eine Pause laut Geschäftsanforderungen nach einer bestimmten Frist nicht mehr gültig sein soll.
Lege vor der Einführung einer Pause fest, wodurch sie ausgelöst wird und wer sie auflösen darf. Eine ausstehende Aufgabe, die automatisch abgeschlossen wird, sobald eine Antwort eintrifft, erfordert nicht immer menschliches Eingreifen. Eine Entscheidung mit wirtschaftlichen, rechtlichen oder sicherheitsrelevanten Auswirkungen oder Folgen für Zugriffsrechte kann dies hingegen erfordern. Diese Unterscheidung bestimmt, wer handeln darf, welche Nachweise gespeichert werden und was geschieht, wenn niemand antwortet.
Zustand und Fortsetzungspunkt dauerhaft speichern
Der Prozess muss das Ende einer PHP-Anfrage, den Neustart eines Workers und eine neue Version des Dienstes überstehen. Speichere dauerhaft eine stabile ID, den aktuellen Zustand, den erreichten Schritt, den Grund für die Pause, Verweise auf die benötigten Daten und relevante Zeitstempel. Halte gegebenenfalls auch fest, wer den Prozess pausiert oder aufgelöst hat und welche Entscheidung getroffen wurde.
Vermeide es, lediglich eine Meldung wie „Genehmigung ausstehend“ zu speichern. Sie verrät weder, welche Ausführung angehalten wurde, noch, welcher Schritt fortgesetzt werden soll oder ob sich die Daten geändert haben. Bilde die Pause stattdessen als Teil des Prozessmodells ab und speichere genügend Kontext, um die Fortsetzung zu validieren. Bewahre nach Möglichkeit Verweise auf sensible Informationen auf, statt Daten unnötig zu duplizieren, und wende Zugriffskontrollen sowie Aufbewahrungsregeln an, die ihrer Art entsprechen.
Definiere zulässige Zustandsübergänge und überprüfe sie serverseitig. Ein Prozess im Zustand „Intervention erforderlich“ kann beispielsweise in „Ausführung“, „Abgebrochen“ oder „Abgelaufen“ übergehen; ein abgeschlossener Prozess sollte nicht über eine gewöhnliche Anfrage wieder in die Ausführung wechseln können. Eine PHP-Funktion kann den Übergang validieren, doch die Regel muss auch bei gleichzeitigen Zugriffen in der Datenbank abgesichert sein und darf nicht nur in der Benutzeroberfläche gelten.
Prozessdatensatz und Ausführung trennen
Zu speichern, dass ein Prozess fortgesetzt werden soll, und seine Schritte auszuführen, sind miteinander verbundene, aber nicht identische Vorgänge. Wird der Zustand aktualisiert und der Prozess beendet, bevor die Arbeit beginnt, kann der Workflow stecken bleiben. Beginnt die Arbeit, bevor der Übergang gespeichert wurde, kann eine Wiederholung denselben Schritt erneut ausführen. Gestalte die Koordination so, dass der gespeicherte Zustand die Wiederherstellung ausstehender Arbeit ermöglicht.
Eine gängige Möglichkeit besteht darin, den Zustandsübergang und einen Fortsetzungsauftrag in derselben Datenbanktransaktion zu speichern, etwa mit einem Transactional-Outbox-Muster. Ein separater Worker liest den Auftrag und führt den nächsten Schritt aus. Die konkrete Auswahl hängt von der Architektur ab. Entscheidend ist, dass das System nicht verarbeitete Arbeit erkennen und wiederherstellen kann, statt darauf zu vertrauen, dass eine Webanfrage aktiv bleibt.
Externe Effekte erfordern besondere Aufmerksamkeit. Eine lokale Transaktion kann eine gesendete E-Mail, eine bestätigte Abbuchung oder einen von einem anderen Dienst bereits angenommenen Aufruf nicht selbst rückgängig machen. Gestalte jeden Schritt mit einem Idempotenzschlüssel, sofern das Zielsystem dies unterstützt, protokolliere das Ergebnis vor dem Fortfahren und berücksichtige Abgleich oder Kompensation, wenn ein Vorgang nicht sicher wiederholt werden kann. Markiere einen Schritt nicht als abgeschlossen, bevor sein Ergebnis bekannt ist.
Fortsetzen, Abbrechen und Ablaufen kontrollieren
Beim Fortsetzen müssen der aktuelle Zustand, die Identität und Berechtigungen der anfragenden Person sowie die Erfüllung der erforderlichen Bedingungen geprüft werden. Es reicht nicht, einer berechtigten Person eine Schaltfläche anzuzeigen: Der Server muss beim Eingang der Anfrage alles erneut validieren. Erfordert die Entscheidung eine Begründung oder zusätzliche Angaben, validiere diese und speichere sie als Teil der Auflösung.
Behandle auch Abbruch und Ablauf als ausdrückliche Zustandsübergänge und nicht als Löschung des Datensatzes. Ein Abbruch muss weitere Schritte verhindern und klarstellen, ob frühere Effekte vorhanden sind, die sich nicht rückgängig machen lassen. Für den Ablauf muss festgelegt werden, was danach geschieht: den Prozess beenden, erneut eine Intervention anfordern oder den Fall einer anderen Maßnahme zuführen. Das Verhalten richtet sich nach der Geschäftsregel und muss für den operativen Betrieb sichtbar sein.
Wiederholte Anfragen und Race Conditions sind normal: Eine Person kann doppelt klicken oder zwei Akteure können nahezu gleichzeitig handeln. Verwende eine bedingte Aktualisierung, eine Sperre oder eine Versionsprüfung, damit nur ein gültiger Übergang ausgeführt wird. Eine zweite Anfrage muss ein Ergebnis erhalten, das zum aktuellen Zustand passt, ohne die Effekte erneut auszuführen. Speichere eine Vorgangs-ID oder einen Idempotenzschlüssel, um Wiederholungen zu erkennen.
Pausen verständlich und überprüfbar gestalten
Die operative Ansicht sollte erklären, warum der Prozess angehalten wurde, welcher Schritt aussteht, welche Informationen fehlen, wer handeln darf und welche Folgen die einzelnen Optionen haben. Vermeide mehrdeutige Schaltflächen oder Aktionen, die Genehmigung, Datenkorrektur und Fortsetzung miteinander vermischen. Zeige nur die für die Entscheidung erforderlichen Informationen an und beschränke den Zugriff entsprechend der Rolle. Ein Verlauf der Zustandsübergänge hilft dabei, legitimes Warten von einem blockierten oder falsch konfigurierten Prozess zu unterscheiden.
Teste den Workflow mit Unterbrechungen vor und nach jedem externen Effekt. Prüfe, ob ein Neustart die Pause erhält, wiederholtes Fortsetzen keine Aktionen dupliziert und ein Abbruch nachfolgende Schritte verhindert. Beziehe Fälle mit während der Unterbrechung geänderten Daten, widerrufenen Berechtigungen, Ablauf, verspäteten Antworten und zwei gleichzeitigen Anfragen ein. Überprüfe auch Protokolle und Warnmeldungen: Sie müssen das Auffinden des Prozesses ermöglichen und den nächsten Schritt verständlich machen, ohne Geheimnisse offenzulegen.
Checkliste zur Festlegung des Verhaltens
- Warten: Eine externe Antwort steht noch aus, und das System kann automatisch fortfahren, sobald sie eintrifft; Zeitlimits und Wiederherstellung sind festgelegt.
- Für eine Intervention pausieren: Vor weiteren Schritten ist eine ausdrückliche menschliche Entscheidung oder Information erforderlich.
- Erneut versuchen: Es ist ein vorübergehender Fehler aufgetreten, und die Wiederholung des Schritts ist sicher oder durch Idempotenz abgesichert.
- Beenden: Es gibt keine gültige Fortsetzung, oder der Prozess wurde abgeschlossen, abgebrochen, ist abgelaufen oder endgültig fehlgeschlagen.
Bestätige vor dem Deployment des Workflows, dass jeder Übergang autorisiert ist, der Zustand dauerhaft gespeichert wird, frühere Effekte nicht wiederholt werden und das Team weiß, wie es die Pause auflösen kann. Wenn du nicht beantworten kannst, was mit welchen Daten und unter welchen Bedingungen fortgesetzt wird, hat der Prozess noch keinen sicheren Fortsetzungspunkt.
