Na ovoj stranici
Ažuriranje narudžbe stiže prije događaja stvaranja narudžbe. Drugdje događaj plaćanja stiže prije ranijeg događaja pretplate. To su ilustrativni timovi koji koriste različite proizvode i sadržaje poruka. Oba su u iskušenju popraviti problem razvrstavanjem isporuka po vremenu dolaska.
To nije izvještaj o incidentu bilo kojeg tima. Pitanje je imaju li dvije pogreške isti oblik iako se detalji dobavljača razlikuju.
Zabilježen razgovor o matematičkim vezama primjećuje da naizgled različiti problemi mogu dijeliti koristan oblik. Primjena te ideje na softverske integracije naš je zaključak. Korisna je samo kada zajednički oblik daje test koji podupire dokumentirano ponašanje svakog sustava.
Uklonite nazive, pa vratite ugovore
Prvi slučaj opišite bez naziva proizvoda: događaj o resursu može stići nakon kasnije promjene istog resursa. Primatelj koji redoslijed dolaska smatra redoslijedom stanja može novije podatke prepisati starijima.
Sada pregledajte oba stvarna ugovora. Shopifyjeva dokumentacija webhooks kaže da redoslijed nije zajamčen, čak ni unutar jedne teme, i daje primjer ažuriranja proizvoda koje može stići prije dostave događaja njegova stvaranja. Stripeova dokumentacija webhooks također kaže da događaji ne moraju stići redom kojim su nastali i preporučuje dohvat objekata koji nedostaju kada očekivani raniji događaj nije stigao.
Shopify i Stripe upozoravaju da redoslijed dostave nije zajamčen. Zajedničko je pitanje ostaje li završno stanje točno; identifikatori i pravila oporavka svakog dobavljača trebaju vlastiti test.
Pitanje koje se prenosi glasi: „Ako ovaj događaj stigne prije povezanoga, možemo li ipak odrediti ispravno trenutačno stanje?” Odgovor provedbe ne prenosi se po pretpostavci. Shopify dokumentira zaglavlja kao X-Shopify-Webhook-Id i vremenske oznake. Stripe koristi vlastite ID-jeve događaja i pravila dohvata objekata. Identifikator koji u jednom sustavu znači „isporuka” ne mora imati isto značenje u drugome.
Naš vodič za Brevo poveznik bavi se zasebnim detaljima polja i mapiranja. Važni su za funkcionalnu integraciju, ali nisu univerzalno ponašanje API-ja.
Zajednički obrazac je svojstvo koje mora ostati istinito
Za sinkronizaciju kupaca to svojstvo može biti: nakon obrade, odredišni zapis kupca odražava trenutačno stanje izvora ovlaštenog za određivanje tog stanja. Za naplatu može biti: radnja ovisna o plaćanju događa se samo kada to dopušta mjerodavno stanje plaćanja. Svojstvo imenuje što mora vrijediti i kada su događaji zakašnjeli, ponovljeni ili nepotpuni.
Prije odabira popravka zapišite četiri stvari:
| Pitanje | Zašto je važno |
|---|---|
| Koji identitet označuje poslovni objekt? | ID događaja možda označuje poruku, ne kupca ili narudžbu. |
| Koji sustav određuje trenutačno stanje? | Sadržaj događaja može biti snimka, promjena ili samo pokazivač. |
| Što izvor može jamčiti o vremenu? | Redoslijed isporuke ne mora biti redoslijed stanja. |
| Koji završni uvjet dokazuje uspjeh? | Primitak događaja ne dokazuje da je odredište ispravno. |
Tablica pomaže razmišljanju, nije protokol. Izvor istine ovisi o tijeku. U jednom sustavu možda treba svjež dohvat, u drugom bi bio neprikladan. Neki događaji moraju ostati kao povijesne činjenice, a ne biti svedeni na najnoviju snimku.
Ponovno upotrijebite test, pa prilagodite lijek
Mali ugovorni test može poslati povezane događaje obrnutim redom i pitati je li završno stanje odredišta i dalje ispravno. Drugi može istu isporuku poslati dvaput. Ti testovi otkrivaju oblik rizika. Dokumentacija dobavljača zatim određuje kako svaki događaj identificirati, provjeriti i oporaviti.
Ta razlika štiti tim od arhitekture kopiranja. Ključ za uklanjanje duplikata iz jednog API-ja može zakazati u drugome. Vremenska oznaka grube preciznosti možda ne utvrđuje red. Dohvat trenutačnog objekta može biti nužan za sinkronizaciju stanja, ali ne može obnoviti svaki međupovijesni događaj. Vodič za integraciju poslovnih alata počinje odabirom sustava koji određuje svako polje; bez toga „najnovije” nema jasno značenje.
Prijenos obrasca ima granice. Slični simptomi mogu imati različite uzroke: zapis koji nedostaje može značiti neautoriziran upit, zakasnjeli webhook, nevaljano mapiranje ili odbijeno zapisivanje. Prije nego što dva slučaja proglasite istima, usporedite ugovor izvora, ugovor odredišta i opaženi završni uvjet. Ako se jedan razlikuje, zadržite zajedničko pitanje i promijenite test.
Metoda je korisna i izvan isporuke događaja. Polje koje API prihvati, ali nedostaje u zapisu vidljivom korisniku, u svakom povezniku postavlja isto opće pitanje: što potvrda prijema dokazuje, a koji dokaz potvrđuje željeno stanje? Odgovor može tražiti čitanje odredišta, dohvat sheme ili provjeru dopuštenja. Obrazac govori timu da odvoji prijenos od značenja. Ne govori koje polje ili endpoint pozvati. Ta uža pouka manje je uzbudljiva od univerzalnog recepta za integraciju, ali putuje dalje jer čuva lokalne činjenice.
Najjača ponovljivo korisna pouka nije isječak koda. To je pitanje koje ostaje korisno u drugom sustavu i olakšava pregled njegova ugovora.
Često postavljana pitanja
Može li se isti integracijski test koristiti kod različitih dobavljača?
Pitanje se često može prenijeti, primjerice stižu li ažuriranja izvan redoslijeda. ID-jeve događaja, značenje sadržaja poruke, potpise i postupke oporavka treba uzeti iz ugovora svakog dobavljača.
Koja je razlika između obrasca i kopiranog popravka?
Obrazac imenuje uvjet pogreške i svojstvo koje treba očuvati. Kopirani popravak bez provjere pretpostavlja da drugi sustav ima iste identifikatore, redoslijed i značenje stanja.
Što provjeriti nakon primjene događaja?
Provjerite stanje odredišta koje tijek zahtijeva, ne samo primitak događaja ili HTTP odgovor. Završni uvjet ovisi o poslovnom objektu i pravilu izvora istine.