16. září 2013

Specifika integračních projektů

Integrační projekty mají svoje specifika, která nemusí být pro každého hned na začátku zřejmá, proto bych rád udělal takové jejich resumé v tomto článku.

Logovat, logovat a logovat

U každé aplikace je důležité mít kvalitní logy a být schopen rekonstrukce běhu aplikace, ale z mých zkušeností toto platí dvojnásob pro integrační projekty. Pokud se bavíme o implementaci nějaké integrační platformy (ESB), pak je to ta část celého řešení, která vše propojuje, přes kterou proudí všechny informace,  a proto je nutné umět dohledat chování pro každý požadavek, který do ESB přijde. Je to hlavně kvůli vaší samotné obraně, protože pokud se někde v řešení vyskytne chyba, pak ESB je první koho se ptají. Naštěstí samotné ESB platformy mají většinou kvalitní logování, např. Apache Camel ve své poslední verzi přidal tzv. Message history pro zpětné vypsání celého průchodu vstupní zprávy.

Není to jen o samotném logování, ale také o tom, aby logovací záznamy obsahovaly všechny potřebné informace a bylo zpětné možné dohledat všechny log. záznamy k jedné vstupní zprávě nebo i k jednomu celému procesu (např. proces založení zákazníka se skládá z několika volání externích systémů).

Vymezení oproti ostatním systémům

Jak už jsem psal, pokud někde nastane nějaký problém, tak integrační platforma je první, kde se hledá možná příčina problému. Proto je potřeba hned na první pohled jasně u každé chyby vidět, zda se jedná o interní chybu integrace nebo o chybu, která se vyskytla v externím systému a pokud ano, tak v jakém.  Z toho důvodu se zavádí katalog chyb, který toto značně zpřehledňuje. Potom kdykoliv se objeví nějaká chyba, tak vždy ji doprovází i jasná identifikace z katalogu chyb.

Bez komunikace a pravidel to nejde

Pokud jste uprostřed celého řešení a propojujete jednotky/desítky/stovky systémů okolo, tak to prostě od stolu neuděláte. Je potřeba komunikovat, volat si, scházet se. Velice se nám osvědčil u integračních projektů přístup, že hned od začátku se integruje celé řešení dohromady - sice to v prvních sprintech bolí, ale hned od začátku máte celé řešení, které funguje end-to-end a nemusíte se obávat nepříjemného překvapení na konci projektu, když budete chtít pospojovat jednotlivé krabičky dohromady.
Integrační platforma musí být vždy o krok napřed před ostatními systémy (proto je i vhodné, aby integrační tým měl aspoň jeden sprint náskok), musí být od začátku jasná pravidla pro vzájemnou komunikaci - povolené komunikační protokoly, povinné informace v každé zprávě, jednotné názvosloví, domluva na společných číselnících, verzování služeb,  atd. Pokud toto nebude hned na začátku, tak se to pak vrátí v době údržby jako bumerang.

Flexibilita musí být   

Integrační procesy se pořád mění, nové systémy se přidávají, staré zanikají nebo jsou nahrazovány novými a je potřeba s tímto hned od začátku počítat, že to není nic výjimečného, že je to prostě realita.

Maximální dostupnost

Je rozdíl pokud nefunguje koncová aplikace nebo integrační platforma uprostřed - to pak nefunguje nic. Hned od začátku je nutné si umět jasně odpovědět na základní scénáře okolo produkčního nasazení - jak budu upgradovat na novou verzi rozhraní, jak budu nasazovat hotfixy, jak budu měnit konfiguraci, jak zaručím co největší dostupnost atd. Hned od začátku je potřeba mít jasno a neříkat si, že se to pak nějak vyřeší.
Pokud budete hledat odpověď na tyto otázky, tak určitě budete přemýšlet nad modulární architekturou (vyplatí se mi použít OSGi a mít možnost upgradovat nezávisle libovolný modul bez restartu celé aplikace?) nebo nad způsobem jak přistupovat k návrhu rozhraní (každá služba bude mít svoje rozhraní, žádné sdílení společných entit vs. jednotlivé rozhraní si sdílejí společné entity).

Jednoduchost nade vše

Více než u jiných typů projektů zde platí, že pokud je něco hodně složitého nebo komplikovaného, tak je to špatně. U dobře navržené integrace nejsou na rozdíl od aplikačního vývoje složité algoritmy, vše musí být jasné a srozumitelné, když to mají všichni pochopit a navzájem se propojit.

Žádné komentáře: