Il nostro sito web fa uso di cookies di terze parti. Per le informazioni sul loro funzionamento e sulle modalità di disabilitazione si veda la nostra cookie policy. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsenti all’uso dei cookies. Leggi di più.OK

I Reports di Meta GS

di Denis Torresan

Questo sarà uno dei primi articoli più tecnici che abbiamo deciso di scrivere per raccontare il progetto, ed avendo progettato e realizzato il modulo della reportistica, ho pensato sia utile descrivere più nel dettaglio il suo funzionamento.
Innanzitutto va spiegata la situazione di partenza, ovvero quello che già altri software fanno, e quindi capire come gli istituti siano già abituati ad operare.

Una buona parte dei software per registro elettronico sul mercato utilizza prodotti quali ad esempio Crystal Report che permettono di generare reports in formato Word o PDF a partire da template in MS Word attraverso lo strumento della stampa unione.

Altri invece utilizzano “in background” il motore di rendering di MS Office per la generazione batch dei documenti sempre tramite stampa unione, questo secondo approccio ha lo svantaggio che Office sotto carico (immaginiamoci il periodo della stampa delle pagelle), spesso va in sofferenza, rendendo difficoltoso o rallentato stampare una grossa mole di reports.

Scelta della tecnologia

Abbiamo deciso di utilizzare il medesimo approccio: templates MS Word, quindi personalizzabili dai vari istituti, con renderizzazione dei dati attraverso la stampa unione, tuttavia la nostra idea è quella di realizzare un server multithread a cui demandare la stampa unione invocata attraverso l’interfaccia web di Meta.

In Fabvla ci definiamo “technology agnostics”, cerchiamo sempre per quanto possibile di scegliere la tecnologia più adatta in base al progetto specifico, anche in questo caso ci siamo interrogati molto su quale potesse essere la strada corretta per manipolare templates Word in un server che dovrà essere disponibile via HTTP, e abbiamo scelto un prodotto commerciale per il rendering di documenti Office, che dispone di un set di API richiamabili programmaticamente e sul quale verrà sviluppato l’intero server.

La libreria è sviluppata in .NET, probabilmente passaggio obbligato per ottenere piena compatibilità con il mondo Microsoft, perciò il server verrà realizzato anch’esso in .NET.

Dato che tutto il nostro stack è basato su Linux, abbiamo già fatto dei test risultati positivi circa l’utilizzo di Mono in ambiete Linux, dato che la libreria risulta compatibile.

Architettura

L’architettura hardware / software è riassunta nello schema qui di seguito riportato.

Lo stack è composto di tre server: Laravel (che gestisce il frontend), ReportServer (che gestisce la generazione dei report), Database condiviso tra i server per accesso indipendente dei vari servizi.

Il ReportServer dispone anche di uno storage condiviso dove vengono salvati i file dei reports generati.

 

Untitled Diagram-1

 

Il ReportServer

Il ReportServer è stato progettato appositamente per poter essere invocato “standalone”, e gestire richieste di generazione report in modo più possibile agnostico rispetto al database, al template da utilizzare e alla struttura dati.

Abbiamo creato quindi un server che riceve una richiesta HTTP in formato JSON, che abbiamo definito ‘descriptor’, e che permette di descrivere l’intero comportamento e le operazioni che il server dovrà fare all’atto della generazione di un report.

Il Descriptor JSON permette di definire in un unico oggetto:

  • La form con tutti i parametri di input, definendone per ognuno il tipo e l’eventuale sorgente dati
  • Tutte le query da eseguire e l’incapsulamento all’interno di “Entity”
  • I formati di output da generare
  • Il template da utilizzare

Il Descriptor JSON, è uno strumento che permette di rendere flessibile la definzione di report anche al personale scolastico dato che abbiamo implementato un editor per definire i report direttamente dall’interfaccia dell’applicativo.

Questo è l’esempio di un descriptor JSON con cui “parlare” con il nostro ReportServer:

jsondescriptor

Una ulteriore sezione del Descriptor permette di definire la form di input, con tutti i parametri di Input che è l’unica parte del descriptor che viene gestita da Laravel, in quanto viene generata una interfaccia web programmabile con tutti i parametri di input che l’operatore andrà a selezionare e che successivamente verranno passati al ReportServer.

In questo esempio si può notare che vengono gestite nativamente anche select annidate, in cui i valori di una selezione popolano un secondo campo che dipende dal primo:

2016-07-18 15h42_01

 

Il pulsante “Genera Report” esegue le seguenti attività: prende il Descrittore JSON base, a questo vengono aggiunti tutti i parametri impostati tramite il form precedente dall’utente ed una serie di ulteriori opzioni di sistema. Infine viene effettuata una chiamata al ReportServer passando come valore l’intero JSON prodotto.

Il ReportServer esegue tutte le operazioni e ritorna una lista di file generati, oppure in caso di errore, una descrizione di cosa è andato storto.

Come ulteriore strumento di diagnostica, abbiamo anche un pannello di debug che permette di vedere dall’interfaccia l’intero log che viene generato dal ReportServer.

Per ora è tutto, alla prossima!

Denis