Når et automatisk workflow fejler: sådan samler I op
Aftal fejlbesked, ansvar og genkørsel, før en arbejdsgang går i drift. En praktisk guide til at opdage fejl uden at skabe dubletter.
En formular modtager en opgave, et system opretter en sag, og en kollega får besked. Det ser enkelt ud, indtil forbindelsen til sagsystemet svigter. Nu er spørgsmålet ikke kun, hvorfor kørslen stoppede. I skal også vide, om kunden har fået en kvittering, om sagen alligevel blev oprettet, og hvem der skal samle arbejdet op.
Et automatisk workflow bør have et aftalt fejlforløb. Brug eksemplet med formular og sag til jeres egen fejlplan sammen med den, der bygger løsningen.
Skeln mellem at starte og at være færdig
Beskriv først det resultat, som skal være opnået, før opgaven må stå som færdig. I eksemplet er det ikke nok, at formularen blev modtaget. Den nye sag skal kunne findes i sagsystemet med de rigtige oplysninger. En besked til en kollega er et efterfølgende trin, som også kan fejle, selv om selve sagen er oprettet.
Giv hvert trin en tydelig status. Modtaget, afventer, udført og kræver hjælp kan være nok. Undgå at samle alle tilstande under en grøn markering. Den person, der ser oversigten, skal kunne afgøre, om noget stadig mangler, uden at læse tekniske logfiler.
Lav en besked, som nogen kan handle på
Aftal, hvem der tager imod fejlmeldingen, og hvordan den kan findes igen. Beskeden bør identificere opgaven, det trin der stoppede, tidspunktet og det næste mulige skridt. Brug en reference til sagen frem for at kopiere hele kundens besked ind i en fælles alarmkanal.
- Hvilken opgave blev ramt, og hvor findes den?
- Hvad ved vi er udført, og hvad er stadig uafklaret?
- Forsøger systemet igen, eller skal et menneske gøre noget?
- Hvem har ansvaret for at afslutte opfølgningen?
Genkør ikke blindt efter en timeout
En timeout betyder, at afsenderen ikke fik svar i tide. Den fortæller ikke i sig selv, om modtageren nåede at oprette sagen. Et nyt forsøg kan derfor skabe en ekstra sag, hvis integrationen ikke genkender, at det er den samme opgave.
Det tekniske begreb idempotens beskriver, at gentagelse af den samme handling har samme tilsigtede effekt som én udførelse. MDN fremhæver, at HTTP-metoder ikke alle har denne egenskab. Bed derfor udvikleren forklare, hvordan netop jeres integration genkender en opgave ved genkørsel. Et navn på teknologien er ikke tilstrækkeligt.
Aftal hvilke fejl der må vente
Nogle fejl kan forsvinde efter en pause, mens andre kræver en rettelse. Manglende adgang eller et obligatorisk felt bliver ikke nødvendigvis løst ved at gentage den samme handling. Jeres fejlplan bør skelne mellem midlertidige problemer og opgaver, der skal tages ud til behandling.
En tjeneste kan sende HTTP-feltet Retry-After for at angive ventetid før et nyt forsøg. MDN beskriver blandt andet brugen ved for mange forespørgsler og midlertidig utilgængelighed. Om jeres værktøj faktisk følger beskeden, skal kontrolleres i opsætningen. Aftal samtidig en grænse for forsøgene, så en fejl ikke bliver til en endeløs kø.
Afprøv fejlvejen sammen med den normale vej
Brug et testmiljø eller ufarlige testdata til at se, hvad der sker, når en forbindelse mangler, et felt er forkert, og samme opgave kommer ind igen. Kontroller både systemets status og den besked, som den ansvarlige modtager. Ret derefter fejlen og gennemfør opfølgningen. Prøven er først nyttig, når I også har set, hvordan køen bliver ryddet korrekt.
Tag skærmbilleder eller en kort optagelse af de vigtigste trin, og gem dem sammen med en enkel vejledning. Den kollega, der tager over en anden dag, skal kunne se, hvordan en sag genfindes, og hvornår det er forsvarligt at forsøge igen. Skriv også, hvad man skal lade være med, hvis resultatet hos modtageren er ukendt.
Følg op på gentagelser
Gennemgå de fejl, der kommer igen. Hvis den samme oplysning mangler i mange sager, kan formularen eller instruktionen være det rigtige sted at rette. Hvis en forbindelse ofte kræver manuel hjælp, kan den aftalte reserveprocedure være for tung. Brug observationerne til at ændre ét led ad gangen, så I kan se, hvad rettelsen gør.
Skal jeres arbejdsgang først beskrives, kan guiden til at forberede data hjælpe med at finde oplysninger og ansvar. I kan også sende os et eksempel på det forløb, I vil bygge, gerne med en beskrivelse af den fejl, I helst vil kunne håndtere.
Kilder
MDN: Idempotent og MDN: Retry-After, læst 8. september 2026. Kilderne forklarer de tekniske begreber. Opgaveeksemplet og forslaget til fejlplan er redaktionens egne.
