Ezen az oldalon
Egy rendelésfrissítés a rendelés létrehozásáról szóló esemény előtt érkezik. Másutt fizetési esemény érkezik egy korábbi előfizetési esemény előtt. Képzeletbeli csapatokról van szó, amelyek különböző termékeket és üzenettartalmakat használnak. Mindkettőnek csábító a kézbesítéseket érkezési idő szerint sorba rendezni.
Ez nem beszámoló egyik csapat tényleges hibájáról sem. Azt kérdezi, lehet-e közös alakja a két hibának, noha a szolgáltatói részleteik eltérnek.
Egy feldolgozott beszélgetés matematikai összefüggésekről megjegyzi, hogy látszólag különböző problémák hasznos közös formát hordozhatnak. Az ötlet szoftverintegrációra alkalmazása következtetés. Csak akkor hasznos, ha a közös forma olyan tesztet ad, amelyet mindegyik rendszer dokumentált viselkedése alátámaszt.
Hagyd el a neveket, majd hozd vissza a szerződéseket
Írd le az első esetet terméknevek nélkül: egy erőforrásról szóló esemény ugyanannak az erőforrásnak egy későbbi változása után érkezhet meg. Ha a fogadó az érkezési sorrendet állapotsorrendnek tekinti, a frissebb információt felülírhatja a régebbivel.
Most nézd meg a két valódi szerződést. A Shopify webhook-dokumentációja szerint a sorrend még egy témán belül sem garantált, és olyan példát ad, amelyben termékfrissítés érkezhet a termék létrehozásáról szóló kézbesítés előtt. A Stripe webhook-dokumentációja szintén jelzi, hogy az események nem feltétlenül keletkezési sorrendben érkeznek, és hiányzó előzmény esetén a hiányzó objektum lekérését javasolja.
A Shopify és a Stripe is figyelmeztet, hogy a kézbesítési sorrend nem garantált. A közös kérdés: helyes-e a végállapot? Az azonosítókat és helyreállítási szabályokat külön kell tesztelni.
Az átvihető kérdés: „Ha ez az esemény egy kapcsolódó másik előtt érkezik, akkor is levezethető a helyes aktuális állapot?” A megvalósítás válasza nem vihető át feltételezésből. A Shopify olyan fejléceket dokumentál, mint az X-Shopify-Webhook-Id, valamint időbélyegeket. A Stripe saját eseményazonosítókat és objektumlekérési szabályokat használ. Ami az egyikben „kézbesítést” azonosít, a másikban mást jelenthet.
A Brevo-csatlakozóról szóló útmutatónk külön mező- és leképezési részleteket tárgyal. Ezek fontosak a működő integrációhoz, de nem tekinthetők általános API-viselkedésnek.
A közös alak egy megőrzendő feltétel
Vásárlói szinkronizálásnál a feltétel lehet: feldolgozás után a célrendszer vásárlói rekordja a megengedett mértékadó forrás aktuális állapotát tükrözi. Számlázásnál lehet: fizetéstől függő művelet csak akkor történik, ha a mértékadó fizetési állapot engedi. A feltétel azt nevezi meg, aminek késő, ismételt vagy hiányos események mellett is igaznak kell maradnia.
Javítás választása előtt írj le négy dolgot:
| Kérdés | Miért fontos? |
|---|---|
| Melyik azonosító nevezi meg az üzleti objektumot? | Az eseményazonosító az üzenetet jelölheti, nem a vásárlót vagy rendelést. |
| Melyik rendszer birtokolja az aktuális állapotot? | Az üzenettartalom lehet pillanatkép, változás vagy csak hivatkozás. |
| Milyen időzítést garantál a forrás? | A kézbesítési sorrend eltérhet az állapot sorrendjétől. |
| Milyen utófeltétel bizonyítja a sikert? | Az esemény megérkezése nem bizonyítja a célállapot helyességét. |
Ez gondolkodási segédlet, nem protokoll. A mértékadó forrás a munkafolyamattól függ. Az egyik rendszerben élő lekérés kellhet, a másikban helytelen lenne. Néhány eseményt történeti tényként meg kell őrizni, nem összevonni a legfrissebb pillanatképpel.
A tesztet használd újra, a javítást igazítsd hozzá
Egy kis szerződésteszt kapcsolódó eseményeket fordított sorrendben küldhet, és megvizsgálhatja, helyes-e a végső célállapot. Egy másik kétszer küldi ugyanazt a kézbesítést. A tesztek megmutatják a kockázat alakját. Ezután a szolgáltatói dokumentáció határozza meg az azonosítás, ellenőrzés és helyreállítás módját.
Ez a különbség védi a csapatot a másolással épített architektúrától. Az egyik API duplikációs kulcsa a másikban elbukhat. A durva felbontású időbélyeg nem feltétlenül ad sorrendet. Az aktuális objektum lekérése kellhet egy állapotszinkronizáláshoz, de nem állíthat helyre minden köztes történeti eseményt. Az üzleti eszközök integrálásáról szóló útmutató azzal kezd, melyik rendszer birtokolja az egyes mezőket; enélkül a „legújabbnak” nincs tiszta jelentése.
A minták átvitelének is van határa. Hasonló tüneteknek eltérő oka lehet: a hiányzó rekord mögött jogosulatlan lekérés, késő webhook, hibás leképezés vagy elutasított írás állhat. Mielőtt egyenértékűnek nevezel két esetet, hasonlítsd össze a forrás és a cél szerződését, valamint a megfigyelt utófeltételt. Ha egyik különbözik, tartsd meg a közös kérdést, de változtasd meg a tesztet.
A módszer az eseménykézbesítésen túl is hasznos. Az API által befogadott, de a felhasználói rekordból hiányzó mező bármely csatlakozónál ugyanazt az általános kérdést veti fel: mit bizonyít a visszaigazolás, és mi bizonyítja a kívánt állapotot? A válasz lehet célrendszerbeli olvasás, sémalekérés vagy jogosultsági ellenőrzés. A minta arra tanít, hogy a szállítást válaszd szét a jelentéstől. Nem mondja meg, melyik mezőt vagy végpontot hívd. Ez a szűkebb tanulság kevésbé látványos egy univerzális integrációs receptnél, de messzebbre jut, mert a helyi tényeket láthatóan hagyja.
A legerősebb újrahasználható tanulság nem egy kezelőkód-részlet. Hanem egy kérdés, amely másik rendszerben is érvényes, és megkönnyíti a helyi szerződés vizsgálatát.
Gyakran Ismételt Kérdések
Ugyanaz az integrációs teszt több szolgáltatónál is használható?
A kérdés gyakran átvihető, például hogy érkezhetnek-e a frissítések fordított sorrendben. Az eseményazonosítót, a tartalom jelentését, az aláírásokat és a helyreállítás lépéseit viszont minden szolgáltató saját szerződéséből kell venni.
Mi a különbség a minta és a lemásolt javítás között?
A minta megnevezi a hiba feltételét és a megőrzendő szabályt. A lemásolt javítás ellenőrzés nélkül feltételezi, hogy a második rendszerben ugyanazok az azonosítók, sorrendek és állapotjelentések.
Mit ellenőrizzünk egy esemény alkalmazása után?
A munkafolyamat által megkövetelt célállapotot, ne csupán az esemény fogadását vagy a HTTP-választ. Az utófeltétel az üzleti objektumtól és a mértékadó forrásra vonatkozó szabálytól függ.