Začněte obchodním případem, ne katalogem konektorů
Mapujte jeden skutečný případ od jeho vzniku po uzavření. Zapište, kdo jej vytvoří, kde vzniká identifikátor, která data se mění a jaký výsledek musí vidět člověk. Pak označte systémy, jimiž případ prochází. Teprve z tohoto toku vyplyne, která spojení jsou důležitá a kde nyní mizí informace. Samotný seznam dostupných API nevysvětlí, proč se zákazníkovi zobrazuje jiný stav než operátorovi. Do mapy patří také ruční exporty, dávkové úlohy a opravy, protože mohou být pro provoz stejně podstatné jako automatické rozhraní.
Každé pole potřebuje vlastníka významu. CRM může znát obchodní kontakt, účetní systém splatnou částku a provozní aplikace stav plnění. Pokud se stejná hodnota zapisuje na několika místech, určete autoritativní zdroj a pravidlo pro změnu. Bez něj integrační vrstva jen rychleji rozšíří rozpory. Stanovte požadovanou aktuálnost každé informace: některá musí být potvrzena před pokračováním, jiná může dorazit během minut. Z této potřeby vychází vhodný způsob komunikace a měřitelný závazek vůči uživateli.
Zvolte synchronní volání a zprávy podle důsledků čekání
Synchronní API je vhodné, když uživatel potřebuje okamžitý výsledek a druhý systém umí odpovědět ve stanoveném čase. Volající však zároveň přebírá závislost na dostupnosti protistrany. Dlouhý řetězec přímých volání může zastavit celý proces kvůli jednomu pomalému článku. Určete limit čekání, opakování a srozumitelnou odpověď při nedostupnosti. Ne každé opakování je bezpečné: opětovné vytvoření platby se chová jinak než opakované čtení stavu. Rozhodnutí proto zapisujte na úrovni konkrétní operace, nikoli jedním pravidlem pro všechna API.
Asynchronní zpráva dává smysl, když příjemce může zpracovat požadavek později a odesílatel se nemusí blokovat. Microsoft upozorňuje, že broker uchová zprávu při komunikačním výpadku a může ji znovu doručit. Proto se návrh příjemce musí zabývat duplicitou a pořadím. Stav „odesláno“ není stav „zpracováno“. Uživatel potřebuje vidět přijetí, průběh i selhání, případně možnost opravy. Událost má popisovat dokončenou skutečnost; příkaz žádá o akci. Zaměňování těchto významů znesnadňuje určení odpovědnosti i reakci na chybu.
Smlouva o datech musí přežít změnu jedné strany
Pro každé rozhraní stanovte identifikátor případu, povinná pole, formát času a částek, význam stavů, chybové odpovědi a kompatibilní změny. Příklady skutečných zpráv odhalí nejednoznačnost lépe než obecný diagram. U finančních částek uveďte měnu a způsob zaokrouhlení; u času časové pásmo a zdroj. Verzi rozhraní zvyšujte podle změny významu, ne podle každé interní úpravy. Konzument musí rozumět tomu, která pole může ignorovat a která nová hodnota stavu vyžaduje jeho reakci. Součástí smlouvy je i kontakt pro řešení neshod.
Testujte na obou stranách hranice. Producent ověří, že vydává domluvený tvar a význam, konzument, že zvládá povolené varianty a chybějící nepovinná pole. Při změně datového modelu připravte přechodové období a ukončení staré verze oznámte předem. Vzorky nesmějí obsahovat skutečné citlivé údaje bez oprávnění. Správně fungující schema validace přitom nestačí: dvě strany mohou používat stejné pole s různým obchodním významem. Tyto rozpory musí vyřešit vlastník procesu, nikoli jen vývojový tým.
Duplicitní a ztracené zprávy řešte jako běžný stav
Při selhání mezi odesláním a potvrzením nemůže odesílatel vždy poznat, zda příjemce požadavek provedl. Návrh proto počítá s opakováním. Každá měnící operace má mít stabilní identifikátor, podle něhož příjemce rozpozná opakované doručení. Microsoft uvádí idempotentního příjemce jako vzor pro systémy, které mohou doručit zprávu vícekrát. U plateb nebo rezervací nestačí kontrola přítomnosti posledního HTTP požadavku v paměti; evidence musí přežít restart a být vázaná na obchodní operaci. Pravidla pro opakování se liší u přechodné chyby a neplatných dat.
Zprávy, které nelze zpracovat, odložte k bezpečnému prošetření s důvodem selhání a vazbou na původní případ. Neopakujte bez omezení chybu, kterou může napravit jen člověk. Po opravě musí být možné zpracování znovu spustit, aniž vznikne další závazek nebo ztratí auditní stopa. Pokud se mění několik systémů, definujte kompenzační krok pro situaci, kdy pozdější část procesu selže. Kompenzace není vždy prosté smazání; účetní nebo auditní záznam může vyžadovat opačnou, dohledatelnou operaci.
Sledujte výsledek případu napříč hranicemi
Log jednotlivé služby nestačí k vysvětlení celého procesu. Používejte identifikátor případu a korelační identifikátor, který prochází voláními a zprávami. OpenTelemetry popisuje předávání kontextu mezi procesy jako základ propojených stop. U každého kroku zaznamenejte začátek, konec, dobu čekání a bezpečně redigovaný důvod chyby. Nástroje musí pomáhat odpovědět na praktické otázky: kde se případ zastavil, zda vznikla duplicita a kdo má další krok. Citlivá data neukládejte do diagnostiky jen proto, že se vyskytují ve zprávě.
Vedle technických metrik sledujte počet případů dokončených včas, počet ručních oprav, podíl zpráv ve frontě čekajících déle než limit a rozdíly v kontrolních součtech. Nastavte odpovědného člověka a postup při překročení prahu. Každodenní rekonciliace může porovnat očekávané a skutečné stavy, včetně případů, které skončily mimo hlavní cestu. Přehled má umožnit bezpečně otevřít konkrétní problém, opravit jej a doložit zásah. Bez takové provozní smyčky se i technicky správná integrace stane zdrojem neviditelných ztrát.
Zavádějte hranice postupně a přiznejte cenu provozu
První dodávka má pokrýt jeden hodnotný tok, jeho datovou smlouvu, chybové scénáře a provozní přehled. Testovací prostředí by mělo umět simulovat nedostupnou protistranu, opožděnou odpověď, duplicitu a změnu pořadí. Přechod na produkci lze rozdělit podle typu případu nebo skupiny uživatelů. Před rozšířením porovnejte počet zpracovaných případů, chyby a ruční práci s původním postupem. Pokud obě cesty běží současně, musí být jasné, která má právo zapisovat. Jinak pilot vyrobí data, která nebude možné jednoznačně smířit.
EXCOIN může navrhnout integrační mapu, datové kontrakty, implementaci vybraného toku a plán monitoringu. Konkrétní dostupnost či úsporu nelze slíbit bez znalosti připojovaných systémů a jejich provozních omezení. Čím více hranic, tím více verzí, oprávnění a chybových stavů musí někdo dlouhodobě spravovat. Proto volíme nejmenší architekturu, která splní požadovanou spolehlivost: někdy přímé API, jindy frontu nebo události, často kombinaci. Úspěch není počet konektorů, ale dohledatelný případ a menší množství ručních oprav.
Součástí předání je rozhodnutí, kdo spravuje přístupové údaje, kdo mění datovou smlouvu a komu se hlásí incident přesahující hranici týmu. Pravidelně kontrolujte nepoužívaná spojení a účty; starý konektor může zůstat skrytou cestou k datům. Změny neplánujte jen podle kalendáře vlastní aplikace, ale i podle výpadků a verzí připojených služeb. Při každé nové integraci se vraťte k mapě vlastnictví dat a ověřte, zda stále platí. Tím se z prvního projektu stane dlouhodobě udržitelný proces.