Vývoj ERP systému ke správě

domovů pro seniory

Případová studie vývoje ERP systému založeném na technologii mikroservis a progresivní webové aplikace

Spolupráce a klient

Naše společná historie

Se společností DelpSys s.r.o. a jejím zakladatelem Jakubem Žákavcem jsme začali spolupracovat na základě výběrového řízení na vývoj ERP systému, které jsme vyhráli v dubnu roku 2020. Od té doby jsme ušli velký kus cesty, vytvořili několik modulů pro tento systém a také zahájili několik dalších společných projektů. S klientem jsme prošli několika důležitými milníky společnosti a vývojovými etapami projektu Legato. V této studii popíšeme všechny důležité aspekty naší spolupráce.

Společnost DelpSys s.r.o. se, mimo jiné, zabývá také činnostmi v sociálních službách. A i zde musí systém pro správu domova pro seniory dávat smysl. Na řadu tak přichází systém LegatoDelp, který jsme pro společnost DelpSys vyvinuli.

Logo DelpSys
Logo aplikace

Požadavek

Přání klienta

Systém Legato měl být modulovatelný a přístupný z webového rozhraní s vlastním mobilním režimem. Měl pod sebou sdružovat několik systémů a částí, jak tomu u ERP systémů zpravidla bývá. Místo obvyklých „zdrojů“, které se v ERP evidují, se kterými se plánuje, které se spotřebovávají a tak podobně, jsou zde obyvatelé resp. klienti domova, které je třeba evidovat, plánovat s nimi různé služby pro dodržení kvality péče, zaznamenávat aktuální data a dokumentovat jejich pobyt.

Systém typu ERP je také třeba řádně nastavit a některým uživatelům omezit určité funkce pomocí definovatelných přístupových práv. Dalším požadavkem klienta byla možnost provozovat systém jak na cloudu, kde bylo třeba vyřešit rozdělení dat pro každý domov, tak i na vlastních serverech domova (on-premise). Samozřejmostí pak bylo logování veškerých akcí a úkonů provedených v systému.

Systém Legato měl být také doplněn o aplikaci mLegato, která by sloužila jako zjednodušená mobilní verze a ve které pečovatelé měli mít možnost provádět naplánované služby i offline. To vše bylo třeba zvládnout již v první fázi projektu, na niž bylo vyhrazeno 18 týdnů.

Problém

Výzva pro naše vývojáře

Dle požadavku měl být celý systém modulovatelný, aby si každý klient mohl koupit jen moduly, o které měl zájem. Přístup k datům měl být omezen pomocí složité hierarchie práv a řešení mělo fungovat jak v cloudu, tak on-premise. Všechny tyto požadavky nebylo možné splnit bez důkladné přípravy a konzultace před samotným vývojem v již tak krátkém termínu, který byl pro tuto část stanoven. Navíc jsme museli zohlednit další funkční požadavky, včetně zjednodušené mobilní verze.

Základní přehled obyvatele včetně ukázky mobilní verze
Rozdíl mezi monolitickou a microservice architekturou

Mikroservisy

Aneb modulovatelnost sama

Na základě požadavku modulovatelnosti jsme se rozhodli celý systém rozdělit na samostatné mikroservisy, kde se každá z nich stará o určitou část systému. V architektuře mikroservis je možné do celého řešení jednoduše přidat nový modul, třeba i bez nutnosti zásahu do stávajícího kódu. Další výhoda mikroservis spočívala v tom, že pro klienty s on-premise lze dodat jen ty části, které jim náleží, a není tak potřeba řešit problémy nutností uzamknout nezakoupené části systému. Naopak v cloudu, kde se o prostor virtuálního serveru dělí několik klientů, je možné jednoduše každou mikroservisu škálovat podle jejího vytížení.

