Različni sistemi lahko skrivajo isto obliko napake

Posodobitev naročila prispe pred dogodkom ustvarjanja naročila. Drugje plačilni dogodek prispe pred starejšim dogodkom naročnine. To sta ponazoritveni ekipi z različnimi izdelki in različnimi podatki. Obe mika, da bi težavo popravili z razvrščanjem dostav po času prihoda.

To ni poročilo o incidentu katerekoli ekipe. Vprašanje je, ali imata napaki skupno obliko, čeprav se podrobnosti ponudnikov razlikujejo.

Pregledan pogovor o matematičnih povezavah opaža, da imajo lahko na videz različne težave uporabno skupno obliko. Prenos te misli na programske integracije je sklep. Koristen postane šele, ko skupna oblika ustvari preizkus, ki ga podpre dokumentirano vedenje vsakega sistema.

Odstranite imena, nato vrnite tehnične specifikacije

Prvi primer opišite brez imen izdelkov: dogodek o viru lahko prispe po poznejši spremembi istega vira. Prejemnik, ki vrstni red prihoda obravnava kot vrstni red stanja, lahko novejše informacije prepiše s starejšimi.

Zdaj preglejte obe dejanski tehnični specifikaciji. Shopifyjeva dokumentacija spletnih kavljev pove, da vrstni red ni zagotovljen niti znotraj ene teme, in poda primer, ko posodobitev izdelka prispe pred dostavo dogodka o njegovem nastanku. Stripeova dokumentacija spletnih kavljev prav tako opozarja, da dogodki niso nujno dostavljeni v vrstnem redu nastanka, in svetuje pridobitev manjkajočih objektov, kadar pričakovani starejši dogodek še ni prispel.

Shopify neurejene dostave glave dogodkov Shopify

Skupno vprašanje Je končno stanje pravilno? Preizkusite obrnjen vrstni red

Stripe neurejene dostave ID dogodkov Stripe

Shopify in Stripe opozarjata, da vrstni red dostave ni zagotovljen. Skupno vprašanje je pravilnost končnega stanja; identifikatorji in pravila okrevanja vsakega ponudnika zahtevajo svoj preizkus.

Prenosljivo vprašanje je: „Če ta dogodek prispe pred povezanim dogodkom, ali lahko še vedno določimo pravilno trenutno stanje?“ Izvedbenega odgovora ne smemo samodejno prenesti. Shopify dokumentira glave, kot je X-Shopify-Webhook-Id, in časovne oznake. Stripe uporablja lastne ID dogodkov in pravila za pridobivanje objektov. Identifikator, ki v enem sistemu pomeni „dostavo“, v drugem morda ne pomeni istega.

Naš vodnik za priključek Brevo obravnava ločene podrobnosti polj in preslikav. Te podrobnosti so pomembne za delujočo integracijo, vendar jih ne smete zamenjati za univerzalno vedenje API.

Skupna oblika je lastnost, ki mora ostati resnična

Pri sinhronizaciji strank je ta lastnost lahko: po obdelavi zapis stranke v ciljnem sistemu odraža trenutno stanje izvora, do katerega ima uporabnik dovoljen dostop. Pri obračunavanju je lahko: dejanje, odvisno od plačila, se zgodi le, ko ga dopušča avtoritativno stanje plačila. Lastnost poimenuje tisto, kar mora ostati resnično, tudi če so dogodki pozni, ponovljeni ali nepopolni.

Pred izbiro popravka zapišite štiri stvari:

Vprašanje	Zakaj je pomembno
Katera identiteta označuje poslovni objekt?	ID dogodka lahko označuje sporočilo, ne stranke ali naročila.
Kateri sistem ima v lasti trenutno stanje?	Vsebina dogodka je lahko posnetek stanja, sprememba ali le kazalec.
Kaj lahko vir zagotovi glede časa?	Vrstni red dostave morda ni vrstni red stanja.
Kateri končni pogoj dokazuje uspeh?	Prejem dogodka ne dokazuje pravilnosti ciljnega sistema.

Tabela je pripomoček za razmislek, ne protokol. Vir resnice je odvisen od poteka dela. V enem sistemu je morda potrebna živa poizvedba, v drugem pa neprimerna. Nekatere dogodke je treba ohraniti kot zgodovinska dejstva, ne jih skrčiti na najnovejši posnetek.

Ponovno uporabite preizkus, popravek pa prilagodite

Majhen preizkus tehnične specifikacije lahko povezane dogodke pošlje v obrnjenem vrstnem redu in vpraša, ali je končno stanje v ciljnem sistemu še vedno pravilno. Drugi lahko isto dostavo pošlje dvakrat. Takšna preizkusa pokažeta obliko tveganja. Dokumentacija ponudnika nato določa, kako prepoznati, preveriti in popraviti vsak dogodek.

Razlika ekipo varuje pred arhitekturo s kopiranjem. Ključ za odpravo podvojitev iz enega API lahko pri drugem odpove. Časovna oznaka z grobo natančnostjo morda ne določa vrstnega reda. Pridobitev trenutnega objekta je lahko nujna za sinhronizacijo stanja, vendar ne more obnoviti vsakega vmesnega zgodovinskega dogodka. Vodnik za povezovanje več poslovnih orodij začne z odločitvijo, kateri sistem ima v lasti posamezno polje; brez te odločitve „najnovejše“ nima jasnega pomena.

Prenos vzorca ima mejo. Podobni simptomi imajo lahko različne vzroke: manjkajoč zapis lahko pomeni nedovoljeno poizvedbo, zakasnjen spletni kavelj, napačno preslikavo ali zavrnjen zapis. Preden dva primera razglasite za enaka, primerjajte tehnično specifikacijo izvora in ciljnega sistema in opaženi končni pogoj. Če se kaj razlikuje, ohranite skupno vprašanje, preizkus pa spremenite.

Metoda je uporabna tudi zunaj dostave dogodkov. Polje, ki ga API sprejme, v uporabniku vidnem zapisu pa manjka, pri vsakem priključku odpira isto splošno vprašanje: kaj dokazuje potrditev in kateri dokaz potrdi predvideno stanje? Odgovor lahko zahteva ponovno branje ciljnega sistema, poizvedbo po shemi ali preverjanje dovoljenj. Vzorec ekipi pove, naj loči prenos od pomena. Ne pove pa, katero polje ali končno točko naj pokliče. Ta ožji nauk je manj vznemirljiv od univerzalnega recepta za integracije, vendar potuje dlje, ker ohrani vidna lokalna dejstva.

Najmočnejši prenosljiv nauk ni odlomek kode za obravnavo. Je vprašanje, ki preživi prehod v drug sistem in olajša pregled tamkajšnje tehnične specifikacije.