Propojit pět nástrojů přes API je technicky triviální. Postavit integrační vrstvu, která bude fungovat za tři roky, když vyměníte CRM, přidáte nového dodavatele a začnete prodávat na novém trhu — to je úplně jiná disciplína. Tady je pět principů, které u našich projektů dlouhodobě fungují.
1. Jeden zdroj pravdy pro každý typ dat
Než se začne propojovat, je potřeba určit, který systém je tzv. „source of truth" pro každou doménu. CRM pro zákazníky. ERP pro produkty a sklad. Účetnictví pro finance. Když máte víc systémů, které tvrdí, že mají autoritativní data o stejné entitě, integrace se nutně rozsypou.
Pokud zákazníka může vytvořit pět různých systémů, integrace bude celý život řešit, který z nich má pravdu při konfliktu. Lepší je definovat jasná pravidla — kdo je autoritativní pro vytvoření, kdo pro updaty, kdo jen čte.
2. Integrace ve dvou směrech, ne v kruhu
Kruhové integrace jsou jedna z nejhorších chyb. CRM posílá update do ERP, ERP posílá update do CRM, CRM si myslí, že je to nový update, posílá to zpět — a máte nekonečnou smyčku. Vzniká to vždycky z dobrého úmyslu („chceme mít synchronizovaná data všude") a vždycky to končí špatně.
Lepší přístup: definujte hub-and-spoke architekturu. Centrální vrstva ví, kdo má co měnit. Periferní systémy jen poslouchají nebo vystavují události.
3. Eventy, ne polling
Polling — pravidelné dotazování systému, jestli se něco změnilo — je naivní a drahý. Při 100 dotazech za hodinu zjišťujete změnu, která se stala možná jednou denně. Eventy fungují obráceně: systém řekne „něco se stalo", a integrace na to reaguje.
Pokud váš systém neumí webhooks, máte dvě možnosti — nasadit lehkou capture vrstvu, nebo polling akceptovat, ale aspoň s rozumnou kadencí. V každém případě by polling neměl být výchozí volba.
4. Idempotence všude
Integrační systém se nesmí zhroutit, když se zpracuje stejný event dvakrát. To se totiž stane — síťové chyby, timeouty, retry mechanismy. Pokud vaše integrace při dvojím zpracování duplikuje zákazníka, vystavuje dvě faktury nebo posílá dva e-maily, máte vážný problém.
Řešení je technicky známé — unikátní idempotency keys pro každou událost. Implementačně to vyžaduje disciplínu, ale jakmile máte tuhle vlastnost zabudovanou, integrace přestávají být zdrojem podivných „náhodných" problémů.
5. Observability od první minuty
Když integrace přestane fungovat, musíte to vědět dřív, než to zjistí zákazník nebo účetní. Logování, alerting, dashboardy zdravosti — to není luxusní vrstva navrch, to je nezbytný základ. Bez observability jste slepí a integrace začnou tichým způsobem selhávat.
Konkrétně: logujte vstup i výstup každé integrace s timestampem a request ID. Alertujte na cokoli, co selhává opakovaně. Mějte dashboard, kde vidíte, kolik událostí proteklo za hodinu — a kdy ta hodnota klesne na nulu.
Co dělat dál
Pokud máte ve firmě více než pět systémů a víte, že se mezi nimi něco ztrácí, není to vada technologie. Je to vada architektury. Audit integrační vrstvy je jeden z nejlevnějších způsobů, jak najít, kde vám provoz nejvíc krvácí — a kde je nejrychlejší návratnost technické práce.
Žádný z těchto principů není nový. Žádný z nich není složitý. Ale dohromady tvoří rozdíl mezi integracemi, které fungují roky, a integracemi, které tým zaměstnávají každý týden tím, že je opravuje.