Na ovoj stranici
Izmena porudžbine stiže pre događaja njenog stvaranja. Drugde događaj plaćanja stiže pre starijeg događaja pretplate. To su ilustrativni timovi sa različitim proizvodima i sadržajem događaja. Oba tima bi mogla pokušati da problem poprave sortiranjem po vremenu dolaska.
Ovo nije izveštaj o incidentu nijednog tima. Pita da li greške imaju zajednički oblik iako se detalji dobavljača razlikuju.
Pregledan razgovor o matematičkim vezama primećuje da naizgled različiti problemi mogu imati korisnu zajedničku formu. Primena na softverske integracije je zaključak. Korisna je tek kada zajednička forma proizvede test koji podržava dokumentovano ponašanje svakog sistema.
Uklonite imena, pa vratite ugovore
Prvi slučaj opišite bez naziva proizvoda: događaj o resursu može stići posle kasnije promene istog resursa. Primalac koji redosled dolaska tretira kao redosled stanja može novije podatke prepisati starijim.
Zatim pogledajte oba stvarna ugovora. Shopify dokumentacija o veb-kukovima kaže da redosled nije garantovan ni unutar jedne teme i daje primer u kome izmena proizvoda može stići pre događaja o njegovom stvaranju. Stripe dokumentacija takođe kaže da događaji ne moraju stići redosledom nastanka i preporučuje preuzimanje nedostajućih objekata kada raniji očekivani događaj još nije stigao.
Shopify i Stripe upozoravaju da redosled dostave nije garantovan. Zajedničko pitanje je tačnost konačnog stanja; identifikatori i pravila oporavka traže poseban test.
Prenosivo pitanje je: „Ako ovaj događaj stigne pre povezanog, možemo li ipak dobiti tačno trenutno stanje?“ Rešenje za sprovođenje ne prenosi se po pretpostavci. Shopify dokumentuje zaglavlja poput X-Shopify-Webhook-Id i vremenske oznake. Stripe ima svoje ID događaja i pravila za preuzimanje objekata. Identifikator koji u jednom sistemu znači „dostava“ u drugom možda ne znači isto.
Naš vodič za Brevo konektor obrađuje drugačije detalje polja i mapiranja. Oni jesu važni za radnu integraciju, ali nisu univerzalno API ponašanje.
Zajednički oblik je svojstvo koje ostaje tačno
Za sinhronizaciju kupaca to svojstvo može glasiti: posle obrade, zapis kupca u odredištu odražava trenutno stanje dozvoljenog izvora. Za naplatu može glasiti: radnja koja zavisi od plaćanja događa se samo kada je autoritativno stanje plaćanja dopušta. Svojstvo imenuje šta mora ostati tačno kada su događaji zakasneli, ponovljeni ili nepotpuni.
Pre izbora popravke zapišite četiri stvari:
| Pitanje | Zašto je važno |
|---|---|
| Koji identitet označava poslovni objekat? | ID događaja može označavati poruku, ne kupca ili porudžbinu. |
| Koji sistem poseduje trenutno stanje? | Sadržaj događaja može biti snimak, promena ili samo pokazivač. |
| Koje vreme izvor može da garantuje? | Redosled dostave možda nije redosled stanja. |
| Koji konačni uslov dokazuje uspeh? | Prijem događaja ne dokazuje da je odredište tačno. |
Tabela pomaže razmišljanju; nije protokol. Izvor istine zavisi od toka rada. Živo čitanje možda je nužno u jednom sistemu, a pogrešno u drugom. Neki događaji moraju se sačuvati kao istorijske činjenice, ne svesti na najnoviji snimak stanja.
Ponovite test, prilagodite lek
Mali test ugovora može poslati povezane događaje obrnutim redosledom i pitati da li je konačno stanje u odredištu i dalje tačno. Drugi može poslati istu dostavu dva puta. Testovi otkrivaju oblik rizika. Dokumentacija dobavljača zatim određuje kako svaki događaj prepoznati, proveriti i obnoviti.
Ta razlika štiti od arhitekture nastale preslikavanjem. Ključ za uklanjanje duplikata iz jednog API-ja može zakazati u drugom. Vremenska oznaka grube preciznosti možda ne uspostavlja redosled. Preuzimanje trenutnog objekta može biti nužno za sinhronizaciju stanja, ali ne može rekonstruisati svaki međudogađaj u istoriji. Vodič za integraciju više poslovnih alata počinje određivanjem sistema koji poseduje svako polje; bez toga „najnovije“ nema jasnog značenja.
Prenos obrasca ima granicu. Slični simptomi mogu imati različite uzroke: zapis koji nedostaje može značiti neovlašćen upit, zakasneli veb-kuk, nevažeće mapiranje ili odbijen upis. Pre nego što dva slučaja proglasite istim, uporedite ugovor izvora, ugovor odredišta i uočeni konačni uslov. Ako se nešto razlikuje, zadržite zajedničko pitanje, a promenite test.
Metod je koristan i van dostave događaja. Polje koje API prihvati, a koje nedostaje u vidljivom zapisu, u svakom konektoru postavlja isto opšte pitanje: šta potvrda dokazuje i koji dokaz potvrđuje željeno stanje? Odgovor može tražiti ponovno čitanje odredišta, upit šeme ili proveru dozvola. Obrazac kaže timu da razlikuje transport od značenja. Ne govori koje polje ili krajnju tačku da pozove. Ta uža pouka je manje uzbudljiva od univerzalnog recepta, ali dalje putuje jer lokalne činjenice ostavlja vidljivim.
Najjača ponovo upotrebljiva pouka nije isečak koda. To je pitanje koje preživi prelazak u drugi sistem i olakša pregled tamošnjeg ugovora.
Često Postavljana Pitanja
Može li se isti test integracije primeniti kod različitih dobavljača?
Pitanje se često prenosi, na primer mogu li izmene stići van redosleda. ID događaja, značenje sadržaja, potpise i oporavak morate uzeti iz ugovora svakog dobavljača.
Koja je razlika između obrasca i preslikane popravke?
Obrazac imenuje uslov greške i svojstvo koje treba sačuvati. Preslikana popravka bez provere pretpostavlja da drugi sistem ima iste identifikatore, redosled i značenje stanja.
Šta proveriti nakon obrade događaja?
Proverite stanje odredišta koje tok zahteva, ne samo prijem događaja ili HTTP odgovor. Konačni uslov zavisi od poslovnog objekta i pravila o izvoru istine.