Webhooks uden dobbeltopgaver: Krav til en sikker genkørsel
En integration kan få den samme besked mere end én gang. Hvis hver levering opretter en ny opgave, får medarbejderne dubletter. Her er en konkret kravliste til et forløb, der skal kunne genoptages efter fejl.
Skeln mellem besked og forretningshandling
Et webhook er en besked, som et system sender til et andet ved en hændelse. Googles nye Workspace Studio-muligheder gør emnet aktuelt. Som et konkret teknisk eksempel dokumenterer Stripe, at webhook-hændelser kan leveres flere gange, og at rækkefølgen ikke er garanteret. Andre systemers leveringsregler skal undersøges særskilt.
1. Beskriv det resultat, der kun må ske én gang
Skriv eksempelvis: En godkendt formularindsendelse skal give én opgave til salgsteamet. Angiv derefter, hvad der identificerer indsendelsen. En kundes mailadresse er sjældent tilstrækkelig alene, fordi samme person kan sende to forskellige henvendelser.
Bed leverandøren forklare, hvordan to leveringer af samme hændelse skelnes fra to nye hændelser. Vælg en stabil reference fra kilden, og lad den følge med til resultatet, så en medarbejder kan spore sammenhængen.
2. Gem, hvor langt behandlingen er nået
Foreslå mindst tre tydelige tilstande: modtaget, under behandling og afsluttet. Et afsluttet forløb skal pege på den opgave, der faktisk blev oprettet. Hvis der blot står modtaget, kan teamet ikke vide, om opgaven også findes.
Der er et særligt fejlpunkt, hvis målsystemet opretter opgaven, men svaret går tabt. Før en ny oprettelse skal løsningen kunne undersøge, om resultatet allerede findes med den stabile reference. Den konkrete mekanisme afhænger af målsystemets muligheder.
3. Afprøv samtidige og forsinkede beskeder
Bed udvikleren vise en prøve med to samtidige leveringer, ikke kun to leveringer efter hinanden. De må ikke begge nå at konkludere, at opgaven mangler. Det kan kræve en entydighedsregel eller en anden koordineret behandling i den valgte løsning.
Prøv også et gammelt signal efter en nyere ændring. Et forsinket signal bør ikke uden videre flytte en færdig sag tilbage til en tidligere status. Aftal, hvornår den aktuelle tilstand skal genlæses fra kildesystemet.
4. Gør genoptagelse til en synlig handling
Lav en fejlliste med hændelsesreference, seneste forsøg, årsag og ansvarlig. Aftal, hvem der må genoptage en sag, og hvordan vedkommende kontrollerer resultatet. Undgå en procedure, hvor alle beskeder sendes igen, blot fordi nogle få fejlede.
Acceptkriteriet er konkret: De aftalte prøver ender med det korrekte antal opgaver, og hver opgave kan spores til sit input. Kravlisten er vores forslag til en leverandørdialog; den er ikke dokumentation for, at jeres eksisterende integration allerede opfylder den.