Regione Toscana - Giunta Regionale

Transcript

1 Regione Toscana - Giunta Regionale Direzione Generale Organizzazione e Sistema Informativo Area di Coordinamento Reti di Governance del Sistema Regionale e ISIC Settore Infrastrutture e Tecnologie per lo Sviluppo dell Amministrazione Elettronica REALIZZAZIONE DI NUOVI MODULI E MANUTENZIONE DELL APPLICAZIONE PER LA RETE BANCA DATI CULTURA DELLA LEGALITÀ (R.Ed.Le.) PROCEDURA DI AGGIORNAMENTO DELL'APPLICAZIONE Hyperborea S.R.L. Via Giuntini 25 int Navacchio (PI) Tel Fax info@hyperborea.com - P.IVA Studio Associato Blackbit di Ing. G. Santoni e Ing. G. Spinosa V.le Sonnino, 76 - GROSSETO info@blackbit.it - P. IVA

2 dati cultura della legalità (REDLE) Sommario SOMMARIO... 2 INTRODUZIONE... 3 PREREQUISITI... 3 PROCEDURA DI AGGIORNAMENTO... 3 AGGIORNAMENTO DELLO SCHEMA DEL DB... 4 CONFIGURAZIONE DELL'APPLICAZIONE... 4 LANCIO DELL'APPLICAZIONE E FINALIZZAZIONE DELLA MIGRAZIONE... 5 Pag. 2 di 6

3 Introduzione La nuova versione dell'applicazione Redle ha comportato una profonda revisione dello schema del database utilizzato nella versione precedente (attualmente in produzione) - a titolo di esempio una delle modifiche consiste nel trasferimento della gestione di tutti i file allegati alle schede-attività dal database al filesystem. Rivestirà quindi una particolare importanza la corretta esecuzione della procedura di migrazione, connessa all'aggiornamento dello schema del database per la nuova versione dell'applicazione. La procedura di aggiornamento descritta nel presente documento consente di migrare una installazione in ambiente di test o produzione dell'applicazione web REDLE versione 1 alla nuova versione (2.0). Oltre alla sostituzione dell'applicazione web vera e propria, l'aggiornamento comporta, come detto, modifiche allo schema del database e ai dati archiviati su filesystem. Al fine di semplificare tale migrazione, viene di seguito descritta l'intera procedura, unitamente alla descrizione dei tool di supporto forniti al fine di supportarne la corretta e completa esecuzione. Prerequisit 1) L'applicazione REDLE1 dovrà essere correttamente installata e funzionante nell'istanza che si intende aggiornare; 2) è necessario avere accesso al database DB2 a cui è connessa l'applicazione REDLE, con un utente avente almeno i seguenti diritti (sullo schema REDLE): 1. INSERT 2. ALTER TABLE 3. REORG TABLE 4. UPDATE 5. SELECT 6. CREATE TABLE 7. CREATE INDEX 8. DROP TABLE 9. DROP INDEX o, più in generale, un utente avente pieni diritti di modifica strutturale dello schema del DB. 3) è necessario avere accesso all'application server su cui è installata l'istanza dell'applicazione che si intende migrare, con utenza avente diritti di gestione del contesto dell'applicazione e della sua configurazione; 4) l'applicazione dovrà avere accesso in scrittura/lettura su filesystem presso un path che l'amministratore potrà/dovrà configurare; 5) lo spazio su filesystem messo a disposizione dell'applicazione dovrà essere pari o superiore alla stima di ingombro del table-space su cui risiede la tabella materiali Pag. 3 di 6

