Documento di testplan Modulo di Aggregazione Documento di progetto (Codici: A3P13S3)

Transcript

1 Piattaforma tecnologica di Monitoraggio Qualità Servizi Erogati Documento di testplan Modulo di Aggregazione Documento di progetto (Codici: A3P13S3) Riferimento Data Destinatario Gianluca Vannuccini Comune di Firenze Presentata da Antonio Cavallari (Capo Progetto Altran) Lista di distribuzione per approvazione da Enti Collaudatori Nome Data Ente Pagina 1

2 Indice 1 Introduzione Scopo del documento Riferimenti Configurazione di riferimento e modalità di test Definizione dei diritti di accesso per i diversi profili Ambiente di Test Note sull uso dei codici univoci Acquisizione automatica dei dati quantitativi Ambito e descrizione sintetica del capitolo Acquisizione dei dati quantitativi tramite Viste Prerequisiti per gli scenari di test Considerazioni aggiuntive Scenari di riferimento Esempi di vista e configurazione del client JMS Esempio di struttura dati XSD Acquisizione dei dati quantitativi tramite Web Service Prerequisiti per gli scenari di test Scenari di riferimento Esempio di file XML inviato tramite WS Revisione Inserimento Dati e import CSV/XML Prerequisiti per gli scenari di test Scenari di riferimento Esempi di XML/CSV compliant con la struttura XSD Attivazione dei processi ETL Dati Quantitativi Prerequisiti per gli scenari di test Scenari di riferimento Acquisizione manuale dei dati qualitativi tramite import XLS Ambito e descrizione sintetica delle funzionalità del modulo Import dei dati qualitativi Prerequisiti per gli scenari di test Scenari di riferimento Formato del file XLS per l import dei dati aggregati sui questionari Attivazione dei processi ETL Dati Qualitativi Prerequisiti per gli scenari di test Scenari di riferimento Inserimento e gestione trasformazioni Ambito e descrizione sintetica delle funzionalità del modulo Funzionalità di gestione delle trasformazioni Prerequisiti per gli scenari di test Scenari di riferimento Post-requisiti Funzionalità di calcolo delle trasformazioni Prerequisiti per gli scenari di test Scenario di riferimento Funzionalità di visualizzazione delle istanze di indicatori Prerequisiti per gli scenari di test Scenari di riferimento...33 Pagina 2

3 1 Introduzione 1.1 Scopo del documento Il presente documento raccoglie i casi di test, comprensivi delle modalità per la riproduzione di tali scenari, per il deliverable A3P13 (modulo per l aggregazione dei dati quali/quantitativi). All interno del rilascio del deliverable software A3P13 si inserisce anche, come estensione dell anagrafe dei servizi, il modulo logico per la gestione delle trasformazioni che consentono di inserire dinamicamente le formule per il calcolo degli indicatori qualitativi e quantitativi (rispettivamente da percentuali di risposte e indicatori intermedi o da variabili e indicatori intermedi). ll modulo logico per l aggregazione dei dati è responsabile della gestione delle attività di acquisizione automatizzata dei dati quantitativi provenienti dai sottosistemi dell Ente, secondo un formato concordato. In tal modo, si intende regolamentare il processo di acquisizione dei dati dai vari sistemi informativi gestionali di back office degli Enti, che contengono dati sull erogazione dei servizi che sono utili al monitoraggio complessivo della qualità e quantità dei servizi erogati da un Ente, in conformità con le specifiche tecniche di aggregazione dei dati definite in A3P7 in termini di interfacce esposte e strutture dati richieste. Rispetto alle modalità di acquisizione automatica presenti in offerta tecnica, le responsabilità dell estrazione dei dati dai sistemi esterni (o di acquisizione dei dati da questi) non è gestita attraverso procedure ETL statiche ma sono delegate alla console web di gestione della piattaforma di monitoraggio, per supportare le caratteristiche di dinamicità alla base del sistema. Di fatto, quindi, è l applicazione web a condurre il processo di prelievo dei dati da un apposita vista messa a disposizione dall Ente e/o ad esporre un web service per l acquisizione di un file XML di popolamento delle variabili associate ad una rilevazione. Una volta acquisiti dall applicazione e validati dagli operatori, in conformità con l approccio organizzativo proposto dal Comune di Piacenza, i dati raccolti (in automatico o tramite data entry) sono quindi aggregati a livello di ETL e processati per la rappresentazione successiva tramite la suite di Business Intelligence Pentaho. A seconda degli schemi di dispiegamento, la base dati può contenere i dati di un solo Ente o, nel caso di installazione comune della piattaforma presso un Ente aggregante, i dati di più Enti afferenti la stessa installazione fisica. Come modalità aggiuntiva rispetto al solo Web Service è stato infatti concordato, durante le riunioni di progetto con gli Enti coinvolti, di includere come fonte principale di alimentazione la possibilità di prelevare i dati da una vista complessiva (specifica per ogni Ente) contenente i dati necessari per la piattaforma, conformemente con la definizione della struttura dati associata alla rilevazione e definita in anagrafe (formalizzata tramite file XSD). Ove necessario, rimane valida la possibilità di inviare alla piattaforma i dati per il popolamento delle istanze di servizio tramite Web Service, allegando il file XML di popolamento conforme alla struttura XSD derivante dalla definizione in anagrafe. Inoltre, è stata aggiunta anche la possibilità di acquisire dei dati qualitativi su questionari erogati al di fuori della piattaforma (e.g. a sportello o tramite CATI), già aggregati e in conformità con le strutture dati dei questionari (rispetto assoluto dei codici identificativi di ogni item del questionario) presenti nella piattaforma, basati su un template comune. Per supportare il pieno rispetto delle caratteristiche di dinamicità del servizio, offerte dall anagrafe, non è possibile procedere con la definizione di trasformazioni univoche (statiche) per il calcolo degli indicatori di qualità. Pagina 3

