lunedì 16 gennaio 2012

Case study: Jasper Server, report e datawarehouse


La mia esperienza con Jasper Server comincia circa 2 anni fa quando, dovendo scegliere un prodotto di business intelligence e datawarehousing da adottare all'interno della mia area di sviluppo, ho fatto una veloce software selection tra i due principali competitor open source del momento: Jasper Server e Penthao.
Entrambe le soluzione mi sono subito sembrate valide ed equivalenti, molte delle API interne, ad esempio quelle per la modellazione degli iper cubi sono condivise.
Alla fine ho scelto Jasper Server Community Edition perchè il "feeling" iniziale ed i più veloci risultati che ero riuscito a ottenere in breve tempo mi avevano positivamente colpito.

Per ovvi motivi non entrerò nel dettaglio del mio progetto ma cercherò comunque di rendere l'idea di quello che è stato fatto.


Panoramica generale



Jasper Server è una suite integrata che consente di erogare servizi di reportistica anche molto complessi ma non solo.
Si presenta come una web application alla quale accediamo mediante user name e password. Una volta entrati al suo interno abbiamo la possibilità di esplorare il repository documentale composto tipicamente da report che è possibile eseguire "on the fly" in modo da visualizzare informazioni il più possibile aggiornate.
Una volta che il report viene renderizzato, abbiamo la possibilità di salvarlo nei formati più comuni (excel, pdf, html, xml, flash) oppure tenerlo on-line su una nostra cartella all'interno del repository di Jasper.
I report che è possibile generare sono limitati solo dalla bravura e dall'esperienza di chi li costruisce. Strumenti come i dataset, per accedere a differenti query, o i sub-report, da utilizzare come dei template da includere gerarchicamente dentro altri template sono solo alcuni dei punti di forza a nostra disposizione.



Creazione dei report

Il tool di riferimento per la composizione dei report è IReport, un'applicazione client di tipo grafico che ha il grosso vantaggio di potersi collegare in remoto direttamente sul repository di Jasper Server per costruire quelle che in gergo vengono chiamate "Report Unit".
La report unit rappresenta il nostro progetto per un singolo report e ci permette di organizzarlo caricando eventuali immagini da visualizzare, sub-report da usare in modalità template e altri utili componenti come le maschere filtro per la ricerca. Una volta pronta la report-unit viene salvata direttamente sul nostro repository e da li può essere testata utilizzando i dati reali.
Inutile dire che l'accesso alle nostre basi dati avviene definendo delle connessioni standard di tipo JDBC (o anche altri formati) e associando una specifica connessione al nostro report.

L'utilizzo di IReport consente di agire sul nostro report in maniera completamente grafica, tuttavia, per esigenze più spinte, è sempre possibile accedere al sorgente xml e agire sui vari tag ma devo dire che ad oggi salvo rare eccezioni non abbiamo mai avuto grosse necessità.



La schedulazione a tempo dei report



Fin qui abbiamo creato dei report e possiamo accedere al nostro server per consultarli. Quello che dal mio punto di vista risulta utilissimo per i miei scopi e la console di schedulazione grazie alla quale possiamo pianificare l'esecuzione batch dei nostri report decidendo se salvarne una copia in locale sul repository o se magari spedirla direttamente per posta elettronica ai nostri clienti.
Le opzioni di schedulazione sono molto varie e consentono di soddisfare la maggior parte delle esigenze.



Gli iper-cubi



Il primo iper-cubo non si scorda mai; ricordo ancora i miei primi esperimenti con i meta-modelli xml per definire il mio primo iper-cubo...
Ma andiamo con ordine. Se erogassimo solo report "stile excel" ci perderemmo la parte più bella delle potenzialità messe a nostra disposizione da Jasper Server.

