ACSOR OPEN 9 settembre 2010

Transcript

1 Progetti ELI-CAT / ELI-FIS Gestione digitale integrata dei servizi locali in materia fiscale e e catastale mediante modelli di cooperazione applicativa ACSOR OPEN 9 settembre 2010 Versione 1.0 1

2 Indice ACSOR Open, i capisaldi della soluzione proposta Requisiti e obiettivi Funzionalità Requisiti tecnico/architetturali Confronto tra ACSOR Open ad ACSOR a licenza Funzionalità Requisiti tecnico-architetturali Stato dell arte delle attività di sviluppo ad oggi I prossimi passi 2

3 I requisiti Il Modello di Dominio Elisa (Deliverable DAR 3.1 All. A) Le linee guida per l implementazione specificatamente fissate in sede di Offerta Tecnica Riutilizzare la conoscenza ed esperienza maturata considerando di fatto come requisiti di input al processo di analisi e sviluppo Il modello logico della banca dati definito per ACSOR La definizione ad alto livello delle logiche di processo per le azioni di data cleaning & integration 3

4 I principali obiettivi Avere a disposizione una ACSOR di proprietà pubblica pienamente Elisa compliant (compatibilità a livello DB) Definire un sistema principalmente indirizzato alle realtà degli Enti Locali di dimensione piccola e media Disporre di un sistema che pur implementando tecniche di data cleaning & integration meno sofisticate, risulti comunque efficace, nonché più semplice da gestire e configurare Realizzare una soluzione pienamente open (anche a livello di RDBMS con il supporto per PostgreSQL ed Oracle) 4

5 Funzionalità (1) - ETL Sincronizzazione Acquisizione Normalizzazione Trasformazione (SOR) Compatibilità PostgreSQL - Oracle Nessun utilizzo di codice PLSQL e SQL Loader Tutti i job sono scritti in Java ANSI/SQL (senza impiego di viste materializzate nel caso PostgreSQL) Riconciliazione Soggetti Riconciliazione Oggetti Data Cleaning Riscontro ACS Loading Data Cleaning Riscontro ACO Loading Semplificazione Unica modalità di gestione delle catene di Chronos sia per le fonti operazionali del cosiddetto Modulo Base che del Modulo di Estensione" di ACSOR Algoritmi di normalizzazione semplificati e basati su viari alternativi Semplificazione delle logiche di riscontro anche attraverso l impiego di un data matcher sviluppato ad hoc e completamente open 5

6 Funzionalità (2) Web applications e web services Il Modulo di Estensione di ACSOR viene realizzato mediante riuso di quanto sviluppato nel progetto ELI-CAT Piena compatibilità con la versione a licenza Funzionalità immutate (completa trasparenza dal punto di vista dell utente finale) Switch in configurazione per pilotare Oracle o PostgreSQL Compatibilità supportata da hibernate (90%) e da codice custom (10%) Interfacce WS immutate Un unico codice java che funzioni per ACSOR a licenza e per ACSOR Open 6

7 Funzionalità (3) Nuovi requisiti Integrazione nel contesto della Rete Telematica di RT partecipazione attiva al Sistema degli Archivi Anagrafici Interoperanti sottoscrizione degli eventi pubblicati dalle varie anagrafi comunali che consentirà di innescare un corrispondente evento di richiesta di aggiornamento del sistema satellite Anagrafe Tributaria (nelle more della riattivazione dei servizi SIATEL) 7

8 Aspetti tecnico/architetturali DB Interventi sul database Strutture Tabelle (in Oracle e PostgreSQL) equivalenti Strutture Tabelle conformi al criterio ELISA compliancy Strutture dati interne e di appoggio alle elaborazioni nuove (per motivi prestazionali, in relazione al mancato impiego di codice PLSQL) Limitazioni indotte dall uso di PostgreSQL (viste materializzate e sinonimi assenti, relazione schema-utente non univoca, sequenze gestite in modo differente, data types a volte differenti) Semplificazione tramite riduzione degli schemi (ACSOR ed ACSOR_EXT fusi insieme), riduzione delle tabelle non interessate dalla compliancy ELISA Bilanciamento tra costi di migrazione (ACSOR a licenza <-> ACSOR Open) e semplificazione/prestazioni in ASCOR Open 8

