Na tejto stránke
Aktualizácia objednávky dorazí pred udalosťou o jej vytvorení. Inde príde platobná udalosť pred skoršou udalosťou predplatného. Ide o ilustratívne tímy používajúce rôzne produkty a dáta udalostí. Obe láka opraviť problém zoradením doručení podľa času príchodu.
Toto nie je správa o incidente ani jedného tímu. Je to otázka, či majú dve zlyhania spoločný tvar napriek odlišným detailom poskytovateľov.
Načítaný rozhovor o matematických súvislostiach poznamenáva, že zdanlivo odlišné problémy môžu mať spoločnú užitočnú formu. Použiť túto myšlienku pri softvérovej integrácii je odvodenie. Užitočné je až vtedy, keď spoločná forma vytvorí test podporený zdokumentovaným správaním každého systému.
Odstráňte názvy a potom vráťte kontrakty
Prvý prípad opíšte bez názvov produktov: udalosť o zdroji môže doraziť po neskoršej zmene toho istého zdroja. Príjemca, ktorý považuje poradie príchodu za poradie stavov, môže staršími informáciami prepísať novšie.
Teraz preskúmajte oba skutočné kontrakty. Dokumentácia webhookov Shopify hovorí, že poradie nie je zaručené ani v rámci jednej témy, a uvádza príklad, keď aktualizácia produktu môže byť doručená pred jeho vytvorením. Dokumentácia webhookov Stripe tiež hovorí, že udalosti nemusia prísť v poradí vzniku, a odporúča načítať chýbajúce objekty, ak očakávaná skoršia udalosť nedorazila.
Shopify aj Stripe upozorňujú, že poradie doručenia udalostí nie je zaručené. Spoločnou otázkou je správnosť konečného stavu; identifikátory a pravidlá nápravy každého poskytovateľa potrebujú vlastný test.
Prenositeľná otázka znie: „Ak táto udalosť dorazí pred súvisiacou udalosťou, dokážeme stále odvodiť správny aktuálny stav?“ Implementačná odpoveď sa nesmie prenášať na základe predpokladu. Shopify dokumentuje hlavičky ako X-Shopify-Webhook-Id a časové značky. Stripe používa vlastné ID udalostí a pravidlá načítania objektov. Identifikátor, ktorý v jednom systéme znamená „doručenie“, nemusí znamenať to isté v druhom.
Náš sprievodca konektorom Brevo rieši samostatné detaily polí a mapovania. Pre funkčnú integráciu sú dôležité, no nemožno ich zamieňať za všeobecné správanie API.
Spoločný tvar je nemenná podmienka
Pri synchronizácii zákazníkov môže nemenná podmienka znieť: po spracovaní cieľový zákaznícky záznam odráža aktuálny stav povoleného zdroja. Pri fakturácii môže znieť: krok závislý od platby nastane len vtedy, keď ho povoľuje autoritatívny platobný stav. Podmienka pomenuje, čo musí zostať pravdivé aj pri oneskorených, opakovaných či neúplných udalostiach.
Pred výberom opravy zapíšte štyri veci:
| Otázka | Prečo na nej záleží |
|---|---|
| Ktorá identita pomenúva obchodný objekt? | ID udalosti môže určovať správu, nie zákazníka či objednávku. |
| Ktorý systém vlastní aktuálny stav? | Obsah udalosti môže byť snímkou, zmenou alebo iba odkazom. |
| Aké časovanie môže zdroj zaručiť? | Poradie doručenia nemusí byť poradím stavov. |
| Ktorá podmienka výsledku dokazuje úspech? | Prijatie udalosti nedokazuje správny stav cieľa. |
Tabuľka je pomôcka na uvažovanie, nie protokol. Odpoveď o zdroji pravdy závisí od pracovného postupu. V jednom systéme môže byť nutné živé vyhľadanie, v inom nevhodné. Niektoré udalosti treba zachovať ako historické fakty, nie zredukovať na najnovšiu snímku.
Preneste test, potom prispôsobte nápravu
Malý test kontraktu môže doručiť súvisiace udalosti v opačnom poradí a overiť, či konečný cieľový stav zostane správny. Ďalší môže tú istú udalosť doručiť dvakrát. Testy odhaľujú tvar rizika. Dokumentácia poskytovateľa potom určuje, ako každú udalosť identifikovať, overiť a napraviť.
Toto rozlíšenie chráni pred kopírovaním celej architektúry. Kľúč na odstránenie duplicít z jedného API môže zlyhať v inom. Časová značka s hrubou presnosťou nemusí určiť poradie. Načítanie aktuálneho objektu môže byť nutné pre synchronizáciu stavu, ale nedokáže obnoviť každú priebežnú historickú udalosť. Sprievodca integráciou viacerých podnikových nástrojov začína rozhodnutím, ktorý systém vlastní každé pole; bez tejto voľby nemá „najnovší“ jasný význam.
Prenos vzorcov má hranice. Podobné príznaky môžu mať odlišné príčiny: chýbajúci záznam môže znamenať nepovolený dotaz, oneskorený webhook, neplatné mapovanie alebo odmietnutý zápis. Skôr než dva prípady vyhlásite za rovnocenné, porovnajte kontrakt zdroja, kontrakt cieľa a pozorovanú podmienku výsledku. Ak sa niečo líši, spoločnú otázku si ponechajte a test zmeňte.
Metóda je užitočná aj mimo doručovania udalostí. Pole prijaté API, no chýbajúce v zázname viditeľnom pre používateľa, kladie v každom konektore podobnú všeobecnú otázku: čo dokazuje potvrdenie požiadavky a ktorý dôkaz potvrdzuje zamýšľaný stav? Odpoveď môže vyžadovať čítanie cieľa, kontrolu schémy alebo oprávnení. Vzorec tímu hovorí, aby oddelil prenos od významu. Nehovorí mu, ktoré pole alebo koncový bod má zavolať. Toto užšie poučenie nie je také pôsobivé ako univerzálny recept na integrácie, no prenáša sa ďalej, pretože ponecháva miestne fakty viditeľné.
Najsilnejším prenositeľným poučením nie je úryvok obslužného kódu. Je to otázka, ktorá prežije presun do iného systému a uľahčí preskúmanie jeho kontraktu.
Často Kladené Otázky
Dá sa ten istý integračný test použiť pri viacerých poskytovateľoch?
Často sa dá preniesť otázka, napríklad či aktualizácie môžu prísť v nesprávnom poradí. ID udalostí, význam dát, podpisy a postupy nápravy treba prevziať z kontraktu každého poskytovateľa.
Aký je rozdiel medzi vzorcom a skopírovanou opravou?
Vzorec pomenuje podmienku zlyhania a vlastnosť, ktorá musí zostať zachovaná. Skopírovaná oprava bez overenia predpokladá, že druhý systém má rovnaké identifikátory, poradie a význam stavov.
Čo kontrolovať po spracovaní udalosti?
Skontrolujte cieľový stav požadovaný pracovným postupom, nie iba prijatie udalosti alebo odpoveď HTTP. Podmienka úspechu závisí od obchodného objektu a pravidla zdroja pravdy.