Integrationer og stabil drift

Dataafstemning: find forskelle mellem appen og de systemer, den forbinder

En integration kan være grøn, selv om en booking mangler, en betaling står forkert, eller et statusskift aldrig nåede økonomisystemet. Dataafstemning sammenligner de vigtige forretningsfakta, gør afvigelser synlige og reparerer dem uden at overskrive den rigtige virkelighed.

Udgivet 30. september 2026 · Ca. 11 minutters læsetid

Et vellykket kald er ikke det samme som ens data

To systemer kan komme ud af takt, selv om integrationen normalt virker. Et webhook kan være leveret, men fejle senere i behandlingen. Et timeout kan skjule, at leverandøren faktisk gennemførte handlingen. En medarbejder kan rette en status direkte i et eksternt system. Eller en gentagelse kan skabe en dublet.

Afstemning er et sikkerhedsnet, ikke en ny hovedintegration. Webhooks, køer og retries skal stadig håndtere den normale trafik. Afstemningen kontrollerer bagefter, om de forretningskritiske resultater faktisk stemmer.

Vælg en sandhedskilde for hvert vigtigt faktum

“Hvilket system har ret?” skal kunne besvares pr. oplysning. Ét system behøver ikke eje hele objektet. Appen kan eje kundens bestilling, betalingsudbyderen kan eje den autoritative betalingsstatus, og økonomisystemet kan eje bogføringsnummeret.

Forretningsfaktum	Mulig sandhedskilde	Afstemningsregel
Betaling gennemført	Betalingsudbyder	Eksternt betalings-id, beløb, valuta og status skal passe til ordren
Bookingens ønskede indhold	Appens godkendte ordre	Dato, produkt, antal og kunde skal kunne forbindes med leverandørens reservation
Bogført bilag	Økonomisystem	Bilags-id og total findes én gang og peger tilbage på appens stabile reference
Levering sendt	Leveringssystem	Forsendelses-id og faktisk status afspejles i appen inden for den aftalte frist

Microsoft anbefaler en tydelig source of truth, når stærk konsistens er nødvendig. Kopier i andre tjenester kan være forsinkede, men de må ikke blive behandlet som en ny autoritativ virkelighed uden en bevidst regel.

Forbind poster med stabile nøgler

Navn, email, dato og beløb er sjældent sikre matchnøgler. De kan ændre sig eller være ens for flere poster. Gem leverandørens objekt-id sammen med appens eget id, og send appens reference som metadata, hvor den konkrete leverandør understøtter det.

Intern nøgle: Stabilt id for ordre, booking, sag eller job i appen.
Ekstern nøgle: Leverandørens id for det tilsvarende objekt eller den tilsvarende hændelse.
Forsøgs-id: Idempotency key eller anden stabil reference, som gør en gentagelse genkendelig.
Sporings-id: Correlation- eller request-id, der forbinder logs på tværs uden at være selve forretningsnøglen.

Match ikke automatisk på “samme beløb samme dag”. Det kan være et godt søgesignal til manuel kontrol, men ikke et sikkert grundlag for at markere en betaling, booking eller faktura som den samme post.

Beskriv sluttilstand og tilladt forsinkelse

Forskellige systemer behøver ikke være ens i hvert millisekund. Skriv i stedet den gyldige sluttilstand og hvor længe en midlertidig forskel må vare. En betaling kan eksempelvis være “afventer” i appen, mens udbyderen færdigbehandler den, men ikke stå ukendt uden ejer i flere dage.

Forventet forskel: Status er på vej gennem køen og ligger stadig inden for den aftalte behandlingstid.
Manglende post: Kilden har et objekt, men den forventede reference findes ikke i det andet system.
Modstridende fakta: Beløb, valuta, status eller ejerskab er forskelligt efter den tilladte frist.
Dublet eller ukendt: Flere mulige match eller en tilstand, som reglen ikke sikkert kan afgøre.

Kør en afgrænset, gentagelig sammenligning

En praktisk afstemning kører på en tidsplan og kan genoptages. Den behøver ikke læse hele historikken hver gang. Brug et dokumenteret tidsvindue eller en cursor, men lad gerne vinduer overlappe, så en forsinket post ikke falder mellem to kørsler.

1. Afgræns omfanget. Vælg én kritisk strøm, eksempelvis gårsdagens betalte ordrer eller bookinger med ukendt status.
2. Hent fra begge sider. Brug mindst mulige læserettigheder, pagination og leverandørens dokumenterede grænser.
3. Normalisér kun det nødvendige. Sammenlign stabile id’er, relevante statusser, beløb, valuta og tidsfelter efter en tydelig regel.
4. Klassificér afvigelsen. Skeln mellem forsinkelse, manglende post, dublet, modstrid og ukendt match.
5. Gem et dataminimeret resultat. Registrér reference, regel, observeret forskel og tidspunkt – ikke komplette payloads som standard.