4 del DB (normalmente TBS_REDLE_N0). Procedura di aggiornamento La procedura di aggiornamento dell'applicazione è articolata in più fasi successive. Aggiornamento dello schema del DB (parte 1 di 2) Per prima cosa è necessario arrestare il contesto dell'istanza che si intende aggiornare, in modo che si possa procedere all'aggiornamento dello schema del database. Allo scopo di semplificare l'aggiornamento dello schema del database, è fornito uno script di migrazione compatibile con IBM DB2. Tale script è disponibile nella posizione: src/main/config/database/sql/migrazione.sql e può essere lanciato utilizzando l'utility a linea di comando DB2 (già connessa al DB dell'applicazione) con: DB2 -tf src/main/config/database/sql/migrazione.sql oppure può essere lanciato tramite un tool di amministrazione di DB2. Configurazione dell'applicazione Si può quindi procedere all'installazione della nuova versione dell'applicazione web, impostando per prima cosa i necessari parametri di configurazione prima di lanciare il relativo contesto di esecuzione sull'application server. Nel file XML di configurazione del contesto, oltre alle normali risorse JDBC e Mail tipiche della maggior parte delle applicazioni JSP/Servlet (la risorsa JNDI per la spedizione della posta si chiama mail/session), dovranno essere definite ulteriori risorse di tipo stringa che servono per fornire all'applicazione le seguenti informazioni: percorso su filesystem dove archiviare gli allegati binari; URL servizio geocode su CART (in conformità all'rfc-59); username accesso servizio geocode CART; password accesso servizio geocode; Di seguito riportiamo un esempio di file configurazione non completo dei dettagli (conf/catalina/localhost/redle.xml relativo a un application server Tomcat): <Context...> <Resource name="jdbc/redle" auth="container" type="javax.sql.datasource" /> <Resource name="mail/session" auth="container" type="javax.mail.session" /> <Environment name="allegati_su_filesystem" value="/tmp" <Environment name="geocode_service_url" value=" <Environment name="geocode_service_username" value="username*" <Environment name="geocode_service_password" value="password*" </Context> Pag. 4 di 6

5 USERNAME e PASSWORD dovranno essere specificate Predisposizione della cornice grafica L'interfaccia web di accesso alla banca dati è progettata per integrarsi armonicamente all'interno del sito web della Regione, nella sezione banche dati. Per questo motivo, in accordo alle specifiche fornite, è prevista la predisposizione e configurazione di una cornice HTML che riproduca la versione attuale della strutturazione dei contenuti e della grafica del sito web della Regione. La cornice è costituita materialmente da 2 file (default_template_pre.html e default_template_post.html) che si trovano nella directory layout dell'applicazione, che possono essere sostituiti con file analoghi, o il cui contenuto può essere liberamente modificato per adeguarsi agli aggiornamenti del portale regionale. Attenzione: le modifiche apportate diverranno effettive solo dopo aver riavviato l'istanza dell'applicazione. Lancio dell'applicazione e finalizzazione della migrazione Quando tutte le risorse dell'applicazione saranno completamente e correttamente configurate, sarà possibile avviarne l'istanza. Durante il primo avvio immediatamente successivo all'aggiornamento dello schema del database, l'applicazione eseguirà una serie di modifiche automatiche ai dati contenuti nel database, in particolare: eseguirà la migrazione degli allegati esistenti, copiandoli dal database al filesystem (riducendo considerevolmente l'ingombro del relativo tablespace); eseguirà controlli di consistenza sul dataset esistente, apportando eventuali modifiche; Per questo motivo è previsto e normale che l'applicazione non risponda immediatamente alle richieste HTTP che gli verranno dirette subito dopo il primo avvio, e che nel frattempo produca una discreta quantità di output nel file di log redle.log. Il tempo richiesto per il completamento del primo avvio è proporzionale alla quantità di allegati presenti nel database di produzione che verranno migrati da esso al filesystem. Quando l'applicazione avrà completato il ciclo di migrazione, potrà iniziare il ciclo di serving delle richieste HTTP e rispondere normalmente alle richieste esterne. Durante il primo avvio, l'applicazione rileverà di dover completare l'adattamento dei dati nei DB, e lancerà automaticamente una procedura interna di completamento della migrazione. Contestualmente, tutti gli allegati binari presenti nel DB in forma di LOB, verranno trasferiti su filesystem, coerentemente al path configurato nel contesto dell'applicazione. Al termine di questa procedura, l'applicazione risulterà complessivamente funzionante, ma sarà necessario lanciare un ultimo script di cleanup (vd. paragrafo successivo) per completare la migrazione del DB, altrimenti alcune delle funzionalità dell'applicazione potranno produrre degli errori di funzionamento. Pag. 5 di 6

6 Aggiornamento dello schema del DB (parte 2 di 2) Quando lo script di cui al punto precedente avrà terminato la sua esecuzione, il database si troverà in uno stato che permetterà l'esecuzione della nuova versione dell'applicazione, ma saranno ancora presenti strutture che raccomandiamo di eliminare lanciando il seguente script che completa il processo di migrazione eliminando tutto quanto non più necessario: DB2 -tf src/main/config/database/sql/migrazione_cleanup.sql Pag. 6 di 6