Een bewerking automatiseren betekent niet altijd dat deze zonder tussenkomst wordt uitgevoerd. Als een actie belangrijke gegevens kan wijzigen, een commerciële voorwaarde kan toepassen, geld kan verplaatsen of gevolgen kan hebben voor derden, moet deze mogelijk wachten op goedkeuring door een persoon. Een menselijke goedkeuringsworkflow voor PHP-automatisering biedt die controle zonder het proces te veranderen in een informele keten van berichten en beslissingen die achteraf moeilijk te reconstrueren zijn.
De kern is niet simpelweg een knop ‘goedkeuren’ toevoegen, maar vastleggen wat wordt voorgesteld, wie een beslissing mag nemen, op basis van welke informatie, hoe lang die beslissing geldig is en wat er daarna gebeurt. Het systeem moet elke status kunnen verklaren en voorkomen dat een oude of dubbele goedkeuring een andere actie uitvoert dan de actie die is beoordeeld.
Bepalen wanneer een bewerking moet worden gepauzeerd
Een controle achteraf is bedoeld om problemen op te sporen nadat de actie heeft plaatsgevonden. Een voorafgaande goedkeuring houdt de uitvoering daarentegen tegen totdat er een beslissing is genomen. Vraag om goedkeuring wanneer de mogelijke impact, de moeilijkheid om de actie terug te draaien of de onzekerheid groter is dan het aanvaarde niveau voor automatisering.
Beoordeel elke bewerking aan de hand van concrete vragen: kan deze een gegeven wijzigen dat moeilijk te herstellen is? Heeft ze gevolgen voor geld, rechten, toegang of toezeggingen aan klanten? Is er een verifieerbare regel op basis waarvan de bewerking zelfstandig kan worden uitgevoerd? Hoeveel schade kan een fout veroorzaken en hoeveel tijd is er om te reageren? Een routinematige, omkeerbare en beperkte bewerking kan automatisch worden uitgevoerd en voor controle worden vastgelegd. Voor een uitzonderlijke actie of een actie met grote impact kan voorafgaande goedkeuring nodig zijn.
Pas menselijke controle niet standaard op alles toe. Een overvolle wachtrij veroorzaakt vertragingen en moedigt routinematige goedkeuringen aan. Definieer drempelwaarden en uitzonderingen en meet openstaande verzoeken, wachttijden, afwijzingen en verlopen verzoeken om regels te vinden die moeten worden aangepast. Baseer de beslissing op het werkelijke risico, niet alleen op het feit dat een bewerking technisch mogelijk is.
Vastleggen wat wordt voorgesteld en wat kan worden goedgekeurd
De beoordelaar moet het effect van de bewerking begrijpen en niet een intern PHP-object hoeven te ontcijferen. Toon de huidige en voorgestelde waarde, de reden, de herkomst van de gegevens, relevante gevolgen en eventuele beperkingen. Als een beslissing afhangt van een regel, geef dan de uitleg die nodig is om die toe te passen. Verberg of bescherm persoonsgegevens die niet nodig zijn.
Scheid het voorstelcommando van de autorisatie. Het voorstel beschrijft de actie en de bijbehorende parameters; de autorisatie staat toe dat dit specifieke voorstel wordt uitgevoerd. De autorisatie mag geen algemene rechten verlenen en mag de goedkeurder niet toestaan de parameters ongemerkt aan te passen. Als wijzigingen nodig zijn, kan de beoordelaar een wijziging aanvragen; het systeem maakt dan een bijgewerkt voorstel dat opnieuw aan de toepasselijke autorisatieregels moet voldoen.
Pas het principe van minimale privileges toe: beperk wie voorstellen kan maken, goedkeuren, afwijzen of annuleren en controleer die rechten bij elke statusovergang aan de serverzijde. Vereis, wanneer het risico dat rechtvaardigt, dat de indiener zijn of haar eigen bewerking niet kan goedkeuren. Implementeer deze scheiding in de autorisatielogica; vertrouw niet uitsluitend op het verbergen van knoppen in de interface.
Expliciete statussen en overgangen modelleren
Modelleer het proces als een state machine. Een bruikbare eerste set statussen kan bestaan uit pending, approved, executing, rejected, changes_requested, expired, cancelled en executed. Een voorstel in afwachting kan worden goedgekeurd, afgewezen, geannuleerd of verlopen; een goedgekeurd voorstel kan alleen worden uitgevoerd als het nog geldig is; een voorstel dat wordt uitgevoerd, kan eindigen als uitgevoerd of teruggaan naar een herstelbare status als is vastgesteld dat er geen effect is opgetreden. Een uitgevoerd voorstel kan niet opnieuw worden goedgekeurd.
Sla de huidige status op naast een onveranderlijke geschiedenis van beslissingen en overgangen. Leg het voorstel-ID, de vorige en nieuwe status, de actor, datum en tijd, reden en verwijzing naar de versie van de beoordeelde gegevens vast. Vervang de geschiedenis niet wanneer je het record bijwerkt: die is nodig om te auditen wat er is gebeurd en fouten te diagnosticeren.
Centraliseer overgangen in PHP in een domeinservice of een gelijkwaardig component. Laat verschillende controllers de status niet rechtstreeks aanpassen via generieke updates. Valideer waar nodig de overgang en de rechten binnen een transactie en wijs acties af die niet bij de huidige status passen. Deze structuur vermindert fouten door gelijktijdige bewerkingen en maakt het eenvoudiger de regels te testen zonder afhankelijk te zijn van de interface.
Verouderde goedkeuringen en dubbele uitvoering voorkomen
Gegevens kunnen veranderen terwijl een voorstel op goedkeuring wacht. Een persoon mag geen voorwaarde goedkeuren die niet langer overeenkomt met de bewerking die wordt uitgevoerd. Sla bij het aanmaken van het voorstel een versie, wijzigingsdatum of fingerprint van de relevante velden op. Controleer deze bij goedkeuring opnieuw aan de hand van de actuele status.
Controleren bij goedkeuring is niet voldoende: de gegevens kunnen nog veranderen voordat de bewerking wordt toegepast. Vergelijk vlak voor de uitvoering de actuele versie of fingerprint opnieuw met de goedgekeurde versie. Stop het proces als deze afwijkt, maak de autorisatie voor dat voorstel ongeldig en vraag om een nieuwe beslissing op basis van de bijgewerkte gegevens. Afhankelijk van het risico kun je de verschillen tonen en een expliciete bevestiging vereisen, maar je mag de eerdere goedkeuring niet automatisch opnieuw gebruiken.
Een vervaldatum beperkt hoe lang een beslissing geldig is. Markeer het voorstel na het verstrijken van die termijn als verlopen en vereis een nieuwe goedkeuring om verder te gaan. Controleer bij elke nieuwe poging of de autorisatie nog geldig is; gebruik een verlopen autorisatie nooit opnieuw om de uitvoering te hervatten of te herhalen.
De goedkeuring moet betrekking hebben op een identificeerbaar voorstel en mag geen herbruikbaar signaal zijn. Voorkom dat twee workers hetzelfde voorstel uitvoeren door de overgang van approved naar executing atomair te claimen of te vergrendelen: slechts één worker mag het voorstel claimen, en alleen als het nog goedgekeurd en geldig is. Controleer binnen deze lokale beveiliging ook de idempotentie en registreer de unieke bewerkings-ID voordat je verdergaat. Dit voorkomt duplicaten binnen het systeem, maar een databasetransactie garandeert op zichzelf niet dat een externe API een effect slechts één keer toepast.
Als de actie in een andere service plaatsvindt, gebruik dan, indien beschikbaar, een idempotency key die door die service wordt geaccepteerd en idempotent wordt verwerkt. Registreer de correlatie-ID, de poging en de antwoorden. Als het antwoord verloren gaat of het resultaat onbekend is, herhaal het effect dan niet blindelings: vraag de externe status op aan de hand van die ID of reconcileer het resultaat met betrouwbare gegevens. Als niet kan worden vastgesteld of het effect heeft plaatsgevonden, stop dan verdere automatische pogingen en leg de zaak voor aan een operator. Bij een fout waarvan vaststaat dat die optrad voordat het verzoek is verzonden, kan een nieuwe poging worden toegestaan, mits de status en autorisatie opnieuw worden gecontroleerd.
Als een worker uitvalt en een voorstel in executing achterlaat, markeer het dan niet automatisch als uitgevoerd en verzend het niet opnieuw zonder eerst een diagnose te stellen. Een herstelproces moet aan de hand van het lokale log en, waar van toepassing, een controle bij de externe service bepalen of het effect heeft plaatsgevonden. Als het bevestigt dat dit niet het geval is, kan het voorstel alleen naar een uitvoerbare status worden teruggezet nadat de geldigheid, gegevens en autorisatie opnieuw zijn gecontroleerd; als de uitkomst onbekend blijft, moet het geblokkeerd blijven en worden opgeschaald.
Een operationele wachtrij en een handmatig alternatief ontwerpen
De wachtrij moet het mogelijk maken openstaande verzoeken te vinden op basis van ouderdom, impact, verantwoordelijke en vervaldatum, en moet bovendien de context tonen waarop de beslissing is gebaseerd. Leg uit waarom een geval geblokkeerd is en welke actie passend is: wachten, wijzigingen aanvragen, annuleren of escaleren. De interface moet ook duidelijk maken wat er gebeurt na goedkeuring, in plaats van alleen beslisknoppen aan te bieden.
Definieer een alternatief voor wanneer een afhankelijkheid uitvalt, zoals de notificatieservice of een integratie die nodig is om de actie uit te voeren. Het voorstel kan in afwachting blijven, terwijl een gecontroleerde procedure wordt geboden waarmee een bevoegd persoon het geval kan beoordelen in het beschikbare operationele systeem. De handmatige route moet dezelfde controles respecteren, de actor en reden vastleggen, parallelle uitvoering voorkomen en het resultaat reconciliëren zodra de integratie is hersteld.
Maak van een technische storing geen impliciete goedkeuring. Als identiteit, rechten of benodigde informatie niet kunnen worden geverifieerd, moet het systeem veilig falen: pauzeren, informeren en escaleren. Leg vast wie het proces mag deblokkeren, hoe die interventie wordt gedocumenteerd en welke taken na herstel van de service moeten worden gecontroleerd.
De workflow testen en de werking bewaken
Test de domeinregels en volledige processtromen: goedkeuring, afwijzing, wijzigingsverzoek, verlopen, annulering en nieuwe pogingen. Voeg tests voor rechten toe om te bevestigen dat iemand zonder autorisatie de status niet kan wijzigen, en concurrencytests om te controleren dat twee gelijktijdige beslissingen niet tot twee uitvoeringen leiden.
Neem gevallen op waarin gegevens veranderen tijdens het wachten of vlak voor de uitvoering, de externe uitvoering mislukt nadat het verzoek is geaccepteerd, en een antwoord verloren gaat terwijl het effect wel heeft plaatsgevonden. Controleer dat de atomaire claim ervoor zorgt dat slechts één worker het voorstel uitvoert, dat nieuwe pogingen verlopen autorisaties afwijzen en dat elke handmatige interventie voldoende wordt vastgelegd. Bewaak in productie het aantal en de ouderdom van openstaande verzoeken, verlopen verzoeken, uitvoeringsfouten en gevallen die reconciliatie vereisen.
Een goed ontworpen workflow houdt menselijk toezicht in stand waar dat controle oplevert, zonder de veiligheid afhankelijk te maken van het geheugen van teams. Expliciete statussen, gescheiden rechten, actuele beoordeelde gegevens, idempotente uitvoering en een duidelijke route bij storingen maken van een informele goedkeuring een verifieerbaar proces.
