Integrationer
Del af Integrationer og workflows
Håndtér fejl i en synlig undtagelseskø
Giv integrationsfejl en årsag, en ejer og et næste skridt. Skeln mellem sikkert genforsøg, datarettelse og ukendt udfald.
En undtagelseskø skal vise, hvilken integrationspost der standsede, hvorfor den standsede, hvem der ejer sagen, og hvad der skal ske nu. En teknisk log kan forklare en fejl uden at gøre den til en opgave, som nogen kan afslutte.
Vælg næste handling efter fejlen
En kortvarigt utilgængelig tjeneste kan egne sig til et begrænset genforsøg. En ukendt statusværdi kræver afklaring af kildedata eller feltmapping. Hvis svaret fra målsystemet gik tabt, skal resultatet undersøges før et nyt oprettelseskald.
| Fejltype | Første spørgsmål | Næste handling |
|---|---|---|
| Midlertidigt udfald | Er et genforsøg sikkert, og angiver tjenesten en ventetid? | Vent og gentag begrænset. |
| Ugyldige data | Hvilket felt eller hvilken regel blev brudt? | Ret ved gældende kilde eller i mappingen. |
| Ukendt udfald | Findes resultatet allerede? | Afstem før ny afsendelse. |
| Vedvarende teknisk fejl | Gælder fejlen én post eller mange? | Tildel teknisk ejer og overvej at standse strømmen. |
Klassifikationen er en arbejdsgang; et produkt udfører den ikke nødvendigvis automatisk.
Vis nok kontekst til at handle
Vis kildepostens reference, ønsket handling, tidspunkt, fejltype, seneste forsøg, status, ansvarlig og næste skridt. Gem også en reference til et eventuelt resultat i målsystemet. Giv medarbejderen en kort forklaring og begræns adgangen til tekniske detaljer. Kopiér ikke hele beskeder med personoplysninger til en bredt tilgængelig fejlvisning, hvis nødvendige felter og referencer er nok.
En teknisk dead-letter-kø er noget andet end en arbejdskø. Azure Service Bus kan holde beskeder, der ikke kunne leveres eller behandles, i en dead-letter-underkø. Beskederne ryddes ikke automatisk. Funktionen opbevarer beskeder til undersøgelse; den tildeler ikke i sig selv en medarbejder ansvar for at rette årsagen.
Genbehandl først efter afklaring
Vis hvilken kildeversion og handling der skal genbehandles. Find først et muligt oprettet resultat i målsystemet, hvis det tidligere udfald er ukendt. Hvis kildedata er rettet, skal det være klart, om den oprindelige eller den opdaterede post sendes. Registrér hvem der genbehandlede sagen, hvornår det skete, og hvad resultatet blev.
Hvis samme fejl rammer mange poster, bør ejeren kunne standse videre behandling og rette den fælles årsag. Bevar de oprindelige fejl i historikken, så gentagne problemer kan undersøges.
Følg op på åbne sager
Aftal en ejer og stedfortræder for hver integration. Prioritér efter betydningen for arbejdet, og se både antal åbne sager og deres alder. En tom fejlkø viser ikke, at alle kildehændelser nåede frem; det kan kræve en særskilt afstemning.
Prøv arbejdsgangen med fiktive tilfælde: ugyldigt felt, kortvarig netværksfejl, tabt svar og en sag uden klar ejer. Angiv på forhånd, hvor hver sag skal lande, og hvad der må genbehandles.
