streamalism.org

1. Áttekintés

Amikor arról beszélünk Jelentési eszközök, sok szoftver lefedi ezt a területet. Legtöbbjük azonban teljes értékű Üzleti intelligencia platformok vagy Felhőszolgáltatások.

De mi történik, ha csak néhány jelentési funkciót szeretnénk könyvtárként hozzáadni alkalmazásunkhoz? Itt áttekintünk néhányat Java jelentéseszközök jól alkalmas erre a célra.

Főleg ezekre a nyílt forráskódú eszközökre fogunk összpontosítani:

• BIRT
• Jasper jelentések
• Pentaho

Ezenkívül röviden elemezzük a következő kereskedelmi eszközöket:

• FineReport
• Logi jelentés (korábban JReport)
• Jelentés Mill

2. Jelentések tervezése

Ebben a szakaszban áttekintjük, hogyan tudjuk vizuálisan megtervezni a jelentéseket és hogyan játszhatunk az adatainkkal. Megjegyzés: ebben a részben csak a nyílt forráskódú eszközökre fogunk hivatkozni.

2.1. Vizuális szerkesztők

Mindhárom eszköz tartalmaz egy WYSIWIG szerkesztőt a jelentés előnézeti képességeivel.

BIRT Report Designer és Jaspersoft Stúdió az Eclipse RCP-re épített eszközök. Ez jó pont a legtöbb Java-fejlesztő számára, mivel ismerhetjük az Eclipse környezetet. Ezektől eltérően Pentaho riporttervező vizuálisan rosszul öregedett.

Ezenkívül van egy további érdekes funkció a Jaspersoft Stúdió: jelentéseinket közvetlenül azokon tehetjük közzé Jasper Reports Server (a jelentéskezelő rendszer).

2.2. Adatkészletek

Mint minden jelentéskészítő eszköz esetében, úgy az a lekérdezésével is lekérhetjük az adatkészleteket adatforrás (lásd lentebb). Ezután átalakíthatjuk őket jelentésmezőkké, létrehozhatunk számított mezőket vagy összesítési képleteket használhatunk.

Emellett érdekes összehasonlítani hogyan kezelhetünk több adatkészletet mivel többre is szükségünk lehet, ha adataink különböző lekérdezésekből származnak, vagy akár eltérőek is adatforrások:

• BIRT a legkönnyebb megoldást kínálja, mivel több adatkészlet is szerepelhet ugyanabban a jelentésben
• Val vel Jasper jelentések és Pentaho, minden egyes esetben külön aljelentést kell létrehoznunk, ami meglehetősen trükkös lehet

2.3. Diagramok és vizuális elemek

Minden eszköz egyszerű elemeket, például formákat és képeket, valamint minden diagram ízt tartalmaz: vonalak, területeken, piték, radar, gyűrűstb. Mindegyikük támogatja a keresztfüleket is.

Azonban, Jasper jelentések biztosítja a leggazdagabb vizuális elemek gyűjteményét. Ez kiegészíti a fenti listát térképeket, szikravonalak, piramisok, és Gantt-diagramok.

2.4. Stílusjelentések

Most hasonlítsuk össze az elemek elhelyezését és méretét az oldalon:

• Az összes eszköz biztosítja a pixelpozicionálást
• BIRT és Pentaho HTML-szerű pozicionálást is biztosít (táblázat, blokk, sorban)
• Egyikük sem támogatja a CSS-szerű flexbox vagy grid rendszert az elemek méretének szabályozásához

Ezenkívül, ha több jelentést kell kezelnünk, érdemes lehet ugyanazt a vizuális témát megosztanunk:

• Jasper jelentések témafájlokat biztosít XML-CSS szintaxissal
• BIRT importálhat CSS stíluslapokat a tervezési rendszerbe
• Val vel Pentaho, csak CSS stíluslapokat adhatunk az oldal fejlécébe. Tehát nehéz összekeverni őket a belső tervezési rendszerrel

3. Jelentések renderelése

Most, hogy láttuk a jelentések megtervezését, hasonlítsuk össze, hogyan tudnánk azokat programszerűen megjeleníteni.

