I denne guiden
Velg etter hva som må stemme
Spør først hva integrasjonen skal holde oppdatert. Skal lageret få en ny ordre raskt? Skal regnskapet få fullstendige oppgjørsdata? Skal et varekort synkroniseres når prisen endres? Kravene til forsinkelse og fullstendighet er forskjellige.
| Behov | Aktuelt mønster | Kontroll som fortsatt trengs |
|---|---|---|
| Starte plukk av en ny ordre | Hendelsesvarsel og henting av ordredetaljer | Finn ordre som ikke nådde lageret |
| Oppdatere et endret produkt | Hendelsesvarsel eller periodisk henting | Unngå at eldre data overskriver nyere |
| Hente en historisk periode | API med avgrensning og sideinndeling | Kontroller at alle sidene ble lest |
| Forklare månedens oppgjør | Rapporter og transaksjonsreferanser | Avstem betalinger, gebyr og refusjoner |
Et raskt varsel er nyttig, men «sendt» hos avsenderen og «ferdig behandlet» hos mottakeren er to forskjellige tilstander.
Eksempel: ordren kommer to ganger
En tenkt butikk sender ordre 1042 til en lagerintegrasjon. Mottakeren lagrer ordren, men bekreftelsen kommer ikke frem før avsenderen gir opp. Hendelsen forsøkes derfor levert igjen.
Hvis mottakeren oppretter en ny lagerordre hver gang, kan kunden få to pakker. Integrasjonen må gjenkjenne både en gjentatt levering og at forretningshandlingen allerede er utført. Det er ikke nok at de to HTTP-forespørslene ser litt forskjellige ut.
I Shopifys webhook-dokumentasjon beskrives kontroll av signatur, håndtering av duplikater og periodisk avstemming. Bruk plattformens egne identifikatorer; ikke lag en duplikatregel som bare sammenligner kundens navn og beløp.
Eksempel: refusjonen kommer før ordreoppdateringen
En ordre er delvis refundert. En eldre oppdatering av ordren kommer frem etter refusjonshendelsen. Hvis integrasjonen ukritisk lagrer siste mottatte melding som sannheten, kan den vise den gamle betalingsstatusen igjen.
Mottatt rekkefølge er derfor ikke alltid hendelsesrekkefølge. Avklar hvilke tidsstempler eller versjoner som styrer oppdateringen, og når mottakeren skal hente gjeldende data fra kildesystemet. Regelen må fungere også etter et gjenforsøk.
Slik oppdager du det som aldri kom frem
Et varsel som mangler, etterlater ikke nødvendigvis en feilmelding i mottakeren. Ha derfor en separat kontroll som sammenligner kilden med det som faktisk er overført.
En praktisk kontroll kan hente endrede ordre siden forrige vellykkede gjennomgang. Den må håndtere sideinndeling, overlapp i tidsrommet og gjentatt behandling. Lagre fremdrift først når den aktuelle delen er behandlet pålitelig; ellers kan kontrollen hoppe over data den tror er ferdig.
Bestem også hva som skjer med ordre som fortsatt feiler: synlig avvik, ansvarlig person og en trygg måte å forsøke på nytt. «Vi ser på loggen hvis noen klager» er ingen kontroll av fullstendighet.
Be leverandøren vise disse fem testene
- Send samme hendelse to ganger. Det skal fortsatt finnes én relevant forretningshandling.
- Lever to oppdateringer i omvendt rekkefølge. Sluttstatus skal være riktig.
- Stopp mottakeren en stund. Den manglende ordren skal kunne finnes igjen.
- La én ordre feile mens andre lykkes. Feilen skal ikke bli borte i en samlet grønn status.
- Kjør en reparasjon på nytt. Det skal ikke gi ny pakke, ny faktura eller ny refusjon.
Test med ufarlige testdata og den aktuelle integrasjonens testmuligheter. Ikke eksperimenter med ekte utsendinger eller tilbakebetalinger for å finne ut om en knapp er trygg.
Hva bør du ta med til Klis?
Ta med systemnavn, hvilke opplysninger som skal flyttes, én konkret ordre og hvor dere mister oversikten. Klis kan hjelpe med å avgrense integrasjonen og avklare hvordan feil skal oppdages og repareres. En god avgrensning sier både hva som skal automatiseres, og hva som fortsatt krever en beslutning.
Velg neste steg
La oss se på mulighetene
Hva vil du få til med nettbutikken?
Legg igjen kontaktinformasjon. Klis følger opp for å avklare behovet og foreslå et konkret neste steg.