På denne siden
En ordreoppdatering kommer frem før hendelsen om at ordren ble opprettet. Et annet sted kommer en betalingshendelse før en tidligere abonnementshendelse. Dette er tenkte team med ulike produkter og dataformater. Begge fristes til å rette problemet ved å sortere leveringene etter når de ble mottatt.
Dette er ikke en rapport om hendelser hos noen av teamene. Det er et spørsmål om de to feilene har samme form selv om leverandørdetaljene er ulike.
En samtale om matematiske forbindelser peker på at problemer som virker forskjellige, kan dele en nyttig form. Å bruke ideen på programvareintegrasjoner er en slutning. Den blir nyttig først når den felles formen gir en test som atferden dokumentert for hvert system støtter.
Fjern navnene, og legg kontraktene tilbake
Beskriv første tilfelle uten produktnavn: En hendelse om en ressurs kan komme frem etter en senere endring i samme ressurs. En mottaker som behandler rekkefølgen på leveringer som rekkefølgen på tilstander, kan skrive over ny informasjon med gammel.
Undersøk så de to faktiske kontraktene. Shopifys dokumentasjon om webhooks sier at rekkefølgen ikke er garantert, selv innenfor et emne, og viser et eksempel der en produktoppdatering kan komme frem før leveringen av produktets opprettelse. Stripes dokumentasjon om webhooks sier også at hendelser ikke nødvendigvis kommer frem i samme rekkefølge som de ble opprettet, og anbefaler å hente objekter som mangler når en forventet tidligere hendelse ikke er kommet.
Både Shopify og Stripe advarer om at leveringsrekkefølgen ikke er garantert. Det felles spørsmålet er om sluttilstanden er riktig. Identifikatorer og regler for retting må testes for hver leverandør.
Spørsmålet som kan overføres, er: «Hvis denne hendelsen kommer før en beslektet hendelse, kan vi likevel finne riktig gjeldende tilstand?» Svaret om implementasjon kan ikke antas å være det samme. Shopify dokumenterer HTTP-headere som X-Shopify-Webhook-Id og tidsstempler. Stripe bruker egne hendelses-ID-er og regler for å hente objekter. En identifikator som betyr «levering» i ett system, betyr kanskje noe annet i et annet.
Vår guide til Brevo-koblinger beskriver egne detaljer om felt og mapping. De er viktige for en fungerende integrasjon, men må ikke forveksles med universell API-atferd.
Den felles formen er en betingelse som må holde
For en kundesynkronisering kan betingelsen være at kundeposten i målsystemet etter behandling gjenspeiler den gjeldende tilstanden i den autoriserte kilden. For fakturering kan den være at en handling som avhenger av betaling, bare skjer når den autoritative betalingsstatusen tillater det. Betingelsen navngir det som må være sant selv når hendelser er sene, gjentatte eller ufullstendige.
Skriv ned fire ting før du velger en rettelse:
| Spørsmål | Hvorfor det betyr noe |
|---|---|
| Hvilken identitet navngir forretningsobjektet? | En hendelses-ID kan identifisere en melding i stedet for en kunde eller ordre. |
| Hvilket system eier gjeldende tilstand? | Dataene kan være et øyeblikksbilde, en endring eller bare en peker. |
| Hva kan kilden garantere om tid? | Leveringsrekkefølge er kanskje ikke tilstandsrekkefølge. |
| Hvilken sluttbetingelse beviser suksess? | At en hendelse ble mottatt, beviser ikke at målsystemet er riktig. |
Tabellen hjelper oss å tenke; den er ingen protokoll. Svaret på hvilken kilde som er fasit, avhenger av arbeidsflyten. Et oppslag av gjeldende tilstand kan være nødvendig i ett system og feil i et annet. Noen hendelser må bevares som historiske fakta i stedet for å slås sammen til det nyeste øyeblikksbildet.
Gjenbruk testen, tilpass løsningen
En liten kontraktstest kan sende beslektede hendelser i omvendt rekkefølge og spørre om sluttilstanden i målsystemet fortsatt er riktig. En annen kan sende samme levering to ganger. Testene viser formen på risikoen. Dokumentasjonen fra leverandøren avgjør så hvordan hver hendelse skal identifiseres, verifiseres og håndteres ved feil.
Skillet beskytter team mot arkitektur bygget på kopiering og liming. En nøkkel for å fjerne duplikater fra ett API kan feile i et annet. Et tidsstempel med grov presisjon kan ikke nødvendigvis avgjøre rekkefølgen. Å hente gjeldende objekt kan være nødvendig for en tilstandssynkronisering, men kan ikke gjenskape hver mellomliggende historiske hendelse. Guiden til å integrere flere bedriftsverktøy begynner med å avgjøre hvilket system som eier hvert felt. Uten det valget har «nyest» ingen klar betydning.
Det finnes en grense for å overføre mønstre. Like symptomer kan ha ulike årsaker: En manglende post kan skyldes et søk uten tillatelse, en forsinket webhook, en ugyldig mapping eller en avvist skriving. Før du erklærer to tilfeller like, sammenlign kildekontrakten, kontrakten til målsystemet og den observerte sluttbetingelsen. Hvis noe er ulikt, behold det felles spørsmålet, men endre testen.
Metoden er nyttig også utenfor hendelseslevering. Et felt som ble godkjent av et API, men ikke vises på posten brukeren ser, reiser samme generelle spørsmål i enhver kobling: Hva beviser en kvittering, og hva beviser den tilsiktede tilstanden? Svaret kan kreve lesing fra målsystemet, oppslag i et skjema eller en tillatelsessjekk. Mønsteret forteller teamet at transport og mening må skilles. Det forteller ikke hvilket felt eller endepunkt det skal bruke. Denne smalere lærdommen er mindre spennende enn en universell oppskrift, men mer nyttig fordi lokale fakta fortsatt er synlige.
Den sterkeste lærdommen du kan gjenbruke, er ikke en kodebit. Det er et spørsmål som fortsatt gir mening i et annet system og gjør den lokale kontrakten enklere å undersøke.
Ofte Stilte Spørsmål
Kan samme integrasjonstest brukes hos flere leverandører?
Spørsmålet kan ofte overføres, for eksempel om oppdateringer kan komme i feil rekkefølge. Hendelses-ID-er, betydningen av dataene, signaturer og veier til retting må tas fra kontrakten til hver leverandør.
Hva skiller et mønster fra en kopiert rettelse?
Et mønster beskriver feilsituasjonen og betingelsen som må være sann. En kopiert rettelse antar uten kontroll at det andre systemet har samme identifikatorer, rekkefølge og betydning av tilstand.
Hva bør sjekkes etter at en hendelse er brukt?
Sjekk tilstanden i målsystemet som arbeidsflyten krever, ikke bare at hendelsen ble mottatt eller HTTP-svaret. Sluttbetingelsen avhenger av forretningsobjektet og regelen for hvilken kilde som er fasit.