Il mio problema, nel quotidiano, è quello di dover gestire e archiviare milioni di record su diversi database e trovarmi poi nella condizione di effettuare ricerche e dare viste aggregate di insieme con tempi di elaborazione anche molto lunghi.
Premesso quindi di aver lavorato per circa un anno alla creazione di un DataMart non banale con tabelle pre-aggregate che consentono una rapida interrogazione dei dati, siamo passati a modellare quello che nell’ambito del datawarehousing si chiama iper-cubo.
Un report non è altro che una vista non modificabile e pre-definita dei nostri dati tipicamente a due dimensioni (es. volume prodotti venduti nei vari mesi dell’anno). Un iper cubo è invece un’aggregazione di dati ottenuta su più dimensioni contemporanee e in maniera completamente dinamica.
Ovviamente per ottenere un report leggibile occorre avere ben chiaro il tipo di aggregazione che si vuole ottenere. Volendo semplificare grazie all’iper cubo siamo in grado di modellare report contenenti tabelle pivot molto complesse non necessariamente prestabilite a priori.
Supponiamo di dover partecipare ad un incontro e voler estrarre delle viste aggregate da utilizzare durante la presentazione. Grazie all’iper cubo, senza che nessuno abbia scritto per questa specifica esigenza una sola riga di codice o di sql, possiamo estrarre i volumi ed i ricavi sui singoli prodotti dividendoli per i vari mesi e organizzandoli magari per regione e città. Possiamo dinamicamente aggiungere un grafico che visualizzi l’aggregazione ottenuta e se scopriamo che in realtà volevamo qualcosa di diverso siamo sempre liberi di modificare i parametri di interrogazione del cubo e ottenere ad esempio una seconda aggregazione che rappresenta il volume dei prodotti raggruppato sulle varie aree dell’azienda e considerandolo magari rispetto ai trimestri dell’anno.
Probabilmente vedere un iper cubo in azione vale più di mille parole ma ad ogni modo spero di aver reso l’idea.
Il punto di forza è l’alta dinamicità delle interrogazioni e la totale assenza di effort legato al risultato.



Interfaccia Web Services



Con qualche settimana di sviluppo, abbiamo anche messo in piedi una personalizzazione documentata in modo da poter erogare i report anche in base a chiamate http apparentemente senza la componente di login al server di reportistica.
In realtà il connettore che abbiamo sviluppato sfrutta l’interfaccia web services messa a disposizione da Jasper Server per recuperare lo specifico report richiesto e l’interfaccia http semplifica e maschera questo livello di complessità riconducendo il tutto ad una semplice chiamata in GET.



Elaborazioni batch: Jasper ETL



Infine, avendo a che fare con basi dati e elaborazioni notturne, siamo passati ad utilizzare la componente ETL (Extract, Transform and Load) di Jasper per modellare graficamente semplici procedure di spostamento file e caricamento batch a fronte di elaborazioni e trasformazioni.
La potenza di uno strumento di ETL sta proprio nella sua interfaccia grafica e nel riuso di componenti già predefiniti.
Esempio tipico: mi arriva un file via ftp che devo aprire, modificare in base alle mie esigenze, caricare sulla mia base dati magari incrociandolo anche con altre informazioni che recupero da canali paralleli e avvisare che il caricamento è andato a buon fine.
Con un ETL possiamo definire l’intero flusso con degli schemi che collegano tra loro dei moduli applicativi belli e pronti: Il query execute, il file uploader, il web caller, il mail sender e via discorrendo.



Altro ancora...


Jasper Server sfrutta tecnologie ormai assodate e solide come Java, Spring, Quartz, Hibernate a altri framework.
Esistono ancora altri aspetti di personalizzazione offerti dai framework stessi che non abbiamo esplorato, ad esempio la possibilità di realizzare una dashboard personalizzata per gli utenti loggati al sistema di reportistica in modo da migliorare l’usabilità e la user experience generale.
Questa è solo una delle tante altre cose che è possibile fare con questa suite.

Concludo qui la mia breve panoramica con la speranza di aver dato almeno un’idea delle potenzialità che abbiamo a disposizione.

Nessun commento:

Posta un commento