V obchodu platí pravidlo, že mít dobrou službu nebo produkt není nic platné, pokud je nedokážeme dostat na trh. Musíme mít způsob, jak o sobě dát vědět a musíme mít systém, jak nasytit poptávku, kterou jsme vyvolali - pokud se nám to tedy povedlo.
Ve světě softwarových služeb a produktů to platí stejně. Potřebujeme tedy marketing i obchod. Pokud jde o obchod, součástí obchodního systému je odstraňování všech překážek, které brání potenciálním klientům v užívání toho, co jim chceme nabídnout. A jednou z klíčových překážek u software v B2B bývá často komplikovaný způsob propojení našeho produktu s dalšími službami zákazníka. Toto propojení je přitom často nezbytné.
Vyřešit integrace svého software v B2B segmentu je pro obchod daného produktu nebo služby stejně důležité, jako jsou dveře pro kamenný obchod. Mít výlohu na náměstí je jistě skvělé, ale pokud budou muset zákazníci obejít tři bloky, aby se dostali dovnitř, kolik z nich nakonec do obchodu dorazí?
Naši klienti jsou nejčastěji ze segmentu e-commerce, kde se pro integrace velice často vytváří vlastní pluginy do jednotlivých e-shopových platforem. Tento způsob využívá logistika, fulfillment, dropshipping, ERP systémy i business intelligence. Je to ideální způsob, který pomáhá nalézt nové klienty, zviditelnit svůj produkt a odbourat překážky pro nové uživatele.
Jak ale připravit správný koncept pro takové integrace?
Správnou úvahu je v tomto případě vhodné podpořit i správným konceptem. Vyhneme se tak v budoucnu potížím se správou i rozvojem řešení. Integrace budou tvořit náš strategický prvek, měli bychom k nim proto přistoupit se stejnou pečlivostí, s jakou připravujeme naší vlastní službu.
Pojďme si popsat technické problémy, se kterými se budeme při integracích potýkat. Většinou se týkají integrací obecně, ale chceme zde demonstrovat především integrace s využitím pluginů v různých platformách, protože rychlý plán na jejich vybudování svádí často k nekoncepčním krokům a zkratkám, které nám mohou v budoucnu komplikovat život.
Na co bychom tedy měli myslet a proč začlenit ještě integrační službu, když máme REST API, se kterým mohou pluginy e-shopů bez problémů komunikovat? Proč by komunikace měla být asynchronní? Pojďme si vše demonstrovat na jednoduchém případu odeslání objednávky z e-shopu:
V ideálním případě budeme chtít volat naše REST API ve chvíli, kdy uživatel vytvoří objednávku. Když pomineme fakt, že nemusíme mít událost v systému dostupnou, naivním způsobem bychom v některých případech mohli volat naše REST API přímo. Pokud ale nechceme řešit úlohy naivně, musíme v tomto případě zajistit opakované volání při dočasné nedostupnosti volaného rozhraní.
Pro opakované volání potřebujeme spouštět plánované úlohy na serveru a taková oprávnění nebudeme mít vždy dostupná. Už tato situace proto volá po integrační službě.
Rate limiting - ano či ne?
Ošetřením nedostupnosti volané služby jsme trochu vylepšili stále ještě příliš naivní řešení. Nyní se pojďme podívat na ošetření rate limitů. Náš systém i vytvořený plugin by si s rate limity druhé strany měly umět poradit. Že na vlastní straně rate limiting nepotřebujete? Vlastně ne, pokud nechcete kontrolovat přetěžování vlastního systému. V každém případě většina rozhraní cloudových služeb limity na svém rozhraní mají a pokud je chceme volat, musíte s nimi počítat.
Neřešme teď způsob, jak limitování ošetřit. O tom třeba někdy příště. Podstatné je, že původní myšlenka jednoduchého pluginu se stává robustnější a plugin „tlustší“. A kolik takových pluginů jsme chtěli pro naše integrace vytvořit? Opravdu chceme psát všechnu tu logiku tolikrát?
Opět se nabízí použít jako mezičlánek integrační službu, která ošetří rate limiting i nedostupnosti obou stran. Samozřejmě je nutné ošetřit i nedostupnost samotné integrační služby. Chytré řešení, jako je Applinth nebo Orchesty, má na to několik prostředků.
Způsoby předcházení nedostupnosti
První způsob předcházení nedostupnosti je propustnost vstupního bodu služby, který unese mnohonásobně větší zátěž, než lze očekávat od pluginu psaného většinou v PHP i od většiny REST API. Nejde přitom jen o technologii, ale především o fakt, že i procesy uvnitř integrační služby jsou asynchronní a služba tedy požadavek jen přijme a předá do fronty.
Další pojistkou nedostupnosti integrační služby jsou dávkové procesy, při kterých integrační služba volá zdroj. Použijeme je místo realtime signálů nebo paralelně s nimi, pokud má pro nás realtime velkou hodnotu. Kromě nedostupnosti zdroje si v tomto případě musíme poradit i se stránkováním zdrojových dat. A především při volání cíle bude kritické dodržování limitů. I kdyby to bylo možné, nedává smysl psát toto všechno zvlášť v každém pluginu, který budeme chtít vytvořit. Proto potřebujeme integrační službu.
Chytrá integrační služba má nakonec ještě jednu podstatnou vlastnost. Slouží jako nárazník, který rozloží extrémní špičky provozu. Řídí totiž limity výstupu na vaše API napříč všemi volajícími systémy. Zatímco na vstupu z vnějšku je stavěná tak, aby dokázala nárazově absorbovat tisíce dotazů každou vteřinu bez nutnosti škálování, na výstupu je konfigurovaná tak, aby nepřetížila vaše API. Rovnoměrná zátěž znamená výraznou optimalizaci vašich prostředků. Pokud použijete chytrou integrační službu, vlastní systém budete škálovat podstatně efektivněji.
Řešení integrací prostřednictvím pluginů
Pokud se tedy rozhodneme řešit integrace prostřednictvím pluginů v systémech třetích stran, vhodný koncept je budovat štíhlé pluginy v systémech a ponechat většinu logiky na integrační službě. Získáme tím i řešení pro integrace systémů, které vlastní pluginy nepodporují. Je to nejefektivnější způsob, jak získat pro svůj obchod dveře do náměstí.
Pokud jste dočetli až sem, dozvěděli jste se některá základní pravidla pro budování multitenantních integrací. V některém dalším článku si popíšeme, co vlastně znamená slovo "multitenantní" v souvislosti s integracemi a co všechno musíme řešit při jejich budování.
