PHintegra - integrační platforma

PHinTegra je komplexní integrační platformou pro realizaci bezpečného a spolehlivého propojení heterogenních softwarových systémů do jednoho spolupracujícího celku. Umožňuje vytvářet hybridní integrační scénáře na jednotné platformě. PHinTegra zajišťuje sestavení a parametrizaci integračního propojení modulů informačních systémů prostřednictvím nabízených služeb, otestování a nasazení připravených integračních propojení do zvoleného prostředí, monitoring a řízení provozu integračních vazeb. Funkční struktura integrační platformy PHinTegra kopíruje životní cyklus sestavení a zprovoznění integračního scénáře.

Základní funkce platformy

správa katalogu systémů a jejich služeb

sestavení integračního scénáře

parametrizace integrační vazby

testování integračního scénáře, trasování

nasazení integračního scénáře

katalogizace nasazeného scénáře

monitorování a řízení provozu, trasování a výstrahy

dokumentace integračního scénáře

zajištění bezpečnosti komunikace

PHinTegra má intuitivní ovládání všech funkcí s uživatelským rozhraním.

Sestavení integračního scénáře je postaveno na „šablonách“ postupů pro jednotlivé metody a technologie integrace. Výsledný produkt pak zajišťuje synchronní i asynchronní způsob komunikace, konzumentem vyžádanou nebo událostí řízenou komunikaci.

PŘEDCHOZÍ GENERACE

Rozšiřující moduly PHinTegra

MESSAGING / STREAMING

Kafka – Aktuální verze PHinTegra aplikačně podporuje připojení na nativní rozhraní Kafka. Kafka je napojena na standardní logy (provoz na jednotlivým topic včetně payloadu – volitelně) nerelační databáze Grafana Loki, nad kterou je pak možno pomocí webové aplikace Grafana tyto logy prohlížet.

Přínosy propojení

Možnost vizualizace a zakládání Kafka topics z prostředí PHinTegra, tak aby tyto topics byly viditelné ze Service Repository PHinTegry a pak umožnit přímý proklik na Grafana vizualizaci logů

Možnost pracovat s topics (zakládat, měnit, provádět transformace, agregace)

ActiveMQ – Enterprise řešení PHinTegra využívá pro messaging komponentu ActiveMQ pro používání front. ActiveMQ je napojena na standardní logy (provoz na jednotlivou frontou včetně payloadu – volitelně) nerelační databáze Grafana Loki, nad kterou je pak možno pomocí webové aplikace Grafana tyto logy prohlížet. Na tomto řešení je postaven princip error handlingu vyvinut.

Přínosy propojení

Možnost spravovat fronty z prostředí PHinTegry, tak aby bylo možný proklik na konkrétní queue a její logy.

SFE – Secure File Exchange

Komponenta vyvinutá Physterem, která je postaven na Apache Camelu a stará se o konfiguraci souborových přenosů.

Přínosy propojení

Dokumentace SFE jobů v Service Repository a proklik na Grafana log

ETL

Komponenta vyvinutá Physterem pro potřeby ETL procesů, která je postavena na opensource produkut Pentaho Kettle.

Přínosy propojení

Dokumentace hlavičky ETL procesu v Service Repository pro dokumentaci a proklik na konkrétní ETL proces a jeho log v Grafana

NOTIFIKAČNÍ ENGINE

Komponenta, která se zabývá odesíláním strukturovaných SMSek a Emailů. Tyto SMSky a e-maily jsou šablonovány a je možno do nich vkládat placeholdery pro dynamické doplňování dat. Pro odeslání je vystavena REST API, do které jsou doplněna data a číslo šablony.

Notifikační engine s pak postará o doplnění do šablony a odeslání SMSky, nebo e-mailu.

PHinTegra zajišťuje

funkčnost pro správu front požadavků a front odpovědí

ve svém jádru běžné komunikační standardy (HTTP, HTTPS, SOAP, REST, …)

ve své customizační části pak uživatelem vyžádané komunikační standardy (DASTA, HL7, …)

správu certifikátů pro bezpečnost komunikace (autentizace, autorizace, šifrování komunikace, šifrování obsahu)

funkce pro rychlé a efektivní otestování integračního scénáře

rychlé nasazení integračního scénáře za plného běhu systémů

automatickou dokumentaci, sestavený, otestovaný a nasazený integrační scénář

automatickou dokumentaci své konfigurace

monitoring a logování svého vlastního provozu a provozu instancí integračních vazeb

uživatelský přehled stavu provedených a běžících instancí scénářů

s možností náhledu na průběh a obsah instance

automatické zasílání výstrahy / upozornění na problematický stav

Technologický popis řešení

