Det korte svar
Et webhook giver besked, når en hændelse opstår. Polling undersøger med faste mellemrum, om noget har ændret sig. Valget afhænger af systemernes muligheder, hvor hurtigt data skal være aktuelle, og hvordan fejl skal opdages.
Beskriv først hvor hurtigt ændringen skal ses
En rapport til næste morgen har andre krav end et lagercheck før en ordre bekræftes. Aftal den maksimalt acceptable forsinkelse for den konkrete proces. Brug dette krav til at vælge integrationsformen, frem for at vælge den teknologi, der lyder mest moderne.
Undersøg også, om kildesystemet tilbyder de nødvendige hændelser eller opdateringstidspunkter. Et webhook om en ordreændring er ikke nødvendigvis en komplet kopi af ordren. Det kan være nødvendigt at hente den aktuelle post efter beskeden.
Sammenlign driftsegenskaberne
Polling er afhængig af interval, datamængde og systemets grænser for kald. Webhooks kræver en modtager, der kan verificere afsenderen og håndtere gentagelser. Ingen af metoderne fjerner behovet for opfølgning ved udfald.
| Spørgsmål | Webhooks | Polling |
|---|---|---|
| Hvordan starter arbejdet? | Kilden sender en hændelse | Modtageren spørger regelmæssigt |
| Typisk forsinkelse | Afhænger af hændelseslevering | Afhænger af interval og behandling |
| Vigtig fejltype | Tabt, gentaget eller forsinket besked | Oversprungne ændringer eller for tunge opslag |
| Nødvendig kontrol | Verificering, kø og dubletbeskyttelse | Stabil markør, overlap og afstemning |
Eksempel: en ordre ændres under et udfald
En ordre ændres, mens modtageren er utilgængelig. Hvis webhook-kilden ikke genleverer, kan ændringen blive overset. Et supplerende afstemningsjob kan undersøge opdaterede ordrer siden den seneste sikre markør.
Ved polling kan et opslag fejle halvvejs. Gem først fremdriftsmarkøren, når de relevante ændringer er behandlet sikkert. Et lille overlap mellem opslag kan reducere risikoen for huller, hvis løsningen samtidig kan håndtere gentagne poster. Detaljerne afhænger af API’ets sortering og tidsfelter.
Aftal hvad der sker med sene og gentagne hændelser
Beskeder kan komme i en anden rækkefølge end forretningshændelserne. Brug versioner eller opslag af aktuel tilstand, hvor systemet understøtter det. Undgå at en gammel besked sætter en afsluttet ordre tilbage til en tidligere status.
Vis seneste vellykkede opdatering og en kø over fejl. Aftal, hvem der reagerer, når data er for gamle. En integration, der fejler stille, er sværere at drive end en integration, der stopper tydeligt og bevarer arbejdet.
Brug det i praksis
Jeres næste skridt
- Definér den nødvendige aktualitet for processen.
- Undersøg kildens hændelser, versioner og kaldgrænser.
- Planlæg verificering og afstemning.
- Gem fremdrift sikkert ved delvise fejl.
- Vis forsinkelser og fejl til en ansvarlig.
Ofte stillede spørgsmål
Er webhooks altid hurtigere?+
De kan give hurtig besked, men den faktiske forsinkelse afhænger af kilden, køer og behandling.
Kan metoderne kombineres?+
Ja. Hændelser kan bruges til hurtig opdatering og periodiske opslag til afstemning, hvis API’et understøtter det.
Kan vi stole på, at en besked kun kommer én gang?+
Det bør ikke antages uden en udtrykkelig garanti og en vurdering af hele kæden. Design for gentagelser og fejl.
Kilder og faglig baggrund
De praktiske eksempler og tjeklister er udarbejdet til denne guide. Følgende kilder uddyber de angivne faglige begreber.
Teknisk baggrund om genforsøg, midlertidige fejl og idempotens.
Begreber i guiden
Fra guiden til jeres arbejdsgang
Se hvilke oplysninger, adgange og kontroller der skal afklares, før jeres systemer forbindes.
Brug skabelonen
Saml jeres egne oplysninger i et arbejdsgrundlag, som kan udfyldes og downloades.
Udgivet af Norstream med AI-assisteret udarbejdelse. Eksempler er illustrative, medmindre andet er angivet. Tilpas metoder og kontroller til jeres systemer og faglige ansvar.
Har du en rettelse eller et spørgsmål?