Více systémů
neznamená
více kopírování.

Z čeho vycházím: Při stavbě publikačních a datových systémů jsem řešil návaznost více API, lokalizace, validace, generování výstupů a postupné publikování bez ztráty přehledu.

Nejdřív určím zdroj pravdy

Pokud stejný údaj existuje v CRM, tabulce i interním nástroji, integrace musí mít pravidlo, který systém je autoritativní. Bez toho se změny přepisují sem a tam a nikdo neví, která hodnota platí.

Zdroj pravdy nemusí být pro všechny údaje stejný. Důležité je pravidlo napsat dřív, než začne synchronizace.

Mapování je důležitější než počet endpointů

API dokumentace neřekne, jak přesně převést význam jednoho pole do druhého systému. Potřebuji řešit formát dat, povinná pole, časová pásma, identifikátory, lokalizaci a pravidla pro prázdné nebo neplatné hodnoty.

U vícejazyčného obsahu navíc rozlišuji zdrojový text, překlad, stav kontroly a publikovanou verzi. Jinak lze snadno přepsat schválený obsah novým návrhem.

Integrace musí být opakovatelná

Výpadek sítě nebo timeout nesmí znamenat, že ručně začneme celý proces od začátku. Každá dávka nebo položka potřebuje identifikátor a stav, podle kterého poznám, co už proběhlo.

• nová položka čeká na zpracování,
• zpracování právě probíhá,
• výsledek byl potvrzen,
• chyba se může bezpečně opakovat,
• konflikt čeká na rozhodnutí.

Konflikt není technická chyba

Když se stejný záznam změnil na dvou místech, systém nemá vždy právo vybrat poslední hodnotu. Někdy je správné konflikt označit a vyžádat si rozhodnutí člověka. Tím se zachová dohledatelnost a nevznikne tichá ztráta dat.

Co má klient vidět

Uživatel nepotřebuje znát každý HTTP status. Potřebuje ale vědět, jestli je synchronizace v pořádku, kolik položek čeká, co selhalo a co může udělat dál. Proto stav a jednoduchá diagnostika patří do návrhu stejně jako samotné volání API.

Teprve když je jasný model dat a stavů, dává smysl řešit výkon, frontu, plánování a konkrétní knihovnu.