4 Come modellato nello schema in Figura 1, sarà un esperto statistico dell Ente a modellare le relazioni (elementari) degli indicatori versi variabili, indicatori (intermedi e/o complessivi) e risposte alle domande dei questionari, attraverso una specifica interfaccia di gestione del modulo di aggregazione. Per ogni indicatore presente nella piattaforma, l esperto statistico può inserire al più una trasformazione attiva che ne definisce le istruzioni di calcolo per tutte le rilevazioni aggregate dall istante successivo alla definizione di tale trasformazione. La piattaforma, ricevendo i dati tramite il tool per l inserimento dei dati quali/quantitativi e dal modulo di aggregazione sulle variabili d uso/performance e su quelle sulla qualità progettata/erogata, provvede ad alimentare le strutture dati aggregate corrispondenti. Il modulo di aggregazione riceve dal tool per l inserimento dei dati qualitativi le risposte dei questionari, le aggrega (calcolo della media per ogni singola risposta); tali dati aggregati costituiscono una sorta di variabili di customer satisfaction per l inserimento all interno delle regole di trasformazione definite. Infine, il modulo di aggregazione applica le trasformazioni definite per il calcolo degli indicatori derivati/complessivi. Figura 1: Processo di elaborazione degli indicatori La piattaforma consente di modellare dinamicamente le trasformazioni per il calcolo degli indicatori intermedi e complessivi per un servizio. Per supportare una reportistica basati su cruscotti, invece, occorre che le formule per il calcolo degli indici di qualità per sottotipologie di indicatori, tipologie di indicatori, servizi e Enti siano definite staticamente, dando la possibilità di modellare una gerarchia finita di relazioni tra i dati. Pagina 4

5 1.2 Riferimenti La descrizione degli scenari di test del modulo A3P13, realizzato in conformità con il deliverable A3P7, richiede come prerequisito la conoscenza delle funzionalità precedentemente sviluppate: Tool di gestione dell Anagrafe dei Servizi (A3P8) e il tool di inserimento dei dati quali/quantitativi (A3P1) in esso integrato. Si fa, pertanto, riferimento ai documenti: A1P1 - definizione di indicatori quantitativi e qualitativi dei servizi erogati attraverso diversi canali A1P2 - definizione di indicatori di customer satisfaction dei servizi erogati sui diversi canali A3P1S4 Test-plan del deliverable A3P1 A3P6 documento di specifiche tecniche sulla struttura dell anagrafe dei servizi A3P7 Specifiche tecniche piattaforma di aggregazione dati quali-quantitativi per il monitoraggio e specifiche del DB contenente i dati aggregati di monitoraggio Documento Indicatori Asili Nido QUALITATIVI v4.pdf del Comune di Firenze Documento Indicatori Asili Nido QUANTITATIVI v2.pdf del Comune di Firenze Documento Raccolta dati quantitativi - Foglio Master.xls del Comune di Piacenza Politecnico di Milano Documento organizzativo del Comune di Piacenza Politecnico di Milano Pagina 5

6 2 Configurazione di riferimento e modalità di test 2.1 Definizione dei diritti di accesso per i diversi profili Come linee guida per la gestione dei profili, tutte le sezioni della console di gestione (e quindi tutte le funzionalità presenti) sono accessibili ai profili di tipo SUPER-USER. Tale profilo è una sorta di amministratore della piattaforma, in gradi di creare degli Amministratori specifici per ogni Ente presente nella piattaforma. Un AMMINISTRATORE ha pieno accesso alle funzionalità specifiche per un Ente, mentre ha funzionalità limitate per quanto riguarda l operatività su aspetti della piattaforma che hanno un impatto su più Enti. Su delega dell Amministratore, su un sottoinsieme di funzionalità strettamente correlati, lavorano dei profili specializzati. La tabella seguente riassume i diritti di accesso ai primi due livelli della struttura del menu da parte dei profili presenti nella piattaforma (in rosso sono evidenziate le funzionalità introdotte nel presente rilascio). Voce di Menu Tipo Super Esperto Operatore Operatore Amministratore User Statistico Questionari Data Entry CONFIGURAZIONE 1 livello SI NO NO NO NO Amministratori Enti 2 livello SI NO NO NO NO Enti 2 livello SI NO NO NO NO Classi di Servizio 2 livello SI NO NO NO NO Piattaforma 2 livello SI NO NO NO NO AMMINISTRAZIONE 1 livello NO SI NO NO NO Gestione utenti 2 livello NO SI NO NO NO ANAGRAFE SERVIZI 1 livello SI SI SI NO NO Variabili 2 livello SI SI SI NO NO Indicatori 2 livello SI SI SI NO NO Rilevazioni 2 livello SI SI SI NO NO Trasformazioni 2 livello SI SI SI NO NO QUESTIONARI 1 livello SI SI SI SI NO Template 2 livello SI SI NO NO NO Back-Office 2 livello SI SI SI NO NO Front-Office 2 livello SI SI SI SI NO DATI QUANTITATIVI 1 livello SI SI NO NO SI Popolamento variabili 2 livello SI SI NO NO SI AGGREGAZIONE DATI 1 livello SI NO NO NO NO Import dati qualitativi 2 livello SI NO NO NO NO Le foglie dell albero (ovvero il terzo livello) ereditano i diritti di accesso impostati per il secondo livello. L unica eccezione è costituita dall azione di clonazione di un questionario che, pur appartenendo al menu di Back-Office, è accessibile al solo profilo SUPER-USER. La home_page per il profilo <SUPER-USER> è la pagina di ricerca degli Enti del sistema, mentre per un profilo di <AMMINISTRATORE> coincide con la pagina di gestione delle rilevazioni. Per quanto riguarda i profili specifici, delegati dall Amministratore dell Ente, un utente con profilo <ESPERTO_STATISTICO> accede come home page personale alla pagina di ricerca della sezione Gestione questionari ; un utente con profilo <OPERATORE QUESTIONARI> accede alla pagina di ricerca dei questionari da compilare; un utente con profilo <OPERATORE DATA ENTRY> accede alla lista delle istanze di servizio per le quali inserire i dati quantitativi di popolamento. Pagina 6

