På denne side
En ordreopdatering ankommer før hændelsen om oprettelse af ordren. Et andet sted ankommer en betalingshændelse før en tidligere hændelse om et abonnement. Det er tænkte teams med forskellige produkter og dataformater. Begge vil gerne løse problemet ved at sortere leveringer efter ankomsttid.
Det er ikke en rapport om nogen af teamenes hændelser. Eksemplet spørger, om de to fejl har en fælles form, selvom leverandørernes detaljer er forskellige.
En optaget samtale om matematiske forbindelser bemærker, at problemer, der ser forskellige ud, kan dele en nyttig form. At anvende idéen på softwareintegration er en slutning. Den er kun nyttig, hvis fællesformen giver en test, som hvert systems dokumenterede adfærd understøtter.
Fjern navnene, og sæt kontrakterne ind igen
Beskriv først tilfældet uden produktnavne: En hændelse om en ressource kan ankomme efter en senere ændring af samme ressource. En modtager, der forveksler ankomstrækkefølge med tilstandsrækkefølge, kan overskrive nyere oplysninger med ældre.
Undersøg så de to faktiske kontrakter. Shopifys webhook-dokumentation siger, at rækkefølge ikke er garanteret, heller ikke inden for samme emne, og giver et eksempel, hvor en produktopdatering kan leveres før beskeden om produktoprettelse. Stripes webhook-dokumentation siger også, at hændelser ikke nødvendigvis ankommer i den rækkefølge, de blev skabt, og anbefaler at hente manglende objekter, når en forventet tidligere hændelse ikke er ankommet.
Både Shopify og Stripe advarer om, at leveringsrækkefølgen ikke er garanteret. Det fælles spørgsmål er, om sluttilstanden er korrekt; id'er og regler for genopretning skal testes for hver leverandør.
Det spørgsmål, der kan overføres, er: »Hvis denne hændelse ankommer før en beslægtet hændelse, kan vi stadig finde den korrekte aktuelle tilstand?« Svaret om, hvordan det gennemføres, kan ikke flyttes på en antagelse. Shopify dokumenterer headere som X-Shopify-Webhook-Id og tidsstempler. Stripe bruger egne hændelses-id’er og regler for at hente objekter. Et id, som betyder »levering« i ét system, betyder ikke nødvendigvis det samme i et andet.
Vores Brevo-connectorguide handler om et andet sæt detaljer om felter og mapping. De er vigtige for en fungerende integration, men de er ikke universel API-adfærd.
Den fælles form er en egenskab, der skal holde
I en kundesynkronisering kunne den være: Efter behandling afspejler kundeposten i destinationen den godkendte kildes aktuelle tilstand. I betaling kunne den være: En handling, der afhænger af betaling, sker kun når den autoritative betalingstilstand tillader det. Egenskaben beskriver, hvad der skal forblive sandt, selv når hændelser er forsinkede, gentagne eller ufuldstændige.
Skriv fire ting ned, før du vælger en rettelse:
| Spørgsmål | Hvorfor det betyder noget |
|---|---|
| Hvilket id navngiver forretningsobjektet? | Et hændelses-id kan identificere en besked i stedet for kunden eller ordren. |
| Hvilket system ejer den aktuelle tilstand? | Indholdet kan være et øjebliksbillede, en ændring eller kun en henvisning. |
| Hvilken tidsorden kan kilden garantere? | Leveringsrækkefølge er ikke nødvendigvis rækkefølge af tilstand. |
| Hvilken slutkontrol beviser succes? | En modtaget hændelse beviser ikke, at destinationen er korrekt. |
Tabellen hjælper med at tænke; den er ikke en protokol. Svaret om den autoritative kilde afhænger af arbejdsgangen. Et direkte opslag kan være nødvendigt i ét system og forkert i et andet. Nogle hændelser skal bevares som historiske fakta i stedet for at blive kogt ned til det seneste øjebliksbillede.
Genbrug testen, og tilpas derefter løsningen
En lille kontrakttest kan sende beslægtede hændelser i omvendt rækkefølge og spørge, om destinationens sluttilstand stadig er korrekt. En anden kan sende samme levering to gange. Testene viser risikotypen. Leverandørens dokumentation afgør derefter, hvordan hver hændelse identificeres, bekræftes og genoprettes.
Den forskel beskytter mod arkitektur, der blot kopieres. En nøgle til at fjerne dubletter fra ét API kan fejle i et andet. Et tidsstempel med grov præcision kan være for upræcist til at fastslå rækkefølgen. Det kan være nødvendigt at hente det aktuelle objekt til en synkronisering af tilstand, men det kan ikke genskabe alle mellemliggende historiske hændelser. Guiden til at integrere flere forretningsværktøjer begynder med at afgøre, hvilket system der ejer hvert felt; uden det har »nyest« ingen klar betydning.
Der er en grænse for at flytte mønstre. Lignende symptomer kan have forskellige årsager: En manglende post kan skyldes en søgning uden tilladelse, en forsinket webhook, en ugyldig mapping eller en afvist skrivning. Før to tilfælde kaldes ens, skal kildekontrakten, destinationskontrakten og den observerede sluttilstand sammenlignes. Hvis én er forskellig, så behold det fælles spørgsmål og ændr testen.
Metoden hjælper også uden for hændelseslevering. Et felt, som et API accepterer, men som ikke findes i den synlige post, rejser det samme generelle spørgsmål i enhver connector: Hvad beviser kvitteringen, og hvilket bevis viser den tilsigtede tilstand? Svaret kan være en tilbagelæsning fra destinationen, et opslag i skemaet eller en kontrol af tilladelser. Mønsteret siger, at teamet skal skelne mellem transport og betydning. Det siger ikke, hvilket felt eller API-kald de skal bruge. Det er en smallere lære end en universel opskrift, men den kan bruges flere steder, fordi den bevarer de lokale fakta.
Den stærkeste lære at genbruge er ikke et stykke håndteringskode. Det er et spørgsmål, som stadig giver mening i et andet system og gør den lokale kontrakt lettere at undersøge.
Ofte Stillede Spørgsmål
Kan den samme integrationstest genbruges hos forskellige leverandører?
Spørgsmålet kan ofte flyttes, for eksempel om opdateringer kan komme i forkert rækkefølge. Hændelses-id'er, betydningen af indholdet, signaturer og vejen til genopretning skal hentes fra hver leverandørs kontrakt.
Hvad er forskellen på et mønster og en kopieret rettelse?
Et mønster navngiver fejlbetingelsen og den tilstand, der skal bevares. En kopieret rettelse antager uden kontrol, at det andet system bruger samme id'er, rækkefølge og betydning af tilstand.
Hvad skal kontrolleres, efter at en hændelse er behandlet?
Kontrollér destinationens tilstand, som arbejdsgangen kræver, ikke kun at hændelsen blev modtaget eller at HTTP-kaldet lykkedes. Slutbetingelsen afhænger af forretningsobjektet og reglen for den autoritative kilde.