3.1. Telepítés

Először jegyezzük meg az összes eszközt úgy tervezték, hogy könnyen beágyazható legyen egy Java projektbe.

A kezdéshez megnézheti a BIRT és a Jasper jelentésekről szóló külön cikkeket. A Pentaho számára van egy súgóoldal és ingyenes kódminták.

Ezután mindegyik eszközhöz csatlakoztatjuk a jelentésmotort az alkalmazás adatainkhoz.

3.2. Adatforrás

Az első kérdés, amelyet fel kell tennünk: hogyan kapcsolhatjuk össze a jelentésmotort a projekt adatforrásunkkal?

• Jasper jelentések: egyszerűen hozzáadjuk a fillReport módszer
• BIRT Ennek megoldása egy kicsit összetettebb: módosítanunk kell a jelentést, hogy az adatforrás attribútumokat paraméterként állítsuk be
• Pentaho-nak nagy hátránya van itt: hacsak nem vásároljuk meg őket PDI kereskedelmi szoftverek, JNDI adatforrást kell használnunk, amelyet nehezebb beállítani

Ha már az adatforrásokról beszélünk, mely típusok támogatottak?

• Mindhárom eszköz támogatja a leggyakoribb típusokat: JDBC, JNDI, POJO-k, CSV, XML és MongoDB
• REST API a modern projektek követelménye, azonban egyikük sem támogatja natív módon
  • val vel BIRT, kódolnunk kell a Groovy forgatókönyv
  • Jasper jelentések extra ingyenes plugint igényel
  • val vel Pentaho, kódolnunk kell a Groovy forgatókönyv vagy megszerezni a PDI kereskedelmi szoftver
• A JSON fájlokat natív módon támogatja Jasper jelentések és Pentaho, de BIRT külső Java elemző könyvtárra lesz szükség
• Ebben a mátrixban megtalálhatjuk a teljes összehasonlító listát

3.3. Paraméterek és futásidejű testreszabás

Mivel a jelentést összekapcsoltuk az adatforrásunkkal, rendereljünk néhány adatot!

A legfontosabb most az, hogy hogyan lehet lekérni a végfelhasználói adatainkat. Ehhez paramétereket adhatunk át a megjelenítési módszernek. Ezeket a paramétereket a jelentés megtervezésekor kellett volna meghatározni, nem futás közben. De mit tehetünk, ha például az adatkészletünk különböző lekérdezéseken alapul, a végfelhasználói kontextustól függően?

Val vel Pentaho és Jasper jelentések, ezt egyszerűen nem lehet megtenni, mivel a jelentésfájl bináris, és nincs Java SDK a módosításukhoz. Összehasonlítva, BIRT a jelentések sima-XML fájlok. Sőt, Java API-t is használhatunk ezek módosításához, tehát nagyon könnyű mindent futás közben testre szabni.

3.4. Kimeneti formátumok és Javascript kliensek

Szerencsére a legtöbb általános formátumot minden eszköz támogatja: HTML, PDF, Excel, CSV, sima szöveg, és RTF. Manapság azt is megkérdezhetjük, hogyan integrálhatjuk a jelentés eredményét közvetlenül weblapjainkba. Nem említjük azonban a PDF megjelenítő durva felvételét.

• A legjobb megoldás a használata Javascript az ügyfelek számára, hogy a jelentéseket közvetlenül egy HTML elembe tegyék. Mert BIRT, a Javascript kliens az Működtesse a JSAPI-t és mert Jasper jelentések, használnunk kell JRIO.js
• Pentaho nem nyújt mást, csak az iFrame integrációt. Ez a megoldás működik, de komoly hátrányai lehetnek

3.5. Önálló megjelenítési eszközök

Amellett, hogy beszámolónkat integráljuk egy weboldalba, érdekelhet bennünket egy dobozon kívüli megjelenítő kiszolgáló is. Minden eszköz saját megoldást kínál:

• BIRT Vieweregy könnyű webalkalmazás végrehajtandó minta BIRT igény szerint beszámol. Ez nyílt forráskódú, de nem tartalmazza a jelentéskezelési funkciókat
• mert Pentaho és Jasper-jelentés, csak kereskedelmi szoftvercsomagok vannak