7 Per quanto riguarda le funzionalità non accessibili dall interfaccia di gestione della piattaforma, le credenziali di autenticazione per l accesso al web service autorizzate sono quelle dei profili di Operatore Data Entry, Amministratore e Super-User. L avvio dello script per il recupero dei dati dalla vista di un Ente, se non gestito tramite cron, è disponibile solo per gli utenti con accesso alla shell della macchina applicativa. 2.2 Ambiente di Test Il software è stato testato nell ambiente di sviluppo del fornitore, su macchine Linux e Windows, verificando il corretto funzionamento dei moduli oggetto di rilascio su DBMS Oracle (versioni 9 e 10 come da capitolato, nonché sulla 11 come richiesto dal Comune di Parma, con configurazioni in RAC o singola istanza) e MySQL (versione 5.1). Il funzionamento delle funzionalità dei servizi web è stato verificato sui browser IE Explorer (versioni 6.x, 7 e 8), Mozilla Firefox (3.0.x, 3.5.x), Google Chrome e Opera 9.x. Le funzionalità rese disponibili dal modulo A3P13 sono accessibili in modalità stand-alone (recupero dei dati da vista tramite script dedicato, invocazione del web service da un client dell Ente) o in maniera integrata (upload CSV/XML dei dati quantitativi e upload XLS dei dati qualitativi) all interno della console di gestione della piattaforma, che rende disponibili i servizi trasversali di gestione dell autenticazione, dell autorizzazione e delle sessioni di lavoro già descritte per l Anagrafe dei Servizi. 2.3 Note sull uso dei codici univoci Per supportare la confrontabilità dei risultati delle indagini statistiche tra installazioni diverse della piattaforma e Enti diversi, la piattaforma deve supportare dei meccanismi per la definizione di oggetti standard (questionari standard di riferimento per template e questionari, indicatori standard ad essi associati, classi di servizio), regolati dalla definizione di accordi tra gli Enti IQuEL coinvolti. In particolare, nella riunione plenaria del 3 luglio, si è imposto come vincolo, per permettere il benchmarking, che tutti gli oggetti della piattaforma (Enti, servizi, variabili, indicatori, rilevazioni, questionari, domande, qualificazioni, risposte e trasformazioni) devono possedere un codice univoco di riconoscimento, per consentire in seguito l aggregazione con dati raccolti esternamente alla piattaforma e la confrontabilità tra dati gestiti da diverse installazioni della piattaforma. In particolare per i dati qualitativi, l esigenza di base è quella di garantire un meccanismo per supportare l acquisizione e il confronto, a fini di benchmarking, di dati raccolti non solo attraverso la piattaforma di monitoraggio ma anche attraverso indagini CATI, secondo un formato concordato basato appunto su codici univoci. In tal modo, è possibile confrontare anche questionari composti da un numero diverso di domande o caratterizzati dalla loro presentazione in ordine diverso, con più domande, con diverse risposte possibili. In fase di aggregazione, la presenza di questi codici consente comunque di garantire la confrontabilità dei dati comuni, identificati tramite codice. Proprio questa flessibilità richiesta nella definizione dei questionari non consente di impostare dei codici di default per domande, risposte e qualificazioni: la visibilità infatti non deve essere limitata al questionario che si sta creando ma allo scenario complessivo di tutti gli Enti partecipanti all iniziativa. E quindi necessario predisporre e condividere una schema di questionario comprensivo dei codici da inserire. Pagina 7

8 La Figura 2 mostra lo schema con i primi codici condivisi, per quelle che sono le entità principali gestite dalla piattaforma. Figura 2: Tabella riassuntiva dei codici condivisi tra gli Enti A livello di evoluzione futura, qualora un Ente stand-alone voglia usufruire della piattaforma al di fuori delle funzionalità di benchmarking tra Enti che caratterizza la piattaforma, sarà possibile introdurre una sorta di protocollo interno per la creazione automatica (o parametrizzabile) dei codici. Pagina 8

9 3 Acquisizione automatica dei dati quantitativi 3.1 Ambito e descrizione sintetica del capitolo Il tool per la rilevazione dei dati quali/quantitativi (A3P1) ha già introdotto due modalità per l inserimento dei dati quantitativi, attraverso un interfaccia tabellare specifica per il data entry o eseguendo l upload di un file XML/CSV correttamente formattato, al fine di popolare le variabili associate ad un istanza di servizio attiva. L interfaccia manuale, sotto forma di tabella, consente inoltre di approvare i dati inseriti tramite upload, eseguendo eventualmente aggiunte o correzioni, in conformità con il documento organizzativo del Politecnico di Milano. Solo dopo aver inserito tutti i valori richiesti nel rispetto dei vincoli di inserimento, è possibile inviare i dati al processo di aggregazione archiviando l istanza di servizio. Il modulo di aggregazione A3P13 completa le modalità previste per l inserimento dei dati quantitativi, ovvero di popolamento delle variabili associate ad istanze di servizio attive, attraverso due modalità di acquisizione dei dati: Recupero da parte della piattaforma dei dati sulle variabili attraverso l accesso ad una vista (specifica per Ente) appositamente predisposta dall Ente secondo il formato definito in anagrafe per il servizio; Invio alla piattaforma dei dati, in forma aggregata, provenienti dai sottosistemi dell Ente, tramite Web Service, presentando i dati sotto forma di attachment XML compliant alla definizione del servizio in anagrafe. Per omogeneizzare le strutture dati coinvolte e rispondere alla variazioni nella struttura XSD di riferimento per un istanza di servizio, introdotte in seguito all introduzione dei codici IQuEL, si è inoltre proceduto con l aggiornamento della funzionalità di import manuale (CSV/XML) presenti sino alla versione 3 della piattaforma. In particolare, come mostrato nella figura seguente, l acquisizione dei dati tramite import XML/CSV viene ricondotta agli scenari di aggregazione dei dati, centralizzando la logica di validazione dei dati acquisiti per procedere con il caricamento delle strutture dati della piattaforma. Pagina 9

