AI navrhne krásný web. Udělat z něj dobrý web je jiná disciplína.
Umělá inteligence mění způsob, jakým vzniká vizuální podoba…
Číst dál
„Potřebujeme jen propojit náš web s CRM.“
Podobná věta může znamenat několik hodin práce, ale také týdny vývoje a následnou dlouhodobou údržbu. Záleží na tom, kolik dat přenášíme, kdo je může měnit, jak často se mají synchronizovat a co se stane, když některá část přestane fungovat.
Za dobu fungování Freely jsme integrovali desítky externích služeb. CRM systémy jako Raynet nebo Salesforce, podnikové systémy SAP, Helios a Money S3, platební a fakturační služby, Make, e-mailingové nástroje, mapové podklady nebo specializovaná API. A přestože má každá integrace svoje specifika, určité problémy se opakují bez ohledu na technologii.
Často přitom nespočívají v samotném odeslání požadavku na API. Náročnější bývá navrhnout, jak spolu mají dva systémy dlouhodobě spolupracovat, aniž by si navzájem komplikovaly život.
1. Kdo vlastně vlastní data?
Představme si, že náš web vytvoří prostřednictvím API nový kontakt v CRM. Předá jméno, kontaktní údaje, firmu a další informace. CRM záznam přijme a všechno funguje. O několik dní později ale obchodník otevře CRM a některé údaje ručně upraví. Třeba doplní telefonní číslo nebo opraví název firmy.
Co se stane při další synchronizaci? Pokud náš web odešle původní data znovu, může obchodníkovy změny přepsat. Pokud naopak automaticky převezme všechno z CRM, mohou se ztratit aktualizace provedené na webu. A co když do stejného CRM zapisuje ještě třetí aplikace? Právě proto je potřeba už při návrhu integrace určit, který systém je pro konkrétní údaje autoritativním zdrojem. Někdy je synchronizace pouze jednosměrná, jindy se změny přenášejí oběma směry. A občas má dokonce každé pole jiného vlastníka.
Například základní identifikační údaje zákazníka mohou pocházet z ERP, obchodní poznámky z CRM a marketingové preference z dalšího nástroje. Není na tom nic neobvyklého. Ale pokud si tato pravidla neurčíme předem, snadno vytvoříme systém, který při každé synchronizaci přepisuje práci někoho jiného.
Nejdůležitější otázka proto nezní, jestli API umožňuje data zapisovat. Ale kdo všechno je může měnit a čí změna má mít přednost.
2. Synchronizace není jen přenos dat z bodu A do bodu B
Další velkou oblastí je množství přenášených dat. Jiná situace nastává, když jednou denně synchronizujeme několik desítek kontaktů, a jiná, když potřebujeme pravidelně zpracovávat desítky tisíc produktů, jejich variant, cen a dalších navázaných informací.
Některá API umožňují stáhnout větší datový balík, který následně zpracujeme na vlastní straně. Jinde musíme data načítat postupně, po jednotlivých stránkách nebo menších dávkách. Do rozhodování vstupují také limity počtu požadavků, velikost odpovědí, rychlost zpracování a dostupná infrastruktura.
Velký import může být efektivní, protože minimalizuje počet volání externí služby. Pokud ale v jeho průběhu něco selže, musíme vědět, odkud pokračovat a jak se vyhnout opakovanému zpracování již uložených dat. Postupné načítání zase umožňuje lépe kontrolovat průběh synchronizace, ale může narazit na API kvóty nebo trvat neúměrně dlouho.
A pak je tu další rozhodnutí: budeme pokaždé přenášet všechno, nebo jen záznamy, které se od poslední synchronizace změnily? Jedna správná odpověď neexistuje. Záleží na možnostech externí služby, objemu dat a požadavcích na jejich aktuálnost.
Na pořadí záleží víc, než se zdá
Složitost výrazně roste, když jednotlivé datové entity závisí jedna na druhé. Představme si produktový katalog, ve kterém potřebujeme nejprve založit produkty, následně jejich varianty a teprve potom k nim přiřadit ceny z dalšího číselníku.
Pokud spustíme import ceníků dříve, než jsou produkty skutečně uložené, nemáme ceny k čemu přiřadit. A pokud import produktů skončí v polovině, potřebujeme zabránit tomu, aby navazující synchronizace vytvořila neúplné nebo chybně propojené záznamy. Podobné závislosti se v praxi objevují velmi často. Produkty a kategorie, zákazníci a objednávky, zaměstnanci a jejich oprávnění nebo pracovní nabídky a související číselníky.
Dobře navržená integrace proto musí pracovat nejen s pořadím synchronizací, ale také s jejich stavem, chybami a možností bezpečného opakování.
To, že externí API úspěšně vrátilo data, ještě neznamená, že máme správně vytvořené všechny vazby v naší databázi.
3. Externí služba umí téměř všechno. Až na to, co právě potřebujeme.
Ne všechny komplikace souvisejí s přenosem dat. Někdy je problém v tom, jak moc dokážeme externí službu přizpůsobit konkrétnímu projektu.
Typickým příkladem může být autentizační platforma. Na první pohled nám ušetří značnou část vývoje přihlašování a registrace uživatelů. Jenže klient potřebuje registrační formulář doplnit o vlastní údaje, propojit je s identifikátory dalších firemních systémů a zajistit několik jazykových mutací.
S podobnou situací jsme se setkali při integraci Auth0. Potřebovali jsme mimo jiné doplnit vlastní výběr země do registračního formuláře, uchovávat identifikátory používané v Microsoft Dynamics a zajistit překlady přibližně do deseti jazyků. Možnosti přizpůsobení použitého registračního rozhraní ale nebyly dostatečné pro všechny požadavky. Část funkcionality jsme proto museli řešit vlastními skripty v šabloně služby, včetně překladové logiky a přepínání jazyků prostřednictvím naší aplikace.
Výsledné řešení funguje. Rozhodně tedy nejde automaticky o příklad špatné integrace. Ukazuje ale, jak se za zdánlivě jednoduchým požadavkem „napojit registraci“ může skrývat poměrně specifický vývoj.
Podobné kompromisy jsou při integracích běžné. Externí služba nám může ušetřit vývoj celé funkční oblasti, ale zároveň nás omezuje tím, co její API, šablony nebo konfigurační možnosti dovolují. A pokud řešení stojí na vlastních úpravách rozhraní externí služby, musíme do budoucna počítat také s rizikem, že její aktualizace ovlivní naše přizpůsobení.
To, že služba danou funkcionalitu nabízí, ještě neznamená, že podporuje všechny procesy, které na ní potřebujeme postavit.
4. Jak otestovat fakturaci, aniž bychom vystavili fakturu?
Jednou z nejméně viditelných položek při odhadu pracnosti integrace bývá testování.
U vlastní aplikace si zpravidla můžeme připravit vývojové nebo testovací prostředí. Vytvoříme testovací data, ověříme různé scénáře a případné chyby opravíme ještě před nasazením. U externích služeb ale takový komfort nemusíme mít.
Někteří poskytovatelé nenabízejí plnohodnotné testovací API nebo jejich sandbox nepodporuje všechny operace. V praxi jsme tak řešili například napojení fakturačního systému, kde nebylo možné jednoduše provádět všechny testy bez vytváření skutečných dokladů.
Najednou je potřeba velmi pečlivě rozlišovat, co můžeme bezpečně testovat a co už představuje reálnou operaci v klientově systému. Část scénářů lze ověřit nad simulovanými odpověďmi API. Můžeme testovat, jak naše aplikace sestavuje požadavky, zpracovává odpovědi a reaguje na chyby. Takové testy jsou užitečné, ale nikdy zcela nenahradí skutečnou komunikaci s externí službou.
A problém pokračuje i po nasazení. Jak ověřit, že integrace funguje na produkci, pokud běžný testovací požadavek vytvoří skutečnou fakturu nebo provede jinou obchodní operaci? Možnosti testování je proto nutné zohlednit už při návrhu řešení. Ne až ve chvíli, kdy je integrace hotová a zbývá ji spustit.
Chybějící testovací prostředí externí služby může výrazně ovlivnit pracnost i rizika projektu. A není to něco, co by vývojář dokázal vždy jednoduše vyřešit na své straně.
5. Co se stane, když něco přestane fungovat?
Úspěšné nasazení integrace je jen začátek. Externí systémy mohou mít výpadky, zpomalovat, měnit API nebo zavádět nová omezení. A naše aplikace se musí umět vypořádat i se situací, kdy požadavek neproběhne podle očekávání.
Představme si například odeslání objednávky do ERP. Naše aplikace odešle požadavek, ale odpověď nepřijde včas. Znamená to, že objednávka nevznikla? Nebo ji ERP úspěšně vytvořilo, jen se k nám nestihla vrátit odpověď? Pokud požadavek jednoduše zopakujeme, můžeme nechtěně vytvořit dvě stejné objednávky. A podobně nebezpečná situace může nastat u fakturace, plateb nebo zakládání dalších záznamů. Proto je potřeba navrhovat mechanismy pro bezpečné opakování operací, kontrolu duplicit a evidenci toho, které kroky skutečně proběhly.
Stejně důležitý je monitoring. Integrace může několik dní nefungovat, přestože samotný web vypadá zcela v pořádku. Uživatel si problému všimne až ve chvíli, kdy v systému chybějí nové objednávky, neaktualizují se ceny nebo nepřicházejí očekávané záznamy.
Dobře navržené řešení proto potřebuje nejen přenos dat, ale také způsob, jak poznat, že přenos přestal fungovat. V ideálním případě se navíc výpadek jedné externí služby nepromítne do nedostupnosti celého webu. Tam, kde je to vhodné, pomůže cache, lokální kopie dat nebo odložené zpracování operací.
Spolehlivost integrace se nepozná podle toho, že funguje za ideálních podmínek. Pozná se podle toho, co udělá, když ideální podmínky přestanou platit.
6. Největší náklady mohou přijít až po spuštění
Právě dlouhodobý provoz bývá při rozhodování o integracích podceňovaný. Systémy, které propojujeme, mají různé vlastníky a vyvíjejí se nezávisle na sobě. Dodavatel CRM může změnit API, ERP přejde na novou verzi, klient rozšíří nabídku služeb nebo začne působit na dalším trhu.
A naše integrace se tomu musí přizpůsobit. Někdy jde o drobnou změnu mapování dat. Jindy může být nutné upravit celou synchronizační logiku, znovu otestovat návaznosti a zajistit kompatibilitu se stávajícími procesy.
Do celkových nákladů proto nepatří jen původní vývoj. Patří sem také monitoring, řešení incidentů, úpravy při změnách API, provoz synchronizačních procesů a případné náklady na licence nebo middleware.
To ale neznamená, že složitější architektura je automaticky lepší. Někdy je rozumné využít existující integrační platformu, jindy napsat vlastní jednoduché propojení. Rozhodující je frekvence změn, důležitost přenášených dat a dopady případného výpadku. Malá integrace kontaktního formuláře s e-mailingovým nástrojem bude mít jiné požadavky než synchronizace produktů, cen, objednávek a zákaznických dat mezi několika klíčovými systémy firmy.
Nejdražší integrace nemusí být ta, jejíž vývoj stál nejvíc. Může to být ta, která každou další změnu promění v komplikovaný zásah.
Na co se ptát ještě před začátkem vývoje?
Pokud firma plánuje nový web nebo aplikaci napojenou na externí služby, doporučujeme ještě před zahájením projektu vyjasnit několik věcí:
- Kdo je zdrojem pravdy? Kde data vznikají, kdo je může upravovat a jak se řeší konflikty?
- Kolik dat a jak často přenášíme? Jde o jednotlivé požadavky, pravidelný import nebo průběžnou synchronizaci?
- Jaké jsou závislosti mezi daty? Musí se některé záznamy vytvořit dříve než jiné?
- Jaká omezení má externí služba? API kvóty, dostupné funkce, přizpůsobení rozhraní a licenční podmínky.
- Jak budeme testovat? Existuje sandbox, testovací účet a bezpečný způsob ověření produkčního provozu?
- Co se stane při výpadku? Umí integrace bezpečně zopakovat operaci, pokračovat po přerušení a upozornit správce?
- Kdo se o ni bude starat po spuštění? Kdo sleduje změny API a řeší případné incidenty?
Na všechny otázky nemusíme mít definitivní odpověď při prvním setkání. Měli bychom ale vědět, že existují, a zahrnout jejich řešení do návrhu architektury i odhadu pracnosti.
Integrace není jednorázový úkol
Externí API dnes nabízí téměř každá větší firemní služba. Samotná dostupnost API ale neříká mnoho o tom, jak náročné bude konkrétní systémy propojit a dlouhodobě udržovat v provozu. To, co při prvním odhadu vypadá jako několik jednoduchých požadavků, může ve skutečnosti zahrnovat synchronizaci rozsáhlých dat, složité vazby, vlastní přizpůsobení externích služeb i problematické testování.
A naopak: dobře zvolená architektura dokáže dlouhodobou správu výrazně zjednodušit, i když její počáteční návrh zabere více času.
Dobře navržená integrace není ta, která dnes úspěšně přenese data. Je to ta, na kterou se firma může spolehnout i ve chvíli, kdy se některý ze zapojených systémů změní, zpomalí nebo přestane odpovídat.