Wenn eine Änderung an Konfigurationen oder Geschäftsdaten andere Benutzer betreffen kann, muss möglicherweise eine Person die Änderung vorschlagen und eine andere sie prüfen, bevor sie wirksam wird. Einen solchen Prozess als Genehmigungsworkflow für Änderungen in einem PHP-SaaS zu entwerfen, erfordert mehr als nur eine Schaltfläche „Genehmigen“: Der Vorschlag muss vom aktuellen Datenstand getrennt, jeder Zustandsübergang geschützt und festgelegt werden, was geschieht, wenn sich der Kontext während der Wartezeit der Anfrage ändert.
Ziel ist, dass das System nachvollziehbar beantworten kann, was beantragt wurde, wer es geprüft hat, mit welchen Berechtigungen und ob es tatsächlich angewendet wurde. Die Lösung sollte dem Risiko angemessen sein: Ein unnötiger Workflow verursacht Reibung, während ein unzureichender fehlerhafte oder schwer nachvollziehbare Änderungen ermöglichen kann.
Entscheiden, welche Änderungen genehmigt werden müssen
Beginnen Sie damit, Änderungen nach Auswirkung, Umfang und Korrigierbarkeit zu klassifizieren. Nicht jeder bearbeitbare Datenwert muss geprüft werden. Ein Benutzer, der eine persönliche Einstellung mit geringen Auswirkungen ändert, kann die Änderung direkt speichern. Für die Änderung einer Abrechnungsregel, einer organisationsweit geltenden Konfiguration oder eines Stammdatums, das mehrere Prozesse beeinflusst, kann dagegen eine Genehmigung sinnvoll sein.
Legen Sie ausdrückliche Produktkriterien fest. Fragen Sie beispielsweise, ob die Änderung mehr Benutzer als die vorschlagende Person betrifft, Beträge oder Berechtigungen ändern kann, aufgrund interner Richtlinien eine zweite Person erfordert und wie aufwendig eine Korrektur wäre. Dokumentieren Sie auch Ausnahmen und wer sie ändern darf. Machen Sie die Genehmigung nicht zu einem allgemeinen Mechanismus für Vorgänge, die nicht zum Anwendungsfall gehören: Hier geht es um Änderungen an Konfigurationen oder Geschäftsdaten.
Die Entscheidung muss auf dem Server durchgesetzt werden und darf nicht nur in der Benutzeroberfläche abgebildet sein. Eine ausgeblendete Schaltfläche hindert niemanden daran, einen Endpunkt direkt aufzurufen. Die API muss ermitteln, ob die jeweilige Änderungsart genehmigungspflichtig ist, und die Regel sowohl auf einzelne Vorgänge als auch auf Massenaktionen und Integrationen anwenden, die dieselben Daten ändern können.
Anfrage und aktuellen Datenstand voneinander trennen
Überschreiben Sie beim Erstellen eines Vorschlags nicht den aktuellen Datenstand. Speichern Sie eine separate Anfrage, die mindestens die Organisation, die betroffene Ressource, die vorgeschlagenen Werte, den Status, die erstellende Person und den Erstellungszeitpunkt enthält. Je nach Produkt müssen außerdem ein Grund, die Herkunft der Anfrage, eine Frist oder eine Version der ursprünglichen Daten gespeichert werden.
Die Werte können als typisierte Felder oder als serialisierte, vom Server validierte Struktur gespeichert werden. Akzeptieren Sie in beiden Fällen keine beliebige Nutzlast, als wäre sie eine direkte Aktualisierung. Validieren Sie beim Eingang des Vorschlags das Schema, die zulässigen Felder, die Formate und die Geschäftsregeln. Validieren Sie beim Anwenden erneut, was dann noch relevant ist, da sich die Bedingungen während der Wartezeit geändert haben können.
Dieses Design ermöglicht es, den aktuellen Wert mit dem Vorschlag zu vergleichen, ohne die Erfahrung anderer Benutzer zu verändern. Außerdem kann die Prüfoberfläche einen verständlichen Unterschied anzeigen. Stellen Sie keinen Wert als aktuell dar, der lediglich aussteht; machen Sie klar erkennbar, welche Daten bereits angewendet wurden und welche nur vorgeschlagen sind.
Zustände und Übergänge ausdrücklich modellieren
Definieren Sie eine kleine Menge von Zuständen mit klarer Bedeutung. Eine gängige Abfolge kann proposed (vorgeschlagen), in_review (in Prüfung), approved (genehmigt), rejected (abgelehnt), expired (abgelaufen) und applied (angewendet) umfassen. Nicht jedes Produkt benötigt einen Prüfstatus: Wenn eine sofortige Entscheidung genügt, kann dieser entfallen. Wichtig ist, dass jeder Zustand eine operative Situation beschreibt und nicht nur ein dekoratives Label ist.
Legen Sie die zulässigen Übergänge fest. Ein Vorschlag kann beispielsweise in die Prüfung übergehen oder abgelehnt werden; eine Anfrage in Prüfung kann genehmigt oder abgelehnt werden; eine Genehmigung kann angewendet werden, sofern sie noch gültig ist. Eine abgelaufene Anfrage sollte nicht auf demselben Weg wie eine aktive genehmigt werden. Nicht zulässige Aktionen müssen stets mit einer einheitlichen Antwort fehlschlagen, auch wenn die Benutzeroberfläche diese Option nicht anbietet.
„Genehmigt“ und „angewendet“ sind nicht gleichbedeutend. Die Genehmigung dokumentiert eine Entscheidung; durch das Anwenden werden die aktuellen Daten geändert. Werden beide Schritte getrennt gehalten, lassen sich Fehler beim Anwenden erkennen und genehmigte Anfragen anzeigen, die noch bearbeitet werden müssen. Kann der Prozess innerhalb einer einzigen kurzen Transaktion abgeschlossen werden, können die Entscheidung und der Schreibvorgang aufeinander abgestimmt werden; im Modell muss dennoch erkennbar bleiben, was geschehen ist.
Berechtigungen bei jedem Übergang prüfen
Autorisieren Sie jede Aktion auf dem Server anhand von Organisation, Rolle, Ressource und aktuellem Status. Gehen Sie nicht davon aus, dass die Berechtigung zum Erstellen einer Anfrage auch das Genehmigen oder Anwenden erlaubt. Vertrauen Sie außerdem nicht auf die vom Client übermittelte Organisations-ID: Ermitteln Sie den Geltungsbereich anhand einer validierten Sitzung oder eines validierten Berechtigungsnachweises und prüfen Sie, ob Anfrage und Ressource zu demselben Geltungsbereich gehören.
Wenn eine Selbstgenehmigung untersagt ist, prüfen Sie, ob die genehmigende Person eine andere Identität hat als die Person, die den Vorschlag eingereicht hat. Diese Regel muss beim Übergang durchgesetzt werden und nicht nur in der Ansicht. Legen Sie außerdem fest, wie mit Anfragen von Administratoren, Dienstbenutzern und automatisierten Prozessen umzugehen ist; Ausnahmen erfordern eine bewusste Richtlinie und dürfen nicht durch ein versehentliches Versäumnis entstehen.
Eine Genehmigung sollte an einen konkreten Vorschlag gebunden sein. Ändert sich dessen Inhalt, ist die vorherige Genehmigung nicht mehr gültig: Erstellen Sie eine neue Version der Anfrage oder setzen Sie sie auf einen Status zurück, der eine erneute Prüfung erfordert. Werden Werte nach der Genehmigung stillschweigend geändert, geht der Zusammenhang zwischen dem geprüften und dem angewendeten Inhalt verloren.
Nebenläufigkeit, Ablauf und Anwendung verwalten
Während eine Anfrage wartet, kann ein anderer Akteur die ursprünglichen Daten ändern. Um das zu erkennen, speichern Sie beim Erstellen des Vorschlags die Version der Ressource oder die relevanten Werte. Vergleichen Sie beim Anwenden die erwartete mit der aktuellen Version. Stimmen sie nicht überein, überschreiben Sie die neue Änderung nicht ohne klare Regelung: Blockieren Sie die Anwendung, kennzeichnen Sie einen Konflikt oder verlangen Sie je nach Produktregeln eine erneute Prüfung.
In einer relationalen Datenbank kann eine Transaktion das Lesen der Anfrage, die Prüfung ihres Status und die Aktualisierung der Ressource schützen. Das konkrete Muster hängt von der Datenbank-Engine und dem Grad der Nebenläufigkeit ab; eine pessimistische Sperre oder eine bedingte Aktualisierung anhand der Version kann geeignet sein. In jedem Fall muss der Übergang atomar sein: Zwei gleichzeitige Anfragen sollten dieselbe Änderung nicht zweimal anwenden können.
Sorgen Sie dafür, dass die Anwendung idempotent ist oder Wiederholungsversuche sicher abgewiesen werden. Werden Daten in der Datenbank aktualisiert und zusätzlich eine Benachrichtigung versendet oder ein Ereignis veröffentlicht, sollten Sie erwägen, das ausstehende Ereignis in derselben Transaktion zu speichern und später zu verarbeiten. So sinkt das Risiko, eine Erfolgsbenachrichtigung für einen Schreibvorgang anzuzeigen, der nicht bestätigt wurde.
Legen Sie auch eine Ablaufregelung fest: Wie lange kann ein Vorschlag aktiv bleiben, wodurch läuft er ab und kann er verlängert werden? Der Ablauf muss beim Genehmigen und Anwenden auf dem Server geprüft werden; es genügt nicht, den Status über einen geplanten Task zu ändern. Wenn eine Verzögerung dazu führt, dass Werte oder Bedingungen nicht mehr zuverlässig sind, verlangen Sie einen neuen Vorschlag.
Den Workflow auditieren und betreiben
Bewahren Sie für jede Änderung einen Datensatz darüber auf, wer sie vorgeschlagen, genehmigt, abgelehnt und angewendet hat, einschließlich Zeitpunkten, Organisations- und Ressourcenkennungen, Ergebnis und des für eine Untersuchung erforderlichen Kontexts. Speichern Sie einen Verweis auf die vorgeschlagene Version und die Entscheidung. Das Audit-Protokoll sollte nicht über die normalen Funktionen zur Bearbeitung von Anfragen geändert werden können. Beschränken Sie die protokollierten Daten auf das Notwendige und wenden Sie die Zugriffs- und Aufbewahrungsrichtlinien des Produkts an.
Die Benutzeroberfläche für den Betrieb sollte dabei helfen, ausstehende, abgelaufene, durch Konflikte blockierte oder genehmigte, aber noch nicht angewendete Anfragen zu finden. Erläutern Sie den Grund für die Blockierung und bieten Sie einen sicheren Lösungsweg an; wandeln Sie einen Anwendungsfehler nicht in eine automatische Genehmigung um. Benachrichtigungen können auf neue Aufgaben und Entscheidungen hinweisen, sind aber lediglich eine Unterstützung: Maßgeblich ist der gespeicherte und abfragbare Status.
Invarianten, Berechtigungen und Fehler testen
Tests müssen die Regeln prüfen, die niemals verletzt werden dürfen. Eine nicht genehmigte Anfrage ändert nicht die aktuellen Daten; eine Person ohne Zugriff auf die Organisation kann die Anfrage weder lesen noch ihren Status ändern; eine Selbstgenehmigung schlägt fehl, sofern sie untersagt ist; und eine genehmigte Anfrage kann nicht mit einem anderen als dem geprüften Inhalt angewendet werden. Ergänzen Sie Tests für Endzustände, abgelaufene Anfragen und ungültige Übergänge.
Testen Sie auch Wettläufe zwischen zwei Genehmigungen oder zwischen einer Genehmigung und einer Änderung der ursprünglichen Daten. Simulieren Sie Fehler während der Anwendung und prüfen Sie, dass die Anfrage nicht als angewendet markiert wird, wenn der Schreibvorgang nicht bestätigt wurde. Gibt es einen Task, der Anfragen ablaufen lässt, stellen Sie sicher, dass wiederholte Ausführungen sicher sind. Mit solchen Tests werden Geschäftsregeln zu überprüfbaren Garantien und der Workflow bleibt auch dann zuverlässig, wenn sich Berechtigungen oder das Datenmodell ändern.
Als Entwurfsmaßstab sollte jeder Schritt eine verantwortliche Person, eine überprüfbare Bedingung und ein beobachtbares Ergebnis haben. Kann das Team nicht erklären, wer zu welchem Übergang berechtigt ist, was bei einer gleichzeitigen Änderung geschieht oder wie eine Entscheidung rekonstruiert werden kann, muss der Workflow vor dem Produktivbetrieb noch genauer definiert werden.