10 Figura 3: Schema dei processi di acquisizione dati e validazione dei dati quantitativi 3.2 Acquisizione dei dati quantitativi tramite Viste La modalità principale di alimentazione automatizzata è costituita dalla possibilità di recuperare i dati attraverso una vista, unica per ogni Ente afferente la piattaforma, su una base di dati generalizzata che racchiude i dati dell Ente di interesse per la valutazione della qualità nell erogazione dei servizi misurati dalla piattaforma. Se gli Enti intendono realizzare un aggregazione di dati presso una base dati unificata, è possibile definire le informazioni sulla base dati da cui attingere i dati di popolamento a livello di configurazione della piattaforma, limitando l onere per l operatore dell Ente alla definizione di quale vista definita sul DB andrà ad alimentare la singola istanza di servizio. Viceversa, nel caso in cui i dati di popolamento possano arrivare (sempre comunque in forma atomica) dall interazione con schemi diversi per ogni Ente presente sulla piattaforma, l amministratore della piattaforma deve configurare ogni client JMS per recuperare i dati dalla vista di riferimento per l Ente (assunta sempre unica). Per quanto riguarda le modalità di attivazione, la piattaforma consente di lanciare l acquisizione dei dati dalla vista manualmente, attivando lo script su input diretto dell operatore, conformemente all organizzazione proposta (esigenza di approvazione) e alla criticità dovuta alle caratteristiche di tipo one-shot del caricamento (se i dati fossero incompleti, non si avrebbe più la possibilità di alimentare automaticamente il sistema). All interno dello schema restituito dalla vista, devono essere presenti tutte le variabili disponibili per i diversi servizi di cui si sta effettuando il popolamento. Pagina 10

11 3.2.1 Prerequisiti per gli scenari di test I prerequisiti per la verifica di questa modalità di alimentazione sono i seguenti: Definizione nella piattaforma di un insieme di variabili e di almeno un indicatore; Definizione e attivazione in anagrafe dei servizi di una rilevazione per l Ente, associata ad almeno una variabile e un indicatore, definendo l intervallo temporale del periodo di riferimento dell istanza di servizio (con unico check data fine > data inizio). Predisposizione di una vista (complessiva per tutti gli Enti afferenti la piattaforma o una vista specifica per ogni Ente) su un DB dell Ente, conforme alla definizione della rilevazione in anagrafe, raggiungibile dal server applicativo su cui è pubblicata l applicazione web di gestione della piattaforma; o La vista è conforme allo schema seguente: codice_ente codice_servizio codice_iquel_variabile valore_variabile data_riferimento_valori Considerazioni aggiuntive Lo script di avvio del client JMS per il recupero dei dati è specifico per ogni Ente, per disaccoppiare i parametri di configurazione e scheduling previsti, e può accedere ad una sola vista (complessiva per tutti gli Enti o specifica per ogni Ente) definita all interno di un DB dell Ente. Il client può quindi interrogare nel complesso più viste, ma ogni popolamento automatico avviene a partire da una sola vista. E possibile configurare, in caso di necessità di pianificazione dell alimentazione, l avvio dello script tramite uno scheduler (soluzione disponibile su ambienti Linux e Windows). Come definito nel workflow di inserimento dati di A3P1, una volta impostato il flag popolato=true l istanza di servizio non è popolabile in nessuna delle modalità automatiche (vista, WS, import csv/xml) ma solo tramite editing diretto sulla tabella, sino all approvazione dei dati inseriti e all invio al processo ETL di aggregazione ed elaborazione dei dati Scenari di riferimento L acquisizione dei dati quantitativi non presenta interfacce grafiche accessibili dalla console di gestione ma è gestita attraverso uno script (.sh su sistemi linux e.bat su sistemi windows) che consente l avvio del processo di caricamento ed elaborazione dei dati. Pertanto, lo scenario principale prevede la configurazione del client JMS (con i parametri per l accesso alla vista contenente i dati di alimentazione delle vista; non sono previste configurazioni extra dovute all uso del JMS), la sua esecuzione una volta disponibili i dati di alimentazione e il successivo accesso alla piattaforma web per procedere con l approvazione dei dati inseriti. 1. Il responsabile tecnico della piattaforma configura il file clientjms-properties.xml del Client JMS specifico dell Ente per il quale si vogliono recuperare automaticamente i dati da una vista di aggregazione, inserendo URL, username e password per la connessione al DB contenente la vista, specificando il driver necessario. 2. Il responsabile tecnico della piattaforma configura il file ExportVariabiliDAO.properties personalizzando il nome impostato per la vista di alimentazione predisposta dall Ente. 3. Il responsabile del servizio comunica al responsabile tecnico della piattaforma che sono disponibili tutti i dati quantitativi, acquisibili automaticamente, inerenti una rilevazione. Pagina 11

