En timeout betyr at avsenderen mangler svar. Den beviser ikke at mottakeren mangler data. Før ny kjøring må dere vite om hendelsen er avvist, akseptert eller fortsatt har ukjent status.
Tre feiltilstander krever ulike handlinger
| Tilstand | Neste kontroll |
|---|---|
| Dokumentert avvist før behandling | Rett årsak og send etter avtalt rutine |
| Delvis akseptert | Finn aksepterte ID-er og restkø |
| Ukjent utfall | Søk status hos mottaker før ny sending |
Anta at 100 veiesedler sendes og forbindelsen brytes etter 60 bekreftelser. Det er ikke trygt å sende alle som nye. De siste 40 kan også være mottatt. Bruk stabile hendelses-ID-er og mottakerens statusmekanisme til å avklare.
Bevar spor og avgrens påvirkningen
Stopp bare det berørte løpet når det er forsvarlig. La godkjente poster beholde status. Feilkøen bør ha hendelsesreferanse, årsak, siste forsøk og ansvarlig, men ikke unødvendige personopplysninger eller hemmeligheter.
Lag en manuell reserveprosedyre med samme identifikatorer og etterkontroll. En midlertidig regnearkføring som ikke avstemmes tilbake, skaper lett et nytt dobbeltgrunnlag ved oppstart.
Se kontrollsummer og drift og støtte. Prøv feilsituasjonen i testmiljø før den oppstår i en ordinær fakturakjøring.
Avklar utfallet før en manuell reserve brukes
Hvis ordinær overføring har ukjent status, må en manuell faktura eller føring merkes og kobles til opprinnelig hendelse. Når systemet kommer tilbake, skal reserveføringen avstemmes før køen gjenopptas.
Stabile identifikatorer hjelper, men en teknisk duplikatsperre er ikke automatisk en garanti for hele forretningsløpet. Kontroller hvordan den virker ved korreksjon, ny versjon og delvis mottak. Dokumenter eventuelle tidsgrenser og unntak fra leverandøren.
Etter en større feil bør rapporten vise hvilke poster som var berørt, hvordan status ble avklart og hva som ble gjort. Bruk syntetiske eller avgrensede referanser i tekniske logger. Fullstendige kunde- eller betalingsdata trengs sjelden for å forklare selve hendelsesforløpet.