Genforsøg, pauser og fejl i en integration
Aftal pauser, stop og opfølgning, før en integration fejler. Et konkret formularflow viser, hvad der kan vente, og hvad et menneske skal afklare.
En kontaktformular har sendt en henvendelse videre, men der kommer ingen kvittering fra modtagersystemet. Skal flowet vente, prøve igen eller bede en kollega om hjælp? Det spørgsmål bør være afklaret, før I kobler systemerne sammen.
Begynd med én arbejdsgang og giv hver hændelse et synligt næste skridt. Her bruger vi en formular, der skal oprette en opgave til den medarbejder, som følger op på henvendelsen. Brug eksemplet til at skrive jeres egen fejlplan.
Beskriv det, der skal ske, når alt fungerer
Formularen afleverer navn, kontaktoplysning og en besked. Flowet gemmer henvendelsen med et fast nummer, kontrollerer de nødvendige felter og sender den til opgavesystemet. Når systemet bekræfter oprettelsen med et opgavenummer, gemmes nummeret på henvendelsen. Først derefter vises den som afleveret.
Skriv også, hvor en kollega kan se resultatet. Et grønt symbol på en samlet kørsel er ikke nok til at besvare, om netop henvendelse 142 er kommet frem. Oversigten skal kunne vise den konkrete hændelse og opgaven, den blev til.
Skeln mellem en pause og et ukendt udfald
Et svar om at vente er en anden situation end slet intet svar. Ved en timeout kan modtagersystemet have nået at oprette opgaven, selv om kvitteringen ikke nåede tilbage. Registrér derfor det ukendte udfald, og undersøg den eksisterende henvendelse i modtagersystemet, før nogen starter en ny oprettelse.
| Det flowet observerer | Næste skridt | Det kollegaen skal kunne se |
|---|---|---|
| Oprettelsen er bekræftet med et opgavenummer | Gem nummeret og afslut afleveringen. | Link eller reference til den oprettede opgave. |
| Modtageren beder om en pause | Beregn næste forsøg, hvis handlingen må gentages. | Ventetid, begrundelse og planlagt tidspunkt. |
| Forbindelsen forsvinder uden et sikkert resultat | Sæt hændelsen til afstemning. Undlad en blind ny oprettelse. | Sidste forsøg og hvilket resultat der stadig er ukendt. |
| En nødvendig oplysning er ugyldig | Bed om den konkrete rettelse. | Det felt, der skal rettes, og hvem der følger op. |
| Det aftalte loft er nået | Stop automatiske forsøg og send sagen til den ansvarlige. | Stopårsag, tidligere forsøg og ansvarlig medarbejder. |
Brug modtagerens ventetid
Svarheaderen Retry-After kan angive en ventetid i sekunder eller et bestemt tidspunkt. Den bruges blandt andet ved for mange kald og midlertidig utilgængelighed. Jeres integration skal kunne læse begge formater og håndtere, at headeren mangler.
I eksemplet kan I aftale højst tre forsøg inden for en time. Det er et eksempel på en driftsregel, som skal tilpasses opgaven. Hvis modtageren beder om en længere pause end den resterende tid, skal flowet vise konflikten og stoppe efter jeres regel. Det skal ikke ignorere ventetiden for at nå sit eget loft.
Når ventetiden mangler eller ikke kan læses, bruges den pause, I har aftalt på forhånd. Gem, hvorfor den blev valgt. Et ukendt svar må ikke skabe en løkke af hurtige kald, der fortsætter, indtil nogen opdager den.
Aftal, hvilke handlinger der må gentages
Idempotens betyder, at gentagne identiske kald har samme tilsigtede effekt som ét kald, som MDN beskriver. Et metodenavn er dog ikke en erstatning for modtagerens dokumentation. Undersøg, hvordan netop oprettelsen af jeres opgave håndterer gentagelser og samtidige forsøg.
HTTP-standarden afgrænser automatisk gentagelse af ikke-idempotente kald. Et manglende svar er ikke i sig selv tilstrækkeligt grundlag for at sende sådan et kald igen. I formularflowet betyder det: brug modtagerens dokumenterede beskyttelse mod gentagelser, eller afstem det ukendte udfald, før en ny oprettelse overvejes.
Et lokalt nummer hjælper jer med at finde hændelsen og samle dens forsøg. Det beviser ikke, at et eksternt system kun har oprettet én opgave. Hold derfor styr på både jeres eget hændelsesnummer og de referencer, modtageren faktisk har returneret.
Giv de stoppede hændelser en ansvarlig
En fejlliste er kun nyttig, hvis nogen ved, hvad de skal gøre med den. Aftal en ansvarlig medarbejder, et tidspunkt for opfølgning og en stedfortræder. En fejlalarm skal pege på den enkelte hændelse og forklare, hvad der mangler for at komme videre.
- Vis hændelsens nummer, seneste forsøg, aktuelle status og næste aftalte handling.
- Vis, om modtageren har bekræftet noget, og hvilken reference der er gemt.
- Giv medarbejderen mulighed for at registrere sin afstemning og begrundelse.
- Skeln mellem at rette manglende oplysninger, fortsætte en sikker handling og lukke hændelsen.
- Bevar tidligere forsøg, så en ny medarbejder kan forstå forløbet.
Prøv stopreglerne før ibrugtagning
Afprøv en testhenvendelse, hvor modtageren svarer langsomt. Afprøv derefter en pause, en ugyldig oplysning og en forbindelse, der forsvinder efter afsendelsen. Kontrollér hver gang, at det næste skridt i oversigten svarer til det, I faktisk ved. Lad også den ansvarlige medarbejder prøve at afslutte en stoppet hændelse.
På Platformhusets integrationsside kan I se, hvordan vi arbejder med sammenhængen mellem systemer og synlige resultater. Til jeres brief er én konkret henvendelse og dens mulige stop ofte et godt sted at begynde.
Ofte stillede spørgsmål
Hvad gør vi, når opgavesystemet ikke svarer?
Gem hændelsen som et ukendt udfald og undersøg, om opgaven allerede findes. En timeout fortæller ikke i sig selv, om oprettelsen lykkedes. Send ikke en ny oprettelse alene for at få en kvittering.
Hvor mange genforsøg bør en integration have?
Aftal både et antal og en samlet tidsgrænse ud fra arbejdsgangen. Tre forsøg inden for en time er et eksempel, ikke en generel regel. Oversigten skal vise, når den valgte grænse stopper en hændelse.
Hvem skal tage sig af stoppede hændelser?
Sæt navn på en ansvarlig medarbejder og en stedfortræder. Aftal, hvor ofte listen gennemgås, og hvilke oplysninger der skal være til stede, før en hændelse kan fortsættes eller lukkes.
Kilder
- MDN: Retry-After, ventetid og formater.
- MDN: Idempotent, samme tilsigtede effekt ved gentagelse.
- RFC 9110, afsnit 9.2.2, idempotente metoder og grænser for automatiske genforsøg.
- Platformhuset: integration, vores produktbeskrivelse.