Technologicky PHinTegra vychází z kontejnerizační platformy, v aplikační části využívá řadu open source produktů (Camel K, Spring boot, Spring Native, Apache Camel, Grafana, Prometheus), databáze (PosgreSQL, Elastic Search) a pro API management nástroje WSO2. PHinTegra je postavena na kontejnerové architektuře. Není závislá na konkrétním kontejnerizačním prostředí. Může běžet jak v Kubernetes, tak OCP/OKD. V rámci vývoje integračních služeb je možno definovat počet integračních PODů a definovat velikost uvolněných zdrojů, ve kterých bude služba deployována. V rámci PHinTegra dashboardu je pak možno sledovat aktuální počet PODů pro dané služby a řešit případně disproporce.
Integrační mikroslužby je možno designovat prostřednictvím Service Designeru na principu low code programování, kdy kompletní proces od tvorby po nasazení služby pro provoz dokáže zajistit integrační analytik/architekt. Dochází tak k časové a finanční úspoře, zároveň nejsou třeba seniorní vývojářské kapacity. Každá služba je nasazena jako separátní autonomní kontejner, který lze škálovat a zajistit tak budoucí „neomezené“ změny performance potřeb.
Služby vytvářené v Service Designeru jsou verzovány a ukládány do Service Repository. Následně jsou integrační mikroslužby ze Service Repository buildovány do runtime aplikací Camel K, Spring Boot nebo Spring Native, dle konkrétního scénáře a potřeby použití.

Design a vývoj integračních služeb

Návrh a vývoj integračních služeb probíhá v Service Designeru, který zajišťuje popis integrační služby (pro potřeby dokumentace služby), návrh datového zdroje (XSD, Open API, DB objekty atd.), definici datové transformace, parametry pro konfiguraci běhového prostředí a API managementu, komponentní a sekvenční diagram a také integrační route pro mediaci integračního flow, viz obrázek níže.

Integrační route se tvoří pomocí open source nástroje Apache Karavan, který nabízí všechny komponenty Apache Camel, což nám poskytuje skoro neomezené možnosti tvorby integrací. Součástí Designeru jsou také např. KAFKA konektor, konektor FHIR nebo konektory do různých DB.
V prostředí Service Designeru lze jednotlivé služby testovat nebo je možné konkrétní testovací scénáře připravit a uchovat pro pozdější použití. Služby se dokumentují a lze je exportovat ve formátu Archimate modelů.

Funkcionality Service Designeru

Integrační scénář – v tomto modulu je dle principů UML designován komponentní diagram, který zachycuje integrační flow. Jsou zde vidět konzumenti služby i technologie propojení. Z tohoto diagramu je přebírán detail pro navržení integrační routy.

Datový model – modul slouží pro designování datových modelů pro integrační služby. Jsou zde modelovány XSD / WSDL a Open API pomocí zjednodušených procesů. Analytik dokáže pomocí tabulkového zobrazení připravit model bez nutné detailní znalosti W3C / swagger notace.

Mapování – modul pro vytváření mapování mezi konzumentem a providerem služby. Modul pomocí drag&drop propojí jednotlivé atributy zprávy a následně vygeneruje mapovací soubor v různých formátech (např. XSLT transformaci pro SOAP).

Route designer – pomocí grafického designeru dochází k návrhu detailního zpracování integrační routy. Výstupem je DSL předpis pro Apache Camel.

Testovací modul – pomocí vydefinovaných atributů (parsovaný request) je možné integračně otestovat konkrétní integrační službu.

Služby vytvořené v Service Designeru jsou pak následně nasazovány prostřednictvím Physter Service Repository, druhého licencovaného nástroje platformy PHinTegra

Metody nasazování integračních služeb

PHinTegra je navržena tak, aby bylo možno všechny integrační služby buildovat a deployovat z jednoho místa pro všechny tenanty a všechna jejich prostředí. V průběhu designu integrační služby dochází ke shromažďování všech artefaktů, které jsou potřeba pro následný build integrační služby. Po kompletním shromáždění pak dochází k buildu integrační služby. V rámci PHinTegra je možno vybrat typ metody buildu Not native – SpringBoot, Not native Quarkus a Native Quarkus. Tento typ metody buildu má pak vliv na velikost PODu integrační služby, a tedy i na velikost potřebné paměti integrační platformy.

Následné nasazení je pak závislé na parametrech application properties, které jsou poplatné prostředí, kam je integrační služba nasazována. V rámci nasazování integrační služby dochází k vytvoření integrační mikroslužba, konfigurace na interní API Management a i případně i na externí API Management v případě potřeby komunikovat s prostředím internetu.

Service Repository

Service Repository přebírá vytvořené a dokumentované služby ze Service Designeru. Na začátku procesu implementace služby se provede sestavení integrační routy, validace obsahu a syntaktické kontroly v datových zdrojích. Pak dojde k volbě konkrétního prostředí a nodu pro implementaci služby. Následně se nastaví běhové parametry služby.
Service Repository ukládá a dokumentuje integrační mikroslužby jako celek (tj. včetně datového zdroje, mapování (grafická podoba), diagramů, integrační route a parametrů z běhového prostředí). Na jednotlivé služby je možné pohlížet i přes konzumenta nebo poskytovatele.
Service Repository zahrnuje i popisy a typické scénáře jako např.: „Které všechny služby poskytovatel vystavuje?“ nebo „Všechny konzumenty ke konkrétní službě“.