Leverandørers hændelses- og leveringshistorik kan have en tidsgrænse. Stripe oplyser eksempelvis en begrænset historik i Events API, og GitHub beskriver særskilt kontrol og genlevering af fejlede webhooks. Kontrollér derfor den aktuelle dokumentation for hver integration, og opbevar de nødvendige egne referencer til jeres driftsbehov.

Reparér efter konsekvens – ikke med blind overskrivning

Fund og reparation er to forskellige rettigheder. Begynd gerne med en rapport, og automatisér kun reparationer, hvor sandhedskilden og konsekvensen er entydig. Microsoft anbefaler at sende uafklarede eller irreversible resultater til en operatør og bruge forretningsspecifik kompensation, når en handling skal omgøres.

Sikker automatisk reparation

Opdatér en lokal læsekopi fra dens autoritative kilde, hvis handlingen er idempotent, den aktuelle tilstand stadig matcher forventningen, og resultatet ikke udløser ny betaling, besked eller levering.

Kontrolleret genbehandling

Genkør en gemt hændelse eller et job med samme stabile nøgle, loft over forsøg og synlig status. Gentagelsen må ikke oprette endnu en ordre, betaling eller mail.

Manuel afgørelse eller kompensation

Beløbsforskel, dobbelt reservation, refundering eller allerede udført levering kræver ofte en navngiven beslutning. Vis beviset, kræv den rette rolle, log handlingen, og brug en særskilt kompensation frem for at redigere historikken væk.

Overvåg selve afstemningen

En afstemning, der er stoppet, giver falsk ro. Driften skal kunne se sidste succesfulde kørsel, det behandlede vindue og om restlisten bliver ældre.

Friskhed: Tid siden sidste komplette kørsel og seneste sammenlignede tidspunkt.
Omfang: Antal læste, matchede, afvigende, reparerede og uafklarede poster.
Alder: Ældste uafklarede kritiske afvigelse – ikke kun dagens antal.
Fejl: API-fejl, rate limits, manglende adgang, udløbet cursor og delvise kørsler.
Alarm: Udeblevet kørsel, voksende restliste eller afvigelse over en aftalt konsekvens eller alder.

Beskyt også afstemningsdata. Brug læseadgang med mindst mulige rettigheder, undgå secrets og fulde personoplysninger i rapporter, og giv fund og reparationshistorik en dokumenteret adgangs- og slettefrist.

Typiske fejl

Webhooken kaldes sandheden: Leveringen beskriver en hændelse, men den aktuelle autoritative status kan siden være ændret.
Kun tekniske fejl tælles: Et 200-svar skjuler, at beløb, valuta eller objekt-id er forkert.
Navn og dato bruges som nøgle: To legitime poster bliver slået sammen, eller samme post findes ikke efter en rettelse.
Seneste ændring vinder altid: Et forkert ur eller en lokal kopi overskriver den autoritative forretningsstatus.
Afstemningen skriver med det samme: En fejl i sammenligningen bliver til masseændringer i produktion.
Alle forskelle alarmerer: Forventet forsinkelse skaber støj, og den alvorlige afvigelse drukner.
Jobbet overvåger kun sig selv: “Kørsel gennemført” måles uden at opdage, at cursoren står stille eller omfanget er nul.

Tjekliste til dataafstemning i drift

☐ Én kritisk datastrøm og dens forretningskonsekvens er valgt.
☐ Sandhedskilden er besluttet for hvert felt, der sammenlignes.
☐ Interne og eksterne poster forbindes med stabile id’er.
☐ Gyldige sluttilstande og tilladt forsinkelse er dokumenteret.
☐ Afstemningen kan genoptages og genkøre et overlappende vindue sikkert.
☐ Fund klassificeres som forsinkelse, manglende, dublet, modstrid eller ukendt.
☐ Rapportering og reparation har adskilte rettigheder.
☐ Automatiske rettelser er idempotente og kontrollerer den aktuelle tilstand før skrivning.
☐ Uafklarede og irreversible udfald har en ejer og en manuel beslutningsvej.
☐ Sidste kørsel, datavindue, restlistens alder og reparationsfejl overvåges.
☐ Logs og rapporter undgår secrets og unødige personoplysninger.
☐ Fejlscenarier er afprøvet i et isoleret miljø med kendte testdata.

Relaterede guides

Webhooks med signatur, idempotens og genbehandling Timeout, retries og sikker nødadfærd til eksterne API-kald Baggrundsjob og køer til langsomt eller planlagt arbejde Revisionslog for ændringer og manuelle driftshandlinger Se hele guidebiblioteket

Officielle kilder

API’er, historikgrænser og genleveringsmuligheder ændrer sig. Kontrollér altid den aktuelle dokumentation for de systemer, appen faktisk forbinder.