V první fázi tak vznikly mikroservisy:

  • Autorizační jádro systému s informacemi o uživatelích a jejich právech

  • Správa klientů domova – primárně jejich informací a jejich ubytování

  • Služba zasílání e-mailů a SMS

  • Nahrávání binárního obsahu (např. fotky klientů k jejich profilu)

  • Logování všech akcí

  • Nastavení a plánování služeb s klienty; první volitelný modul 

Zpočátku měly všechny mikroservisy oddělený jak kód, tak databázi. Vnitřní komunikace probíhala vždy přes rozhraní jednotlivých mikroservis. Například vykreslení informací o klientovi domova zahrnovalo zavolání mikroservisy pro správu klientů, která se zeptala autorizační mikroservisy, zda má daný uživatel právo pro zobrazení těchto dat, načtení fotky klienta z mikroservisy s binárním obsahem, zalogování akce do mikroservisy s logy a finální načtení dat z mikroservisy se záznamy klienta pro návrat těchto dat na popředí, kde byla akce vyvolána.

Tenantizace

Rozdělení databáze

Provoz v cloudu jasně počítal s tím, že systém bude používat více domovů najednou. Tyto domovy však nemohou společně sdílet data. Proto bylo třeba zvolit určitou tenantizaci, respektive rozdělení databáze, aby jeden domov neměl přístup k datům z jiného domova. To bylo vyřešeno na úrovni databáze, kdy každá instance objektu má identifikátor určující, do kterého domova patří. Každý požadavek resp. výsledný dotaz do databáze je pak filtrován podle tenanta aktuálně přihlášeného uživatele. Uživatelé dostali i vlastní tenatský identifikátor pro rozlišení případu, kdy má jeden uživatel přístup do více domovů. Tenant tedy pro nás znamenal jeden domov.

Souhnrnné nastavení domova
Nastavení rolí v systému

Systém práv

Omezení přístupu k datům

Pro systém práv jsme použili knihovnu PRBAC (Partition Rule Base Access Control) a zabudovali ji přímo do frameworku Django, ve kterém jsme aplikaci vyvíjeli. Mohli jsme tak dynamicky a systémově nastavit každému objektu z každé mikroservisy vlastní přístupová práva, která byla uchována v autorizační mikroservise. Tato práva jsme nazvali jako atomická, jelikož jsme je dále seskupovali do shluků přiřazovaných na popředí k jednotlivým rolím, které mohou uživatelé získat. Kromě typických modelových práv je možné i dodatečně definovat vlastní práva, čehož jsme později využili pro ještě drobnější nastavení práv, např. pro změnu hesla jinému uživateli, speciální akce, opakované provedení výkonu, nebo pro celý konstrukt frontendových práv, která dále určil viditelné části popředí systému.

Služby

První rozšiřující modul

Jak jsme již uvedli ve výčtu mikroservis, jednou z prvních volitelných mikroservis byla mikroservisa se službami. S klienty domova je třeba periodicky provádět určité výkony. Tyto výkony mají určitý předpis –⁠ službu. Ta určuje, co je třeba provést. Výkon má již podobu časového údaje. Na základě přednastavené služby se dle nastavení domova generovaly výkony, které bylo třeba provést. Rozřazené byly dle jednotlivých tras či pater v domově.

Provádění výkonů na webu i v mobilu
Náhledy PWA mLegato

mLegato

Mobilní apka ve formě PWA

Další důležitou součástí zadání byla menší mobilní aplikace pro obsluhu výkonů. Klient požadoval, aby tato část mohla fungovat i offline, pokud by pracovník provádějící výkony neměl přístup k internetu. Měli jsme možnost tuto aplikaci vyvinout zvlášť, nicméně tato část by neúměrně zvýšila rozpočet a prodloužila dobu vývoje první fáze. Vzhledem k tomu, že akce v mLegatu kopírovaly funkce webové aplikace, rozhodli jsme se webovou aplikaci realizovat jako progresivní webovou aplikaci – celou aplikaci je tak možné stáhnout do mobilu a po přidání příslušných funkcí obsluhovat i offline. Díky tomu má pracovník možnost na svém mobilním telefonu provádět výkony a my jsme ušetřili na vývoji samostatné aplikace.