12 4. Il responsabile tecnico della piattaforma verifica che la vista di alimentazione contenga esclusivamente dei dati completi sulle rilevazioni che si intendono alimentare. a. La chiave logica della vista è data dalla terzina {codice_ente, codice_servizio, codice_variabile} in modo da garantire la non sovrapposizione dei dati di popolamento; 5. Il responsabile tecnico della piattaforma avvia, eseguendo lo script specifico dell Ente, il client JMS per l acquisizione dei dati. 6. Il client recupera tutti i dati presenti nella vista di alimentazione dell Ente e li invia all adapter; a. Eventuali condizioni di errore sono gestite dalla script, che si interrompe senza conseguenze per la console di gestione, riportando nel file di log la natura dell anomalia (DB non raggiungibile, vista non presente, errore nella struttura della vista, etc.). 7. Lo script termina l esecuzione del client, memorizzando il resoconto dell esecuzione nel file di log all interno della cartella logs. 8. L adapter individua tutte le coppie <Ente, tipologia di servizio> presenti nella tabella di alimentazione; 9. Per ogni coppia <Ente, tipologia di servizio> presente nella tabella di alimentazione, il sistema individua tutte le istanze di servizio dell Ente che rispondono a queste condizioni: (Stato dell istanza di servizio = ATTIVO) AND (Flag inviato=false) AND (popolato=false). 10. Per ogni istanza di servizio popolabile: a. Il sistema recupera le variabili componenti e le ricerca all interno dei dati sorgenti, formando il file XML di popolamento, verificando che la data di riferimento dei valori di popolamento rientri all interno dell intervallo di riferimento della rilevazione (ovvero un valore di popolamento prelevato dalla vista è inserito nel file XML solo se la sua data di riferimento rispetta l intervallo di estensione della campagna di rilevazione). b. Il file XML della rilevazione viene validato con la versione light della struttura XSD di riferimento. c. In caso di validazione avvenuta con successo, sono memorizzati i dati per la rilevazione (popolamento delle tabelle istanza_variabile e variabile_servizio), ponendo a popolato l istanza di servizio. i. Se la struttura dei dati non supera la validazione con la versione light dell XSD, priva dei controlli sulle restrizioni e sull obbligatorietà dei campi, i dati sono scartati senza aggiornare l istanza di servizio. d. Sui soli valori popolati dalla vista, viene impostato con la data dell operazione il campo data_ultima_modifica sulla tabella istanza_variabile delle sole variabili effettivamente popolate (ovvero presenti nel file XML costruito dall adapter). 11. Il sistema memorizza il log dell elaborazione in un apposito file di log. 12. Accedendo all interfaccia web per la gestione della piattaforma, un operatore con accesso alle funzioni di inserimento manuale dei dati quantitativi può procedere con l approvazione (o l eventuale completamento/correzione) dei dati acquisiti automaticamente dalla vista di alimentazione dell Ente Esempi di vista e configurazione del client JMS Seguendo la struttura XSD proposta come esempio nel paragrafo 3.2.5, la vista messa a disposizione dall Ente ENTE-001 dovrebbe essere la seguente: codice_ente codice_servizio codice_iquel_variabile valore_variabile data_riferimento_valori ENTE-0001 SRV-0001 A-UP-BO /12/2008 ENTE-0001 SRV-0001 A-UP-BO /12/2008 Pagina 12

13 ENTE-0001 SRV-0001 A-UP-BO /12/2008 ENTE-0001 SRV-0001 A-UP-CE /12/2008 ENTE-0001 SRV-0001 A-UP-FO /12/2008 I dati della vista sono utilizzati per il popolamento delle rilevazioni inerenti il servizio corrispondente con il codice_servizio indicato nei dati. Per ogni rilevazione popolabile, il sistema recupera le variabili componenti e le ricerca all interno dei dati sorgenti, formando il file XML di popolamento, verificando che la data di riferimento dei valori di popolamento rientri all interno dell intervallo di riferimento della rilevazione (ovvero un valore di popolamento prelevato dalla vista è inserito nel file XML solo se la sua data di riferimento rispetta l intervallo temporale a cui si riferiscono i dati quantitativi raccolti per la rilevazione). Il campo data_riferimento_valori non è quindi riferito al periodo in cui effettivamente sono stati raccolti i dati (e.g. a ottobre 2009) ma alla data a cui effettivamente si riferiscono quei dati (e.g. al numero di chiamate effettivamente ricevute per un certo servizio al 29/12/2008, anche se il dato è stato recuperato ed elaborato nel 2009). Un esempio di file di configurazione clientjms-properties.xml del client JMS è il seguente: <?xml version="1.0"?> <dataproperties> <properties> <jndi-name>jdbc/iquel</jndi-name> <files-sql>/opt/iquel /ClientExportVariabiliJms/properties/</files-sql> <connection-url> jdbc:oracle:thin:@(description=(address_list=(address=(protocol=tcp)(host=xxx.xx x.xxx.xxx)(port=1521))(address=(protocol=tcp)(host=xxx.xxx.xxx.xxx)(port=1521))(load_bal ANCE=no)(FAILOVER=no)) (CONNECT_DATA=(SERVICE_NAME=xxx))) </connection-url> <driver-class>oracle.jdbc.driver.oracledriver</driver-class> <user-name>username_schema</user-name> <password>password_schema</password> <timeout-jms>15000</timeout-jms> <indirizzo-jms> </indirizzo-jms> <port-jms>1099</port-jms> </properties> </dataproperties> Se la struttura della vista è conforme alle specifiche, non è necessaria alcuna personalizzazione del file ExportVariabiliDAO.properties che gestisce l interrogazione della vista se non l indicazione del nome della vista stessa Esempio di struttura dati XSD La struttura XSD, per consentire il popolamento delle strutture dati riferendosi ad oggetti identificabili anche su diversi sistemi, deve far riferimento ai nuovi identificatori univoci introdotti nel sistema. L introduzione dei codici univoci all interno della piattaforma ha un impatto indiretto sulle operazioni di import dei dati quantitativi, sia come progettazione del popolamento automatico sia, come revisione, sulla precedente fase di popolamento manuale tramite import CSV/XML Ipotizzando le definizioni riassunte nella tabella seguente, si mostra un esempio della XSD conseguente. Codice Variabile Tipo Restrizioni A-UP-BO-09 giorni_apertura_bando VariabiliBO >1 A-UP-BO-08 giorni_durata_procedura VariabiliBO >0 Pagina 13

14 A-UP-BO-07 numero_iscrizioni_non_soddisfatte_fine_anno VariabiliBO >0 A-UP-CE-05 numero_accessi_pagine_web VariabiliCanale >0 A-UP-FO-01 numero_sportelli_servizio VariabiliFO >1 Con l introduzione dei codici univoci di identificazione, grazie alla presenza di codici di riferimento univoci, è possibile semplificare la struttura evitando di ripetere nell inserimento tutte quelle che sono informazioni già presenti nella piattaforma, onerose da verificare e validare. La nuova struttura XSD-LIGHT da generare per un istanza di servizio, usata per i controlli di validazione interni alla piattaforma (di tipo lasco, consentendo un popolamento parziale e il mancato rispetto delle restrizioni), riprendendo le variabili d esempio che compongono lo scenario di test, è quindi la seguente: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" targetnamespace=" elementformdefault="qualified"> <xs:complextype name="variabili"> <xs:sequence> <xs:element name="a-up-bo-07" minoccurs="0" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value="0"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-bo-08" minoccurs="0" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value="0"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-bo-09" minoccurs="0" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value="0"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-ce-05" minoccurs="0" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value="0"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-fo-01" minoccurs="0" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value="0"/> </xs:restriction> </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="rilevazionetype"> <xs:sequence> <xs:element name="valori_variabili" type="variabili" maxoccurs="1" minoccurs="1"/> </xs:sequence> Pagina 14

