¶ Reporting architektúra
¶ OData és Reporting Service
A B.eye rendszerben a reporting megvalósításának egyik kulcsfontosságú eleme egy OData V4 réteg, amely többfunkciós szereppel bír. Ez egy köztes réteg az adatbázis és a reporting kliens alkalmazás (Microsoft Excel) között. Egyik fő szerepe a jogosultságkezelés. Az adatok elérése OData végpontokon keresztül történik.
A jogosultságkezelésen felül a másik kulcsszerepe az OData rétegnek a benne elhelyezkedő Reporting Service. Ez a service fogad üzeneteket az alkalmazástól, hogy valamilyen módosítás ment végbe a rendszerben, aminek hatása van a reporting rendszerre is. Az üzenetek hatására a service különböző ágakon tárolt eljárások futtatásával karbantartja a reporting rendszer számára külön fenntartott adatbázis elemeket. Egy-egy karbantartási művelet hatására a service visszajelez, hogy sikerrel járt-e, invalid állapotba került a reporting adatstrukúra vagy valamilyen egyéb hiba keletkezett. Amennyiben invalid állapotba kerül a reporting adatstruktúra, úgy az architektúrát kiegészítve egy reporting ütemező logika bizonyos időközönként leellenőrizve elvégez egy teljes adatbetöltést a reporting adatstruktúrába.
¶ Reporting ütemező
Az előző fejezetben is említetten a reporting rendszerhez kapcsolódik egy ütemező is, amely segítségével automatizáltan tudunk adott események hatására műveleteket végezni annak érdekében, hogy az alkalmazás és a reporting rendszer azonos adattartalommal bírjanak.
¶ Reporting technológia
Ebben a fejezetben kerül részletes kifejtésre a reporting rendszer technológiai működése. A megértést segítő fontos fogalmak vastagon szedve kerülnek kiemelésre. Ezek olyan elemei a megvalósításnak, amelyek megértése elengedhetetlen.
¶ Reporting schema
A B.eye rendszerben a reporting rendszer megvalósítása redundáns adattárolással történik. Az alkalmazás adatainak adatbázis tárolása mellett a reporting rendszer kiszolgálása végett egy külön reporting schema került definiálásra az adatbázisban. Az itt tárolt adatok részben egyezhetnek az alkalmazás adatival, de ezen felül előkalkulált adatokat is tartalmazhatnak. A megvalósítás lényege, hogy:
- a kliens alkalmazásban (jelen esetben Microsoft Excel) az adatlekérés pillanatában semmiféle SQL oldali bonyolult számítás ne menjen végbe, minden adat előkészítve várakozzon a lekérésre
- az adatlekéréskor csak SQL oldali jogosultságkezelés történjen, ami azt jelenti, hogy a végpontokban definiált adathalmazból jogosultság függvényében az OData réteg a végpontnak megfelelő teljes adathalmazt vagy annak egy bizonyos szeletét adja vissza
- a visszaadott adathalmaz legyen primitív, ami azt jelenti, hogy kizárólag azonosítók és előkalkulált számértékek adatátvitele történjen, az azonosítók feloldását dimenzió lekérdezések mentén a kliens alkalmazásra bízzuk
¶ Reporting adatkörök
A fent említett reporting schema strukturálisan úgynevezett adatkörökre csoportosul. Az alábbi adatkörök kerültek definiálásra:
- lead
- mérföldkő szakasz
- számla
- allokáció
- időlejelentés
- költséglejelentés
- üzleti tervek
- tény csapatköltség
¶ Adatbázis szerkezet, további fogalmak
Minden adatkör szerkezetileg tartalmaz egy vagy több adattáblát, ahol az alkalmazásbeli adatokat és az előkalkulált adatokat tároljuk, valamint tartalmaz egy úgynevezett adatkör loader tárolt eljárást, amely lényegében az adatokat betölti az adattáblákba. A megvalósítás további különlegessége, hogy minden adattábla és tárolt eljárás A és B variánssal is szerepel a reporting schema-ban. A két variáns minden esetben strukturálisan teljesen azonos. Az A és B variáns egy úgynevezett snapshot pillanatképet tartalmaz az adatokról, amelyet adott esetben karban tudunk tartani, vagy azt tudjuk rá mondani, hogy invalid az állapota, ezért a másik variánsba keletkezzen egy új snapshot, ami már teljességgel érvényes. Ennek megértését legjobban példákon keresztül fogjuk látni, de ahhoz még fontos pár fogalmat tisztázni.
Az alkalmazás használatakor eseményeket végzünk a rendszerben. Ilyen esemény lehet a teljesség igénye nélkül például: egy időlejelentés létrehozása, projekt számainak követése a projektmenedzser által, számla rögzítése, devizaérték módosítása, stb.
Az események típusuk szerint az alábbiak lehetnek:
- létrehozó esemény (CREATE)
- módosító esemény (UPDATE)
- törlő esemény (DELETE)
Egy adott esemény komplexitás szerint lehet:
- egyszerű – egy adatkört érintő változtatás
- összetett – több adatkört is érintő változtatás
Egy-egy esemény komplexitása meghatározza, hogy milyen műveletcsoport végrehajtása szükséges a reporting schema-ban, hogy az továbbra is konzisztens állapotban legyen az alkalmazás schemajával. Minden esemény reporting schema-ra gyakorolt hatását maga az adatkör loader tartja karban, tehát komplexitástól függetlenül az esemény bekövetkeztével paraméteresen meghívódik az adatkör loader.
Az egyszerű események, olyan események, amik lefutása és hatása gyors, egy adatkört érintőek. Az egyszerű események reporting lefutását inkrementális lefutásnak nevezzük. Egy szemléletes példa lehet erre egy allokáció módosítása:
- a felületen az allokáció módosításának hatására a módosítás lementődik az alkalmazás adatschema-jába
- ezután az OData reporting service kap egy üzenetet az alkalmazástól, hogy karbantartás szükséges a reporting schemaban
- meghívódik az allokációs adatkör loader UPDATE paraméterrel a megfelelő allokációs azonosítóval
- az azonosító segítségével a loader megkeresi azokat az adatokat és előkalkulációkat, amelyeket frissíteni kell, és elvégzi a karbantartást a konzisztencia megtartása végett
Az összetett események, olyan események, amelyek lefutása nem tud azonnal végbe menni, mert adott esetben több adatkört is érintő változások, amelyek eredményeképp sok helyen idézünk elő változást a reporting schema-ban. Az ilyen események lefutását full-load lefutásnak nevezzük, és ennek eredményeképp az egész reporting schema tartalmát újratöltjük. Erre jó példa lehet egy adott deviza árfolyamának megváltoztatása:
- a felületen a devizaárfolyam módosításának hatására a módosítás lementődik az alkalmazás adatschema-jába
- mivel ez a változás nagyon sok előkalkulációt érinthet, ezért az OData reporting service kap egy üzenetet, hogy invalidálja az éppen aktuálisan érvényes snapshotot (amely vagy A vagy B variánsban szerepel)
- a reporting rendszer ütemezője ránéz, hogy az éppen érvényben lévő snapshot invalid-e, és ha igen, akkor a másik variánsban elkezdi az adatkör loadereket lefuttatni
- ennek végeztével, amikor az érvényes snapshot előállt, szemafor logikával átváltja a variánst, hogy a reporting rendszer tudja, hogy melyik variánsból kérje le az adatokat.
Ennek a megoldásnak a leglényegesebb eleme az, hogy nincsen olyan időpillanat a rendszerben, amikor a kliens reporting alkalmazás nem tudna letölteni adatot. Az inkrementális lefutás a másodperc töredéke alatt végbemegy, így az adatok megjelenése azonnali. A full-load esetén annak elkészültéig továbbra is elérhető a kliens számára az előző adathalmaz, annak befejezésével pedig automatikusan az újrakalkulált értékek jelennek meg a reporting kliensen az adatfrissítés hatására.
¶ Hibakezelés
Mivel architekturálisan különálló entitások közötti kommunikáció zajlik a reporting rendszer működése érdekében, ezért természetesen felmerülhetnek mind a kommunikációban, mind az entitásokon belül is hibák (például: SQL adatbázis hiba).
A különböző hibatípusok kezelése alapvetően egységesen zajlik, hiszen a Reporting Service fel van készítve a hibakezelésre olyan módon, hogy az esetlegesen felmerülő hibákat detektálja, és automatikus módon hibajavító algoritmussal ezeket lekezeli. Ha egy hiba bekövetkezik és inkonzisztens lesz az alkalmazás adatbázis sémája a reporting rendszer sémájához képest, akkor az éppen érvényben lévő snapshot invalidálásra kerül, majd az előző fejezetben említett módon az invalid állapot miatt a reporting rendszerhez kapcsolódó ütemező a következő periódusában egy új snapshotot készít, így újra azonos lesz a két séma, és az Excel reportok adatai újra a valós adatokat fogják tartalmazni.
Amennyiben nem szeretnénk megvárni, hogy az ütemező magától a következő periódusában javítsa az esetlegesen felmerült hibát, úgy lehetőségünk van manuálisan is teljesen új snapshotot készíteni a B.eye rendszerben az alábbi lépésekkel adminisztrátor jogkörrel:
- Karbantartás menü / B.eye ütemező
- Ütemező típusa: Riport snapshot
- Indítás gomb megnyomása
A művelet alatt színkódok jelölik a snapshot jelenlegi állapotát:
- piros, ha az adott snapshot hibára futott
- sárga, ha az adott snapshot invalid állapotba került (az egész reporting schema tartalmát újratölti a rendszer, mely a következő ütemezett időzítés alkalmával történik meg)
- kék, ha éppen fut az adott snapshot készítése
- zöld, ha érvényes és aktuális az adott snapshot
Előfordulhat természetesen olyan SQL oldali hiba is a rendszerben, amelyet az algoritmus fizikai korlátai miatt nem tud javítani. Ezek olyan hibák lehetnek, amikor az alkalmazásban előállt adatok nem tudnak eleget tenni a reporting rendszer sémájának megkötéseivel (például: előállt véletlen folytán az alkalmazásban egy érték nélküli (NULL) költség, amely a reporting rendszerben nem megengedett). Az ilyen hibák minden esetben jelzésre kerülnek pirossal a B.eye ütemező Riport snapshot felületén (jelezve az adott soron az SQL oldali hibaüzenetet), de az ütemező ezeket a következő futáskor nem tudja javítani. Ilyen ritka esetekben az adott hibák egyedi felülvizsgálatot követelnek, ezért az ilyen típusú SQL hibák esetén szükséges felkeresni a B.eye alkalmazás adminisztrátorát.