API · INTEGRACIJE · ZANESLJIVOST · 11 MIN BRANJA
Zanesljiva integracija ni skripta, ki deluje na predstavitvenih podatkih. Je produkcijski tok, ki prepozna in zabeleži napako ter omogoči obnovitev po njej.
Najprej določite lastništvo podatkov
Za vsako entiteto bi moral obstajati avtoritativni sistem. En sistem je lahko lastnik gosta, drugi rezervacije, tretji finančnega dokumenta. Če oba konca prosto spreminjata isto polje, postane sinhronizacija tekmovanje, kjer zmaga zadnji zapis brez poslovnega razloga.
Pred pisanjem kode se dogovorite o smeri, identifikatorjih in pravilih preslikave. Zlasti dokumentirajte vrednosti, ki ne obstajajo na obeh straneh, in kako se obravnavajo neznani statusi.
Vsaka pomembna operacija mora biti idempotentna
Omrežje lahko prekine odgovor, potem ko je druga stran že obdelala zahtevo. Pošiljatelj potem ne ve, ali je bila operacija uspešna in mora poskusiti znova. Če vnovična predložitev ustvari novo rezervacijo ali bremenitev, integracija ni varna.
Ključ idempotence, zunanji identifikator in dnevnik obdelanih dogodkov omogočajo prepoznavanje iste zahteve in vrnejo obstoječi rezultat. To je bistveno za rezervacije, plačila, račune in spremembe inventarja.
Ponovni poskus brez idempotence ni mehanizem zanesljivosti; gre za možnost podvajanja poslovnega dogodka.
Ni nujno, da je vse sinhrono
Uporabniku ni treba čakati, da pet zunanjih storitev potrdi interni zapis. Pogosto je bolje shraniti osnovno transakcijo, objaviti dogodek in povezane korake obdelati v ozadju. Čakalna vrsta sporočil ohrani delo za obdelavo, dokler zunanji sistem ni na voljo.
Sinhroni klic uporabite, ko je odgovor nujen za naslednjo odločitev uporabnika, na primer končno potrditev razpoložljivosti. Za obvestila, sinhronizacijo CRM ali analitiko asinhroni tok zmanjša medsebojno odvisnost sistemov.
Ponovni poskus bi moral imeti omejitve
Pri začasnih napakah so smiselni ponovni poskusi z vse daljšim zamikom. Napaka pri validaciji, neznana enota ali zavrnjena avtorizacija ne bodo izginile po desetih enakih poskusih. Integracija mora ločiti prehodne napake od trajnih.
Po določenem številu ponovnih poskusov gre sporočilo v nadzorovano čakalno vrsto za obdelavo napak. Oseba mora imeti dovolj konteksta, da razume težavo in po popravku znova zažene obdelavo.
Dnevnik ni dovolj brez poslovnega konteksta
Tehnični zapis »HTTP 400« redko pomaga operativni ekipi. Napako je treba povezati z rezervacijo, objektom, kanalom in konkretnim korakom. Nadzorna plošča mora pokazati uspešna in neuspešna sporočila, zamude v čakalni vrsti ter ponavljajoče se vzroke.
Korelacijski identifikator v vseh storitvah skrajša diagnostiko. Občutljivi podatki in poverilnice se ne smejo zapisovati v dnevnike.
Pogodba API se spreminja
Zunanji sistem lahko doda status, spremeni omejitev ali ukine različico končne točke API. Integracija mora dopuščati neznana dodatna polja, a jasno opozoriti na manjkajoč obvezen podatek. Preizkusi pogodbe API in testno okolje pomagajo odkriti spremembo pred produkcijsko uporabo.
Različice, roki in lastnik integracije morajo biti dokumentirani. "Ko je enkrat povezan" ne pomeni trajno dokončan; Integracija API-jev je razmerje med dvema produktoma, ki se razvijata različno hitro.
Osnovni kontrolni seznam pred produkcijsko uporabo
Pred uvedbo preverite avtentikacijo in rotacijo skrivnosti, časovne omejitve, pravila ponovnih poskusov, idempotenco, omejitve zahtev, preslikavo identifikatorjev, revizijski dnevnik, alarme in ročno obnovitev. Preizkusite podvojena sporočila, sporočila v napačnem vrstnem redu in nedostopno zunanjo storitev, ne le idealnega toka.
Integracija je uspešna, ko ekipa ne prepisuje več podatkov, izjeme pa so manj pogoste in bolj vidne. Če vsakodnevno delo zahteva novo tabelo »za spremljanje neprenesenega«, sistem še ni dokončan.