15 <xs:attribute name="cod_ente" fixed="ente-0001" use="required"/> <xs:attribute name="cod_rilevazione" fixed="ists-0001" use="required"/> </xs:complextype> <xs:element name="rilevazione_dati_servizio" type="rilevazionetype" /> </xs:schema> La nuova struttura XSD-RESTRICTED (completa) da generare per un istanza di servizio, resa disponibile per il download all interno della schermata di dettaglio di un istanza di servizio attiva/archiviata, è usata per comunicare esternamente in maniera formale la struttura dati attesa dal sistema. Riprendendo le variabili d esempio che compongono lo scenario di test, è quindi la seguente: <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" targetnamespace=" elementformdefault="qualified"> <xs:complextype name="variabili"> <xs:sequence> <xs:element name="a-up-bo-07" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value=" "/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-bo-08" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value=" "/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-bo-09" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value=" "/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-ce-05" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value=" "/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="a-up-fo-01" minoccurs="1" maxoccurs="1"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:maxinclusive value=" "/> <xs:mininclusive value=" "/> </xs:restriction> </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="rilevazionetype"> <xs:sequence> <xs:element name="valori_variabili" type="variabili" maxoccurs="1" minoccurs="1"/> </xs:sequence> <xs:attribute name="cod_ente" fixed="ente-0001" use="required"/> <xs:attribute name="cod_rilevazione" fixed="ists-0001" use="required"/> Pagina 15

16 </xs:complextype> <xs:element name="rilevazione_dati_servizio" type="rilevazionetype" /> </xs:schema> NOTE SULLA CREAZIONE L elemento principale della struttura è l element Rilevazione_dati_servizio di tipo RilevazioneType, che si compone dell elemento Rilevazione_dati_servizio si compone di due attributi con valore prefissato (codice ente e codice rilevazione, prelevati da DB, che rappresentano il codice dell Ente di riferimento dell istanza di servizio a cui si riferisce il file XSD e il codice IQuEL dell istanza di servizio stessa) e una sequenza di oggetti di tipo Variabile. Il complextype Variabili si compone di una serie di una sequence di elementi di tipo element generati creando un elemento per ogni variabile associata all istanza di servizio, inserendo il codice IQuEL come nome dell elemento. Per supportare anche popolamenti parziali, nella sola versione light, la cardinalità di ogni variabile è posta tra 0 a 1 (minoccurs="0" maxoccurs="1"). Per supportate l acquisizione di dati formalmente validi (come tipo di dato) ma non accettabili (violazione delle restrizioni), la versione light della XSD presenta i soli valori di restrizione dovuti al tipo di dato. Nella versione completa, la cardinalità di ogni variabile è posta a 1 (minoccurs="1" maxoccurs="1") perché la sua presenza è obbligatoria. Le restrizioni sui tipi sono create a partire dalle corrispondenti restrizioni definite per le variabili (invariato rispetto al meccanismo precedente). Nei due casi, l ordinamento degli elementi contenente le variabili all interno della sequenza è per ordine alfabetico sul codice della variabile (ovvero sul nome dell elemento). Nella pagina di dettaglio di una istanza di servizio (GestioneIstanza.action), se l istanza è nello stato attivo o archiviato, deve essere presente un azione che consente il download della XSD di riferimento (quella restricted) per la produzione dei dati di alimentazione. 3.3 Acquisizione dei dati quantitativi tramite Web Service Prerequisiti per gli scenari di test I prerequisiti per la verifica di questa modalità di alimentazione sono i seguenti: Definizione nella piattaforma di un insieme di variabili e di almeno un indicatore; Definizione e attivazione in anagrafe dei servizi di una rilevazione per l Ente, associata ad almeno una variabile e un indicatore, definendo l intervallo temporale del periodo di riferimento dell istanza di servizio (con unico check data fine > data inizio). Predisposizione di un WS client e del key-store per supportare la comunicazione HTTPS del web service (client di esempio fornito da Altran per l esecuzione del caso di test). Predisposizione di una struttura XML compliant con la struttura XSD generata dall anagrafe dei servizi per la rilevazione appena creata (da generare in conformità con quanto definito in anagrafe) Scenari di riferimento La piattaforma espone un web service per l acquisizione dei dati quantitativi per il popolamento di un istanza di servizio. Tale web service, con accesso protetto, deve essere invocato fornendo come parametri di ingresso gli elementi necessari per individuare l istanza di servizio di riferimento, in modo da selezionare il giusto file XSD di validazione. Le credenziali di autenticazione al web service autorizzate sono quelli dei profili di Operatore Data Entry, Amministratore e Super-User. 1. Il redattore dell Ente che intende inviare un file XML di popolamento dei dati verso la piattaforma tramite Web Service avvia il client fornendo i parametri di configurazione richiesti. Pagina 16