Reference klienta

"Firma Think Easy vyhrála výběrové řízení na vývoj ERP systému, které jsme vypsali. Realizace proběhla formou microservices architecture a progresivní webové aplikace. Oceňuji především rychlé reakce na naše požadavky a vážím si otevřené komunikace. Spolupráce s Matějem, Matoušem a jejich týmem nám dává smysl. S Think Easy se pouštíme do dalších fází našeho projektu."

Jakub Žákavec, Delpsys s.r.o.

Platformy a použité technologie

Jaké technologie jsme zvolili

Většina mikroservis byla naprogramována v Pythonu a jeho Django Rest Frameworku s použitím PostgreSQL databáze. K asynchronním činnostem byl využit plánovač Celery a redisová fronta. Pro mikroservisu k zasílání e-mailů bylo použito FastAPI, jelikož se jednalo o „průtokové“ API. Mikroservisa pro logování používá databázi Influx, která je vhodná pro vysoké množství dat s časovou značkou (tzv. timeseries databáze). Nasazení je připravené na Amazon Web Services. Popředí jsme realizovali jako progresivní webovou aplikaci v React.js/Typescript.

Hlavní přínos

Funkce systému v kostce

  • Obsluha klientů domova, uživatelů a jejich přístupových práv.
  • Plánování a provádění služeb pro klienty
  • V přehledech je možné řadit, filtrovat a vyhledávat
  • V detailech jsou nastaveny standardní akce úprav, potvrzení akce, smazání
  • Viditelné části detailu je možné částečně skrýt nebo odkrýt, skryté části zůstávají skryté i při překliku na jiný detail
  • V tabulkách je možné nastavit šířku jednotlivých sloupc
  • Každý objekt je možné smazat, pokud není nikde přiřazen, jinak bude deaktivován
  •  Propracovaný systém práv omezující přístupy, akce i viditelné části systému
  • Deaktivované objekty je možné znovu aktivovat
  • Systém obsahuje několik nastavení pro každý domov, resp. tenanta, jako je nastavení času generování výkonů dle služeb či délka plánu výkonů v mLegatu
  • Systém škálovatelných mikroservis
  • Příprava nasazení na cloud i on-premise
  • Logování veškerých akcí v systému
  • Všechny číselníky pro formuláře je možné nastavit v nastavení

Další fáze

Signalizace

Dozorce na bezpečí klientů

Ještě pred dokončením a doladěním první fáze jsme dostali nový požadavek: Integrovat již existující aplikaci signalizace do celého řešení. Signalizace je komponenta, která podle náramků, které nosí klienti domova a které se označují jako „brány“ (jejichž funkcí je pomocí signálu bluetooth sbírat polohu náramku), a za pomoci analyzujícího rozhraní dokáže určit polohu jednotlivých klientů a umožňuje tak jejich ochranu v případě nečekaných problémů. Uživatelé těchto náramků se mohou přihlásit o pomoc, kterou následně pracovníci domova vyřídí v mobilní aplikaci SignalDelp zobrazující jednotlivé alarmy. Systém také uměl nahlásit klienty mimo signál a určit jejich poslední polohu.

Aplikace byla napsána v Node.js, tedy v jiném frameworku než zbytek mikroservis. To ovšem u mikroservis není problém, ale spíše výhoda – přes rozhraní lze komunikovat s jakýmkoliv systémem. Do aplikace jsme dodatečně naprogramovali tenantizaci a celou mikroservisu integrovali jako nadstavbu mikroservisy s daty klientů. Po integraci jsme do webové aplikace Legata přidali možnost nastavení celého systému signalizace a dále jsme rozšiřovali dle požadavků klienta.

Nastavení signalizace v Legatu
Ukázka detailu klienta

