Na této stránce
Aktualizace objednávky přijde před událostí jejího vytvoření. Jinde dorazí událost platby před starší událostí předplatného. Jde o ilustrativní týmy používající jiné produkty i formáty. Oba mohou chtít problém vyřešit seřazením doručených událostí podle času přijetí.
Nejde o zprávu o incidentu žádného z týmů. Ptáme se, zda mají obě selhání společný tvar, přestože podrobnosti dodavatelů se liší.
Zaznamenaná diskuse o matematických souvislostech si všímá, že zdánlivě odlišné problémy mohou mít užitečnou společnou podobu. Použití na softwarové integrace je naše odvození. Užitečné je pouze tehdy, když společná podoba vytvoří test podložený dokumentovaným chováním každého systému.
Odstraňte názvy a pak vraťte specifikace rozhraní
Popište první případ bez názvů produktů: událost o zdroji může přijít po pozdější změně téhož zdroje. Příjemce, který považuje pořadí příchodu za pořadí stavů, může přepsat novější informaci starší.
Nyní zkontrolujte skutečné specifikace rozhraní. Dokumentace webhooků Shopify uvádí, že pořadí není zaručené ani v rámci jednoho tématu, a dává příklad aktualizace produktu doručené před oznámením jeho vytvoření. Dokumentace webhooků Stripe také negarantuje pořadí doručení podle vzniku a doporučuje načíst chybějící objekty, pokud očekávaná dřívější událost nepřišla.
Shopify i Stripe varují před nezaručeným pořadím doručení. Společná otázka je správnost konečného stavu; identifikátory a pravidla obnovy vyžadují samostatný test.
Přenositelná otázka zní: „Pokud tato událost přijde před související událostí, dokážeme stále určit správný současný stav?“ Odpověď k realizaci nelze převzít bez ověření. Shopify dokumentuje hlavičky jako X-Shopify-Webhook-Id a časová razítka. Stripe používá vlastní ID událostí a pravidla načítání objektů. Identifikátor znamenající „doručení“ v jednom systému nemusí znamenat totéž v jiném.
Náš průvodce konektorem Brevo řeší odlišné podrobnosti polí a mapování. Jsou důležité pro fungující integraci, ale nejsou univerzálním chováním API.
Společný tvar je invariant
U synchronizace zákazníků může invariant znít: po zpracování odráží cílový záznam zákazníka současný stav oprávněného zdroje. U plateb: akce závislá na platbě nastane, jen pokud ji dovoluje autoritativní stav platby. Invariant pojmenovává to, co musí platit, i když události dorazí pozdě, opakovaně nebo neúplné.
Před výběrem opravy napište čtyři věci:
| Otázka | Proč záleží |
|---|---|
| Která identita označuje obchodní objekt? | ID události může označovat zprávu, ne zákazníka nebo objednávku. |
| Který systém vlastní současný stav? | Obsah události může být snímek, změna nebo jen odkaz. |
| Jaké pořadí zdroj zaručuje? | Pořadí doručení nemusí být pořadím stavů. |
| Jaká výsledná podmínka dokazuje úspěch? | Přijetí události nedokazuje správný stav cíle. |
Tabulka je pomůcka k uvažování, ne protokol. Zdroj pravdy závisí na postupu. Živé načtení může být v jednom systému potřebné a v jiném nevhodné. Některé události je třeba zachovat jako historické skutečnosti místo jejich sloučení do nejnovějšího snímku.
Převezměte test a upravte nápravu
Malý test specifikace rozhraní může doručit související události v obráceném pořadí a ptát se, zda je konečný stav cíle správný. Další může tutéž událost doručit dvakrát. Testy odhalují tvar rizika. Dokumentace dodavatele pak určí, jak každou událost identifikovat, ověřit a obnovit.
Rozdíl chrání tým před architekturou kopírování. Klíč deduplikace z jednoho API může v druhém selhat. Časové razítko s hrubou přesností nemusí stanovit pořadí. Načtení aktuálního objektu může být nutné pro synchronizaci stavu, ale neobnoví každou mezilehlou historickou událost. Průvodce integrací více firemních nástrojů začíná volbou vlastníka každého pole; bez ní „nejnovější“ nemá jednoznačný význam.
Přenos vzorců má meze. Podobné příznaky mohou mít různé příčiny: chybějící záznam může způsobit dotaz bez oprávnění, opožděný webhook, neplatné mapování nebo odmítnutý zápis. Než dva případy prohlásíte za stejné, porovnejte specifikaci zdroje a cíle a pozorovanou výslednou podmínku. Pokud se liší, ponechte společnou otázku a změňte test.
Metoda pomáhá i mimo doručování událostí. Pole přijaté API, ale neviditelné v uživatelském záznamu vyvolává v každém konektoru podobnou otázku: co dokazuje potvrzení a co dokazuje zamýšlený stav? Odpověď může vyžadovat načtení cíle, kontrolu schématu nebo oprávnění. Vzorec říká oddělit transport od významu. Neříká, které pole nebo koncový bod zavolat. Užší lekce je méně vzrušující než univerzální recept na integrace, ale cestuje dál, protože zachovává místní fakta.
Nejsilnější přenositelnou lekcí není úryvek kódu. Je jí otázka, která přežije přesun do jiného systému a usnadní zkoumání jeho vlastní specifikace.
Často Kladené Otázky
Lze stejný integrační test použít u různých dodavatelů?
Často lze přenést otázku, třeba zda aktualizace mohou přijít v jiném pořadí. ID událostí, význam obsahu, podpisy a postup obnovy se musí řídit specifikací rozhraní každého dodavatele.
Jaký je rozdíl mezi vzorcem a zkopírovanou opravou?
Vzorec pojmenovává podmínku selhání a invariant, který je třeba zachovat. Zkopírovaná oprava bez ověření předpokládá u druhého systému stejné identifikátory, pořadí a význam stavu.
Co kontrolovat po použití události?
Kontrolujte cílový stav požadovaný postupem, ne jen přijetí události nebo HTTP odpověď. Výsledná podmínka závisí na obchodním objektu a pravidlu zdroje pravdy.