4. A projektek állapota és tevékenysége

Először egy szót a licencekről. BIRT alatta van EPL, Jasper jelentések alatt LGPLv3, és Pentaho alatt LGPLv2.1. Így ezeket a könyvtárakat beágyazhatjuk saját termékeinkbe, még akkor is, ha azok kereskedelmi jellegűek.

Ezután megkérdezhetjük magunktól, hogyan tartják fenn ezeket a nyílt forráskódú projekteket, és ha a közösség továbbra is aktív:

• Jasper jelentések jól karbantartott adattárral rendelkezik, szerkesztője, a TIBCO Software stabil közepes aktivitással rendelkezik
• BIRT adattár karbantartott marad, de annak aktivitása nagyon alacsony 2015 óta, amikor az OpenText megszerezte az Actuate szerkesztőjét
• Hasonlóképpen, Pentaho az adattáraktivitás nagyon alacsony a Hitachi-Vantara 2015-ös felvásárlása óta

A Stackoverflow trendek segítségével ezt megerősíthetjük. A legkisebb népszerűség a BIRT és Pentaho, de mérsékelt a Jasper jelentések.

Mindhárom A Java jelentési eszközök népszerűsége az elmúlt 5 évben csökkent bár egyelőre stabilak maradnak. Ezt a Cloud és a Javascript ajánlatok megjelenésével magyarázhatjuk.

5. Kereskedelmi Java Reporting Tools

A nyílt forráskódú megoldások mellett néhány kereskedelmi lehetőség is rendelkezésre áll, amelyeket érdemes megemlíteni.

5.1. Finom jelentés

Finom jelentés eredetileg önálló kiszolgálóként lett végrehajtva. Szerencsére be tudjuk vonni a projektünkbe, ha használni akarjuk. Az összes JAR-t és erőforrást manuálisan kell másolnunk a WAR-ba, az eljárásukban leírtak szerint.

Miután ezt megtette, láthatjuk a Döntési platform a projektünkben URL-ként elérhető eszköz. Erről az URL-ről közvetlenül a megadott internetes nézetben, egy iFrame, vagy Javascript kliensük használatával. Programozott jelentéseket azonban nem tudunk létrehozni.

Egy másik hatalmas korlát a cél futásideje. A 10. verzió csak a Java 8 és a Tomcat 8.x verziókat támogatja.

5.2. Logi jelentés (korábban JReport)

A Fine Report-hoz hasonlóan a Logi Report-ot is önálló kiszolgálóként tervezték végrehajtani, de integrálhatjuk meglévő WAR-projektünk részeként. Így ugyanazzal a korlátozással kell szembenéznünk, mint a Finom jelentés: nem tudunk programszerűen jelentéseket generálni.

A Fine Reporttól eltérően. a Logi Report azonban szinte az összes servlet-tárolót és a Java 8–13-at támogatja.

5.3. ReportMill Reporting

Végül, A ReportMill-t azért érdemes megemlíteni, mert simán be tudjuk ágyazni minden Java alkalmazásba. Továbbá, mint a BIRT, nagyon rugalmas: futás közben testreszabhatjuk a jelentéseket, mivel ezek sima XML fájlok.

Azonban rögtön láthatjuk, hogy a ReportMill elöregedett, és a többi megoldáshoz képest gyenge tulajdonságokkal rendelkezik.

6. Következtetés

Ebben a cikkben áttekintettük a legismertebb Java jelentési eszközöket, és összehasonlítottuk azok jellemzőit.

Következtetésként az alábbi Java Jelentési Eszközök közül választhatunk a követelményektől függően:

A BIRT-t választjuk:

• Egy egyszerű könyvtárhoz cseréljen egy meglévő házi megoldást
• Azért legnagyobb rugalmasság és nagy testreszabási lehetőség

A Jasper jelentéseket választjuk:

• Ha szükségünk van egy jelentéstárra, amely kompatibilis a teljes értékű jelentéskezelő rendszer
• Ha fogadni akarunk a legjobb hosszú távú fejlődés és támogatás