Redesign, refaktor

Příprava pro další fáze

Po dokončení první fáze a integrace signalizace jsme se s klientem dohodli na celkovém redesignu a refaktoru popředí, jelikož byl vzhledem k termínu realizace vyvinut poměrně narychlo. Díky tomu jsme popředí revitalizovali a připravili na jeho několikaroční vývoj a dovedli ho do podoby, která je vidět na jeho náhledech. Zároveň jsme dokončili a doladili některé funkce tak, aby byly ucelené a kompletní.

Plánování

Volné přidělení výkonů

Při redesignu jsme také začali pracovat na modulu plánování – rozšíření mikroservisy služeb. Toto rozšíření umožňuje pracovníkům přiřazovat sami sobě jednotlivé výkony v týdnu v přehledné tabulce s několika dalšími funkcemi. Dále jsme v této fázi provedli úpravu aplikace mLegato a částečně změnili některé její funkce.

Ukázka kalendáře plánování
Záznamy v dokumentaci
Ukázka jednoduché mapy

Dokumentace

Další záznamy ke klientovi

Po plánování přišel na řadu modul dokumentace s několika dalšími funkcemi. Jednou z nich byla samotná dokumentace umožňující evidovat lékařské záznamy daného klienta domova. Tyto záznamy pak bylo možné i digitálně podepsat, což znemožnilo jejich další úpravu. Druhou funkcí, kterou jsme přidali, bylo ukládání dokumentů k klientovi. Ty jsme přidali do mikroservisy s binárními daty. 

Poslední a zároveň největší částí bylo přidání záznamů ke klientovi. Kromě jejich přidání, vyplnění klientskými daty a úpravy je bylo také možné vykreslit v plnohodnotně nastavitelné myšlenkové mapě. Záznamy mohou mít podobu textu, čísla, data atd. Nejzajímavější ovšem byla část vypočítaných hodnot. V tomto typu jsme umožnili administrátorům omezený přístup do databáze, díky kterému mohli sestavit dotaz na jakákoliv data ze systému a tak u klienta domova vykreslit různé vypočítané hodnoty, například kolik má v daném týdnu naplánovaných výkonů. Administrátor mohl vše nastavit, tudíž tyto hodnoty mohly být velice variabilní. Jejich výpočet probíhá asynchronně a každá vypočítaná hodnota má určitou životnost, než se znovu sama při dotazu přepočítá. K tomu, aby byla tato možnost řádně funkční, byly jednotlivé databáze přemigrovány jako jednotlivá schémata do společné databáze, která běží pod novou mikroservisou určenou k obsluze těchto záznamů.

V rámci tohoto modulu jsme také přidali nový typ práv, takzvaná typová práva. Dokumentace, dokumenty, záznamy i mapy měly totiž určitý typ, který je možné přidat ke každé roli. Pokud žádná role, kterou měl uživatel přiřazenou, neobsahovala právo na daný typ, uživateli se příslušné dokumenty, dokumentace, záznamy nebo mapy nezobrazily. Tato práva vznikají a zanikají s novými či smazanými typy objektů, které lze v nastavení systému dynamicky přidávat.

Externí modul

Dozorce i mimo domov

Poslední částí, kterou jsme společně s klientem implementovali, byla integrace externího modulu. Tento externí modul je ve své podstatě signalizace pro klienty, kteří využívají pečovatelskou službu ze svého vlastního domova. Tento modul umožňuje pokročilou analýzu posbíraných dat, takže dokáže analyzovat i pády či delší nehybnost klienta.

Modul byl integrován jako API třetí strany, tudíž není přímou součástí systému Legato a nejedná se tak o novou mikroservisu. Ve webové aplikaci lze nastavit různé prodlevy snímačů jak pro tenanta, tedy pro všechny klienty tohoto domova, tak i pro jednotlivé klienty samostatně.

Lokalizace expterním modulem