17 2. Il web service effettua una validazione preliminare sui parametri di autenticazione e di invocazione dichiarati dal client per l invocazione del servizio: codice_ente e codice_istanza_servizio (che consentono di identificare univocamente una campagna di rilevazione). a. Se le credenziali inserite nella richiesta di autenticazione non corrispondono ad un utenza abilitata all accesso, l invocazione del web service fallisce con un errore di mancata autenticazione. b. Se il parametro d invocazione codice_ente non è presente nella piattaforma (tabella Ente) o se le credenziali inserite nella richiesta di autenticazione consentono l accesso per un Ente diverso da quello dichiarato come parametro di selezione, l invocazione del web service fallisce con un errore che indica una errata selezione dell Ente di riferimento. c. Se il parametro d invocazione al metodo di acquisizione dati codice_istanza_servizio non è correttamente validato, l invocazione del WS fallisce con un errore che indica una errata selezione dell Istanza di servizio. i. Il parametro codice_istanza_servizio deve essere presente nel DB (codice iquel della tabella istanza_servizio); ii. Il parametro codice_istanza_servizio deve essere riferito all Ente identificato dal codice_iquel dell Ente fornito come parametro; d. La coppia di chiavi (codice_ente, codice_istanza_servizio) deve indicare un istanza di servizio nello stato attivo e non popolata. 3. Se ha successo la validazione dei parametri di autenticazione e invocazione (per identificare l istanza da popolare: codice Ente + codice istanza), il sistema elabora il file XML contenente i dati di popolamento per le variabili associate all istanza di servizio dell Ente che si vuole popolare. 4. Il sistema effettua una validazione formale del file XML con il file XSD-LIGHT di riferimento (associato, cioè, all istanza di servizio identificata dai parametri), per garantire la conformità della struttura dati e delle variabili che si intendono popolare con i codici delle variabili della piattaforma associate al servizio. a. Il sistema effettua anche acquisizioni automatiche dei dati di tipo parziale (non tutte le variabili associate al servizio sono presenti nell XML di alimentazione), in quanto nel file XSD ogni variabile ha cardinalità 0-1. b. Indipendentemente dal valore del flag abilitazione_ins_manuale, che determina se il primo popolamento delle variabili DEVE avvenire tramite processi automatici (=false) o può avvenire in entrambe le modalità (flag=true), i dati inseriti devono comunque essere visualizzati e approvati dal redattore prima di essere inviati al processo di aggregazione, pertanto valgono le seguenti considerazioni: 5. Se il file XML fornito è compliant con la definizione XSD-light per l istanza di servizio selezionata, sintatticamente e semanticamente, il sistema memorizza i dati nel DB (memorizzazione delle istanze di variabili) e imposta il flag popolato = true per l istanza di servizio coinvolta nel processo di popolamento. a. Per i dati presenti nel file XML di popolamento, viene impostato con la data dell operazione il campo data_ultima_modifica sulla tabella istanza_variabile. b. Conformemente al processo di validazione dei dati quantitativi, l operatore potrà procedere con l invio dei dati solo quando sono presenti i valori di popolamento per tutte le variabili e sono rispettate tutte le restrizioni sui valori ammissibili. 6. Il Web Service restituisce al client l esito del processo di caricamento. Pagina 17

18 3.3.3 Esempio di file XML inviato tramite WS Il file XML contiene internamente la riproposizione dei codici in grado di identificare univocamente l istanza di servizio oggetto di popolamento, già presenti nell invocazione del web service come parametri esterni al fine di individuare il file XSD di validazione, al fine di garantire l atomicità di interpretazione di un file XML anche al di fuori del Web Service e per compliance con la struttura XSD di validazione di quell istanza. Ogni invocazione del web service è pertanto relativa al popolamento di una sola istanza di servizio (identificata appunto dal codice IQuEL dell Ente e da quello dell istanza). Il file presenta quindi la lista con le variabili richieste dalla struttura XSD corrispondente all istanza di servizio dell Ente. Segue un esempio di XML per il popolamento di 5 variabili dell istanza di servizio ISTS-0001 per l Ente ENTE-0001, conforme alla struttura XSD proposta come esempio nel paragrafo 3.2.5,. Sono evidenziati in grassetto quelli che sono i contenuti informativi della struttura. <?xml version="1.0" encoding="utf-8"?> <Rilevazione_dati_servizio cod_ente="ente-0001" cod_rilevazione="ists-0001" xmlns=" xmlns:xsi=" xsi:schemalocation=" IQuEL_finale.xsd"> <Valori_variabili> <A-UP-BO-07>100</A-UP-BO-07> <A-UP-BO-08>220</A-UP-BO-08> <A-UP-BO-09>140</A-UP-BO-09> <A-UP-CE-05>14002</A-UP-CE-05> <A-UP-FO-01>5</A-UP-FO-01> </Valori_variabili> </Rilevazione_dati_servizio> 3.4 Revisione Inserimento Dati e import CSV/XML Prerequisiti per gli scenari di test I prerequisiti per la verifica di questa modalità di alimentazione sono i seguenti: Definizione nella piattaforma di un insieme di variabili e di almeno un indicatore; Definizione e attivazione in anagrafe dei servizi di una rilevazione per l Ente, associata ad almeno una variabile e un indicatore, definendo l intervallo temporale del periodo di riferimento dell istanza di servizio (con unico check data fine > data inizio). Predisposizione di una struttura XML o CSV compliant con la struttura XSD generata dall anagrafe dei servizi per la rilevazione appena creata (da generare in conformità con quanto definito in anagrafe) Scenari di riferimento 1. Dal menu dinamico, i profili autorizzati hanno accesso alla funzione Dati Quantitativi Gestione Dati Inserimento Dati che effettua la ricerca di tutte le istanze di servizio, di tutti gli Enti per i quali l utente ha diritto di accesso, che rispondono a queste condizioni: o (Stato dell istanza di servizio = ATTIVO) AND o (Flag inviato=false) AND Pagina 18