9 Aspetti tecnico/architetturali interfacciamento ACI Il deploy su RDBMS PostgreSQL non consentirà l attivazione delle viste di compatibilità ACI a livello di RDBMS infatti l Anagrafe Comunale degli Immobili, allo stato dell arte attuale, come noto ha Oracle come requisito In questo contesto l unico interfacciamento possibile tra ACSOR e ACI sarà attraverso l interscambio di flussi informativi via Orchestratore Locale (con piena ridondanza delle informazioni così condivise) facility che al momento non è prevista nel prodotto ACI già realizzato nel progetto ELI-CAT 9

10 ACSOR Open versus ACSOR a licenza Processi ETL Web application e web services Funzionalità Database Esclusivamente Oracle ACSOR a licenza Acquisizione flussi tramite files, interfacciamento anche tramite viste materializzate Modulo Base e modulo esteso sono dotati di catene di acquisizione molto differenti (uso dei servizi di certificazione massiva) I Processi di data cleaninig ed integrazione sono molto sofisticati La tecnologia di accesso e gestione dati adopera soluzioni native Oracle (PLSQL, SqlLoader) particolarmente performanti su database medio grandi Nessuna differenza dal punto di vista dell utente con la versione Open Nessuna differenza nella integrazione delle applicazioni tramite WS Acquisizione flussi tramite files, viste materializzate solo nel caso in cui il database sia Oracle Unica modalità di gestione delle catene di acquisizione (modulo esteso trattato analogamente al modulo base) I processi di data cleaning ed integrazione sono più semplici Tutti i job di elaborazione lavorano in java per consentirne la portabilità, le prestazioni peggiorano rispetto ad ACSOR a licenza Nessuna differenza dal punto di vista dell utente con la versione a licenza Nessuna differenza nella integrazione delle applicazioni tramite WS Una funzionalità in più (integrazione con il Sistema degli Archivi Anagrafici Interoperanti di RT) Oracle e PostgreSQL ACSOR Open Limitazioni nel caso PostgreSQL (no viste materializzate) 10

11 Stato dell arte delle attività di sviluppo Database Ristrutturazione del DB (sia Oracle che PostgreSQL) limitata ad entità non coinvolte nel modello di compliancy ELISA Fusione schemi ACSOR e ACSOR_EXT Struttura DB modellata anche in PostgreSQL Migrazione del DB di FDV in PostgreSQL Web Applications e Web Services Porting completo su PostgreSQL Test effettuati sul DB di FDV in PostgreSQL Test di regressione sul DB di FDV in Oracle Processi ETL Sviluppo servizi di normalizzazione dei comuni e degli indirizzi (basati sul concetto di viario alternativo) Sviluppo dei servizi di integrazione dei soggetti (implementati secondo logiche semplificate e attraverso l uso di un data matcher sviluppato ad hoc e completamente open ) 11

12 I prossimi passi Al fine di minimizzare i ritardi in termini di realizzazione della soluzione, è fondamentale proseguire comunque nelle attività di sviluppo in relazione a quelle funzioni che possano essere date per assodate dalla lettura dell Offerta Tecnica Organizzare incontri specifici presso il laboratorio Engineering per visionare in modo pratico l esecuzione dei processi ETL dell attuale versione a licenza Valutazione dei requisiti funzionali da approfondire ulteriormente con il Comitato Tematico, quali l eventuale revisione dei flussi di caricamento del satellite tributi strumenti di diagnostica dei dati forniti in input a supporto delle attività di certificazione preliminare dei flussi in ingresso da parte di un Ente certificatore indipendente Altre funzionalità chiave individuate dal Comitato Tematico Redazione dei documenti di Requisiti Utente e di Analisi Interfaccia Utente Redazione del documento di Analisi Funzionale Redazione del documento di Analisi Tecnica Redazione del documento Piano dei Test Sviluppo e consegna della manualistica Alfa e beta test Collaudo finale con i DAR 12