19 o (supporto_completamento_manuale=true) OR (supporto_completamento_manuale=false AND popolato=true) 2. La tabella con i risultati della ricerca mostra i risultati, in forma tabellare, mettendo nelle colonne la tipologia di servizio, il nome dell istanza di servizio, stato, data di attivazione ed Ente, consentendo l accesso al dettaglio. 3. Accedendo al dettaglio, se l istanza di servizio non è già popolata, è possibile selezionare il file da importare per popolare la tabella. 4. Il sistema elabora il file CSV/XML acquisito, validandolo rispetto alla struttura XSD associata alla rilevazione dell Ente. 5. Sui valori popolati a partire dai dati presenti nel file viene impostato con la data dell operazione il campo data_ultima_modifica sulla tabella istanza_variabile delle sole variabili effettivamente popolate. a. Per quanto riguarda l inserimento dei dati direttamente nella tabella, per il primo inserimento o per le correzioni successive, a ogni salvataggio viene aggiornato con la data l operazione il campo data_ultima_modifica sulla tabella istanza_variabile Esempi di XML/CSV compliant con la struttura XSD Di seguito, si riporta un esempio di valorizzazione tramite file XML, compliant con la XSD generata dalla piattaforma nell Anagrafe dei servizi. Tale XML è del tutto analogo a quello inviato tramite Web Service. <?xml version="1.0" encoding="utf-8"?> <Rilevazione_dati_servizio cod_ente="ente-0001" cod_rilevazione="ists-0001" xmlns=" xmlns:xsi=" xsi:schemalocation=" IQuEL_finale.xsd"> <Valori_variabili> <A-UP-BO-07>100</A-UP-BO-07> <A-UP-BO-08>220</A-UP-BO-08> <A-UP-BO-09>140</A-UP-BO-09> <A-UP-CE-05>14002</A-UP-CE-05> <A-UP-FO-01>5</A-UP-FO-01> </Valori_variabili> </Rilevazione_dati_servizio> Il file CSV contiene, in forma tabellare, le informazioni richieste dalla struttura XSD per valorizzare a chi appartengono i dati (identificativi del servizio, della rilevazione e dell Ente) e sulle variabili da popolare (codice della variabile e valore). Tramite la definizione di identificatori univoci, la nuova struttura CSV da importare diviene: codrilevazione,codente, codvariabile,valore ISTS-0001,ENTE-0001,A-UP-BO-07,100 ISTS-0001,ENTE-0001,A-UP-BO-08,220 ISTS-0001,ENTE-0001,A-UP-BO-09,140 ISTS-0001,ENTE-0001,A-UP-CE-05,14002 ISTS-0001,ENTE-0001,A-UP-FO-01,5 3.5 Attivazione dei processi ETL Dati Quantitativi Prerequisiti per gli scenari di test I prerequisiti per l aggregazione dei dati quantitativi gestiti dalla piattaforma sono i seguenti: Definizione nella piattaforma di un insieme di variabili e di almeno un indicatore; Pagina 19

20 Definizione e attivazione in anagrafe dei servizi di una rilevazione per l Ente, associata ad almeno una variabile e un indicatore, definendo l intervallo temporale del periodo di riferimento dell istanza di servizio (con unico check data fine > data inizio). Inserimento dei dati quantitativi e approvazione dei dati inseriti Scenari di riferimento 1. I moduli della piattaforma non eseguono processi ETL sui dati quantitativi per il popolamento delle tabelle di aggregazione, alla base dei processi di reportistica, ma si limitano a segnalare che i dati sono stati approvati dall Ente e che quindi il processo può partire. a. Un operatore non può archiviare manualmente un istanza di servizio ma si limita ad approvare i dati quantitativi cliccando sul tasto invia e impostando così il flag inviato. Il processo ETL, incluso logicamente nel modulo A3P11, monitora tutte le istanze di servizio che sono (attive & inviate), provvedendo ad aggregare i dati corrispondenti e a modificare lo stato dell istanza di servizio in elaborato al termine del processo. Pagina 20

21 4 Acquisizione manuale dei dati qualitativi tramite import XLS 4.1 Ambito e descrizione sintetica delle funzionalità del modulo Per quanto riguarda la gestione dei dati sui questionari, l alimentazione automatica non supporta il caricamento dei dati nella loro forma elementare (ovvero dove ogni sessione di popolamento del questionario è memorizzato in dettaglio attraverso i dati raccolti nelle tabelle storico_questionario e storico_risposta) ma esclusivamente i dati di riepilogo su consultazioni svolte attraverso altri strumenti rispetto alla piattaforma di monitoraggio (e.g. CATI o questionari cartacei), identificando il questionario tramite i codici identificativi dell Ente e del questionario. Il sistema deve quindi supportare l acquisizione dei dati aggregati, complessivi per un questionario, andando a memorizzare direttamente i valori totali sul popolamento del questionario (ovvero, per ogni risposta a domande/qualificazioni, vanno acquisiti il numero e la percentuale di voti). Il caricamento dei dati sul questionario avviene comunque a livello di piattaforma, dove il questionario per l Ente interessato a caricare i dati acquisiti esternamente deve comunque essere presente. Una volta attivato il questionario, è possibile procedere con l import dei dati (caricati in formato XLS). Il sistema verifica che i dati in ingresso siano compliant con il questionario che si è selezionato per il popolamento e procede con la memorizzazione dei dati nell apposita struttura di aggregazione, estendendo le informazioni da file con quelle già presenti nella piattaforma. Il questionario viene quindi posto nello stato di archiviato. Dopo l elaborazione da parte dei processi ETL, il questionario viene posto nello stato di elaborato, senza dare la possibilità di inserire ulteriori dati di popolamento. 4.2 Import dei dati qualitativi Prerequisiti per gli scenari di test I prerequisiti per l aggregazione dei dati qualitativi gestiti dalla piattaforma sono i seguenti: Definizione nella piattaforma di un questionario; Pubblicazione del questionario; Predisposizione di un file XLS con dei dati di popolamento compliant con il questionario (specifico per un Ente) che si intende popolare Scenari di riferimento 1. A livello di menu dinamico, le funzionalità di acquisizione automatica dei dati qualitativi presenti nella piattaforma sono accessibili dal menu di AGGREGAZIONE DATI. a. Il solo profilo autorizzato ad accedere è quello di tipo Super-User. 2. Accedendo alla funzionalità di Import dati della sezione Dati qualitativi, il sistema mostra una pagina per l upload dei dati aggregati raccolti dagli Enti (e.g. tramite CATI) per una indagine statistica. 3. L invocazione dell azione di import richiede la presentazione di una pagina di ricerca che abilita la possibilità di ricercare un questionario tramite filtri di ricerca: o Possibilità di specificare, anche parzialmente (ricerca %LIKE% case insensitive), il nome del questionario; Pagina 21