PREINFORMATIVA PER L’AFFIDAMENTO DI SERVIZI APPLICATIVI DI SVILUPPO, MANUTENZIONE E GESTIONE DEL SISTEMA NOIPA

Scopo del documento è fornire una descrizione delle varie componenti del sistema NoiPA, esplicitandone le relative caratteristiche funzionali e tecniche nonché del nuovo sistema NoiPA Cloudify attualmente in corso di realizzazione. Il documento verrà consegnato aggiornato alla stipula del contratto.

2. DESCRIZIONE FUNZIONALE DELLE COMPONENTI DEL SISTEMA (NOIPA LEGACY)

Di seguito vengono descritte le applicazioni beneficiarie dei servizi oggetto della fornitura, esplicitandone le relative caratteristiche funzionali e tecniche.

In particolare le componenti applicative che vengono di seguito illustrate sono:

• NoiPA-Gestione anagrafica;

• NoiPA-Gestione stipendi;

• NoiPA-Gestione accessorie;

• NoiPA-Gestione presenze;

• NoiPA-Sanità;

• Pensioni di guerra.

I servizi sopra elencati sono fruibili tramite il Portale NoiPA.

2.1 NoiPA-Portale

Il Portale NoiPA (xxxxx://xxxxx.xxx.xxx.xx) è il sito pubblico che rappresenta il punto unico di accesso alle applicazioni beneficiarie dei servizi oggetto della fornitura.

Il Portale, fruibile h24, è organizzato in un’area di front-end pubblica (disponibile, oltre che nella versione in lingua italiana, anche in lingua tedesca ed inglese) e in un’area privata (o riservata), accessibile previa autenticazione.

2.1.1 L’area pubblica

L’area pubblica del Portale rende disponibili informazioni di carattere generale e normativo e comunicazioni per tutti gli utenti.

Figura 1 – La homepage pubblica del portale NoiPA

La struttura dell’home page pubblica è stata progettata per agevolare gli utenti nel loro percorso verso le informazioni di interesse.

Attraverso la home, oltre ad accedere alle notizie in evidenza ed ai contenuti multimediali resi disponibili, è possibile accedere ai menù corrispondenti alle aree tematiche ed informative relative a:

• servizi offerti dal sistema NoiPA (stipendiali, giuridici e presenze, gestione del capitale umano, servizi aggiuntivi)

• dati che rappresentano il sistema NoiPA (informazioni e numeri sul mondo NoiPA, dati relativi alla spesa per il pagamento degli stipendi , open data, ossia dati resi pubblici e disponibili per la conoscenza, condivisione ed eventuale utilizzo)

• informazioni su progetti, tecnologie e metodologie utilizzate nel percorso di innovazione del sistema NoiPa

• mondo NoiPA:

o le amministrazioni che ad oggi hanno aderito a NoIPA;

o il personale che lavora presso le amministrazioni gestite;

o gli enti privati e i partner istituzionali che collaborano e interagiscono in varia misura con il sistema NoiPA (informazioni sulla rete di relazioni che NoiPA ha costruito nel tempo, in particolare con Banca d’Italia sul processo dei pagamenti telematici, nonché informazioni sui servizi a favore degli enti creditori, destinatari delle ritenute effettuate per loro conto sulle competenze fisse mensili, e a favore dei CAF e professionisti abilitati, per quanto riguarda l’assistenza fiscale indiretta);

o normativa di riferimento;

o i servizi offerti in modalità self service agli Amministrati degli Enti aderenti;

o supporto: FAQ e strumenti per formulare richieste di assistenza..

2.1.2 L’area privata

L’area privata, accessibile solo previa autenticazione, consente ad ogni singolo amministrato di consultare, stampare e richiedere l’export dei documenti di propria competenza (Cedolini e CU) e di accedere ai servizi self service disponibili, sia legati alla componente stipendiale sia alla componente di rilevazione presenze, nel caso di dipendenti di Enti che abbiano aderito alla soluzione avanzata (Gestione trattamento economico e Gestione presenze).

In caso di autenticazione di operatori delle Amministrazioni aderenti abilitati all’accesso ai sistemi gestionali (NoiPA-Gestione anagrafica, NoiPA-Gestione stipendio, NoiPA-Gestione presenze, NoiPA-Sanità), a seconda della profilazione associata all’operatore stesso, la home page privata espone, nell’area Strumenti di

lavoro, altre sezioni che consentono di accedere alle varie funzionalità utili per la propria attività lavorativa.

Figura 2 – La homepage privata del portale NoiPA “Amministrato”

Nell’area Personale della parte privata, sono resi disponibili, a beneficio degli Amministrati, i seguenti documenti:

• Cedolino;

• CU;

• Dati riepilogativi pagamenti dell’anno in corso

Particolari misure di sicurezza adottate dal sistema garantiscono la provenienza e l’inalterabilità del cedolino dematerializzato del dipendente; ogni cedolino è caratterizzato dalla presenza del Codice Grafico bidimensionale.

I modelli stipendiali elettronici interrogabili tramite portale sono elaborati con periodicità prestabilita in formato PDF mediante un flusso informatico che vede un trasporto securizzato di tipo SFTP.

Nell’area I miei dati, sono indicate le informazioni relative ai rapporti di lavoro inerenti l’amministrato.

Self service

Nella pagina privata dell’Amministrato sono anche contenute, alla voce Servizi, le funzionalità on-line rese disponibili in modalità self-service a tutti gli amministrati , che possono usufruirne in qualsiasi momento. I self-service attualmente disponibili,

organizzati per area tematica (anagrafici, stipendiali, prestiti e convenzioni, previdenza, presenze) sono i seguenti:

• Detrazioni per familiari a carico, il servizio per le richieste di detrazione per i familiari a carico ma anche per visualizzare l'elenco delle richieste che l'amministrato ha fatto nel corso degli anni;

• Residenza fiscale e/o domicilio, il servizio per richiedere la variazione della residenza e/o del proprio domicilio fiscale;

• Modalità di riscossione, il servizio per variare i dati relativi alle modalità di riscossione dello stipendio;

• Piccolo Prestito, il servizio per la richiesta di erogazione di Piccolo Prestito all'INPS

- gestione ex INPDAP con accredito dell'importo sul proprio conto corrente, con la conseguente applicazione della trattenuta sul cedolino di stipendio;

• Previdenza Complementare, il servizio utile per l'adesione o modifica di adesione ai fondi di previdenza complementare (Espero, Perseo Sirio) relativi al comparto di appartenenza ma anche per prendere visione delle regole di adesione e di tutta la documentazione relativa ai fondi;

• Bonus IRPEF, il servizio che consente di rinunciare per l' anno in corso al bonus previsto dall'art. 1 del D.L. 66 del 24 aprile 2014;

• NoiPAssicura, il servizio, in fase sperimentale, per l’attivazione della ritenuta mensile per il pagamento della polizza annuale per RCAuto;

• Fondo Espero – comunicazione periodica, il servizio, a disposizione del solo personale del comparto scuola, che consente di accedere all’area privata del Fondo per consultare informazioni annuali sulla propria posizione;

• Presenze/assenze, i servizi per effettuare le operazioni di controllo e gestione delle presenze in servizio, come la domanda di ferie, comunicazioni relative alle timbrature giornaliere, visualizzazione cartellino mensile, ecc.

Per usufruire dei self-service per la gestione stipendiale è necessario utilizzare il codice PIN generato e associato automaticamente dal sistema NoiPA all'identità digitale dell’amministrato.

Funzionalità per gli operatori del sistema

In caso di autenticazione di operatori abilitati all’accesso ai sistemi gestionali (NoiPA- Gestione anagrafica, NoiPA-Gestione stipendio, NoiPA-Gestione presenze, NoiPA- Sanità), a seconda della profilazione associata all’operatore stesso, la home page privata espone, nell’area Strumenti di lavoro, altre sezioni che consentono di accedere alle varie funzionalità utili per la propria attività lavorativa, raggruppate nelle seguenti macroaree:

• Gestione da cui sono accessibili gli applicativi di cui si forniscono i dettagli nei paragrafi successivi;

• Reportistica che consente la consultazione dei dati riepilogativi a supporto del pagamento/verifica delle retribuzioni mensili;

• Amministrazione che contiene servizi a supporto della gestione e della redazione da parte degli amministratori del sistema;

• Assistenza che contiene strumenti a supporto del servizio di assistenza.

Figura 3 – Esempio di homepage privata del portale NoiPA “Operatore”

Nella home dell’operatore, inoltre, sono presenti due sezioni informative:

• Area Messaggi, che mostra l’elenco dei messaggi pubblicati, visibili sulla base della propria profilazione, suddivisi per tipologia (Notifiche amministrato, Avvisi urgenti, Messaggi operatore, Messaggi in evidenza, Adesione enti);

• Agenda, che evidenzia le scadenze correlate alla emissioni mensili, suddivise per tipologia di emissione (emissione ordinaria, emissione urgente, emissione speciale) e alle attività degli operatori del modulo Gestione Sanità.

2.2 NoiPA-Gestione Anagrafica

Il modulo NoiPA Gestione Anagrafica rappresenta la componente applicativa che accoglie tutti i dati anagrafici d’interesse del personale delle PP.AA. gestite. Inoltre, costituisce la fonte alimentante degli altri moduli, Gestione stipendio, Gestione presenze e Gestione del personale del comparto Sanità.

In particolare la Gestione Anagrafica comprende tutte le informazioni e le funzionalità che riguardano i processi anagrafici di ogni dipendente amministrato e delle entità ad esso correlate quali, ad esempio, l’ente di appartenenza, la sede di servizio e l’inquadramento.

Nei paragrafi successivi si riporta una breve descrizione delle aree tematiche di Gestione Anagrafica.

2.2.1 Gestione amministrati

Le funzioni presenti in ambito questa area tematica consentono la visualizzazione e aggiornamento dei dati anagrafici dell’amministrato e l’immatricolazione di un nuovo amministrato.

Tale aggiornamento consente di inserire i dati della scheda anagrafica del dipendente, comprensiva dei dati desumibili dal codice fiscale e di altre informazioni, quali ad esempio l’indirizzo di posta elettronica, la cittadinanza, lo stato civile, le decorrenze, giuridica ed economica, di prima nomina nella P.A., nonché le informazioni di residenza e domicilio. In fase di immatricolazione viene generato e inviato all’indirizzo di posta elettronica associato all’amministrato, in automatico, il PIN, utile per usufruire dei self-service stipendiali disponibili sul portale NoiPA.

Si precisa che è garantito il controllo del codice fiscale, grazie ad un protocollo di colloquio con l'Agenzia delle Entrate che fornisce un servizio di allineamento dei dati relativi all'anagrafica del dipendente con l'Anagrafica Tributaria.

Le informazioni inserite in fase di immatricolazione, con specifiche funzionalità e tramite specifico ruolo, se necessario, possono essere aggiornate in momenti successivi all’immatricolazione.

2.2.2 Gestione rapporti di lavoro

Le funzioni disponibili in questa area tematica permettono di visualizzare e di gestire i rapporti di lavoro dell’amministrato, chiusi o attualmente vigenti.

Le principali informazioni gestite relative ai rapporti di lavoro sono raggruppate nelle seguenti sezioni:

• Rapporto di lavoro, in cui vengono raccolte le informazioni sullo stato e sulla tipologia di rapporto di lavoro, quali ad esempio data assunzione, motivo assunzione, data di fine servizio, tipo attività;

• Inquadramento giuridico, in cui vengono trattate le informazioni giuridiche di inquadramento del singolo rapporto di lavoro, quali ad esempio decorrenza, scadenza, comparto, contratto, qualifica contrattuale;

• Inquadramento economico, in cui vengono censite le informazioni economiche di inquadramento del singolo rapporto di lavoro, quali ad esempio decorrenza economica, scadenza economica, qualifica contrattuale, livello, classi e scatti, laddove contrattualmente previsti;

• Unità organizzativa, in cui vengono tracciate, per ogni rapporto di lavoro, le informazioni legate all’assegnazione principale del dipendente ad uno specifico ufficio/sede di lavoro dell’Ente presso cui presta l’attività lavorativa.

Anche in questi casi sono messe a disposizione degli operatori specifiche funzionalità per l’aggiornamento successivo dei dati registrati nel sistema resi necessari da provvedimenti successivi (ad esempio trasferimento di ufficio o di Ente).

2.2.3 Attivazione pagamenti

Questa area tematica consente di attivare, sulla componente NoiPA-Gestione stipendio, il pagamento delle competenze stipendiali, fisse e/o accessorie, in relazione ad uno specifico rapporto di lavoro.

In particolare, in questa fase l’operatore deve specificare informazioni aggiuntive quali, ad esempio:

• tipologia di attivazione - competenze fisse ed accessorie o solo competenze accessorie;

• cassa previdenziale e relativo trattamento pensionistico;

• aliquote fiscali media e massima;

• assegni spettanti previsti per il contratto/rapporto di lavoro;

• modalità di pagamento.

2.2.4 Gestione familiari

Nelle varie fasi di gestione di un singolo amministrato, sia nella prima immatricolazione sia in fase di variazioni successive, è possibile censire i dati anagrafici dei familiari del dipendente stesso.

Tali informazioni si rendono necessarie per il corretto trattamento di tutte quelle informazioni di carattere economico o di rilevazione presenze strettamente correlate ai familiari (detrazioni, spettanze per L.104, ecc.).

2.3 NoiPA-Gestione Stipendi

Questa componente di NoiPA è destinata alla gestione di tutti gli aspetti che caratterizzano il trattamento economico spettante ai dipendenti della P.A. e all’attuazione degli adempimenti, fiscali e previdenziali, correlati alle emissioni stipendiali effettuate.

In questo ambito si individuano le seguenti macro funzionalità

1. Variazioni dati economici

2. Calcolo e pubblicazione del cedolino e liquidazione competenze

3. Versamenti ritenute

4. Adempimenti previdenziali

5. Gestione dati fiscali e produzione del modello CU

6. Flussi istituzionali

7. Gestione funzionalità per specifiche categorie di personale (personale supplente della scuola e dipendenti del Ministero Affari Esteri)

8. Gestione tabelle applicative

2.3.1 Variazione dati economici

Le funzioni relative alle variazioni dei dati economici sono rivolte principalmente alla gestione delle informazioni legate al singolo dipendente. Le principali attività effettuate dagli operatori, con specifiche abilitazioni, sono:

• ricostruzioni di carriera, aggiornamenti del trattamento economico a fronte di una rideterminazione dell’evoluzione giuridica della carriera del dipendente;

• gestione carichi familiari, trattamento delle informazioni relative alla composizione del nucleo familiare ed al reddito complessivo finalizzate alla determinazione dell’assegno al nucleo spettante;

• applicazione delle riduzioni del trattamento economico derivanti, ad esempio, da periodi di assenza;

• gestione dell’orario di lavoro, trattamento dei rapporti di lavoro part-time o degli orari ridotti, specifici del personale del comparto Scuola; ai fini della liquidazione mensile del cedolino, tutte le competenze spettanti al personale interessato vengono determinate dinamicamente sulla base degli importi spettanti, decurtati della riduzione commisurata alla percentuale di tempo parziale o di orario ridotto;

• gestione dati fiscali e contributivi, insieme delle funzionalità disponibili per l’acquisizione dei flussi relativi a pagamenti fondamentali e pagamenti accessori, necessari per un corretto calcolo dello stipendio mensile e del conguaglio fiscale e contributivo di fine anno

• gestione fondi pensionistici integrativi, funzionalità per la gestione delle trattenute per i fondi pensionistici integrativi (FIP)

• gestione ritenute extra-erariali, funzioni insieme delle funzionalità che consentono la consultazione e l’aggiornamento dei dati relativi alle ritenute extraerariali,

trattenute sulle retribuzioni del personale e agli enti creditori ai quali vengono versate dette ritenute extra-erariali

• gestione dello stato delle posizioni stipendiali, ovvero funzionalità da utilizzarsi per variare lo stato delle posizioni stipendiali dei dipendenti in caso di trasferimenti ad altre amministrazioni, riattivazione di iscrizioni cessate, ecc..

Per semplificare le modalità operative dei singoli enti, soprattutto in relazione alle lavorazioni di aggiornamento che riguardano un numero significativo di nominativi, il sistema NoiPA consente di effettuare aggiornamenti massivi tramite l’invio di flussi di dati, rispondenti ai tracciati predefiniti, scaricabili dal portale NoiPA. Tale modalità di aggiornamento è destinata a una sempre maggiore diffusione anche in relazione agli ingressi delle Forze di Polizia e delle Forze Armate, con soluzione organizzative fortemente centralizzate.

Ad oggi, i principali aggiornamenti comunicabili in modalità massiva sono:

1. attivazione nuovo personale;

2. imponibile tassazione buoni pasto;

3. riduzioni del trattamento economico derivanti da assenze;

4. arretrati a credito/a debito una tantum;

5. variazione inquadramenti e assegni;

6. ritenute extra-erariali e enti creditori locali.

Il monitoraggio di tali lavorazioni avviene tramite le funzionalità di un “cruscotto” appositamente realizzato e disponibile all’interno della componente Gestione Stipendi.

2.3.2 Calcolo e pubblicazione del cedolino e liquidazione competenze

Questa sezione raccoglie le attività di calcolo degli emolumenti mensili spettanti al personale dipendente delle PP.AA. aderenti al servizio NoiPA, attraverso l’elaborazione delle informazioni delle competenze, fisse e accessorie, contenute nel sistema.

Si ricorda che, in applicazione dell’art. 2, comma 197 della Legge n. 191 del 23 dicembre 2009, le competenze nette mensili, spettanti ai dipendenti della PAC, possono essere liquidate tramite un unico cedolino, comprensivo delle competenze di natura sia fissa che accessoria, con emissione, quindi, di un unico titolo di pagamento.

Le risultanze delle elaborazioni di questa area tematica sono: i cedolini stipendiali, fruibili direttamente dal singolo amministrato nell’area privata del portale NoiPA, e i flussi necessari per l’effettiva liquidazione delle competenze mensili determinate. Per gli operatori degli uffici responsabili del trattamento economico dei vari enti, i cedolini sono fruibili dallo strumento Modelli, di seguito descritto.

Nel contesto NoiPA vengono distinte due differenti tipologie di trattamento della liquidazione delle competenze, legate alla natura dell’ente di cui si effettuano i pagamenti:

1. Enti con pagamento telematico (Enti in bilancio): in questo caso il sistema NoiPA trasmette per via telematica i titoli di pagamento alla Banca d’Italia. Un puntuale meccanismo di rendicontazione, posto in essere con l’ausilio della Banca d’Italia, consente di evidenziare in tempo reale gli eventuali storni di pagamento (mancato accredito) e di pubblicare su una apposita area internet i dati riepilogativi. I flussi telematici prodotti rispettano le regole definite nel protocollo d’intesa tra Ministero dell’Economia e delle Finanze e Banca d’Italia, al fine di garantirne l’autenticità, l’integrità e la correttezza formale dei flussi dei pagamenti prodotti;

2. Enti che provvedono direttamente al pagamento degli stipendi del proprio personale (Enti fuori bilancio): il sistema NoiPA mette a disposizione di queste Amministrazioni le disposizioni di pagamento per i propri dipendenti, raccolte in un flusso avente il formato standard CBI (Corporate Banking Interbancario). Questa tipologia di flusso, integrata con una serie di dati specifici della banca tesoriera selezionata, consente all’ente di canalizzare autonomamente i pagamenti per il bonifico. In particolare, i flussi CBI vengono depositati nelle cartelle FTP concordate con l’Amministrazione destinataria.

2.3.3 Versamenti ritenute

Anche per il versamento delle ritenute mensili (fiscali, previdenziali ed extraerariali) determinate a valle delle elaborazioni stipendiali, come per il pagamento dello stipendio agli amministrati, il sistema NoiPA distingue tra enti Enti con pagamento telematico ed Enti che provvedono direttamente al pagamento degli stipendi del proprio personale.

Per un riscontro dei versamenti effettuati delle ritenute extraerariali applicate, il sistema produce specifici elenchi, messi a disposizione di ciascuna organizzazione nell’area servizi del sito a cui si accede tramite autenticazione con codice utente e password.

Questi elenchi riportano, per ciascun dipendente per il quale si è provveduto alla trattenuta mensile, l’importo della quota versata, eventuali rimborsi effettuati e altre informazioni contenute nel tracciato standard definito.

2.3.4 Adempimenti previdenziali

Il sistema NoiPA gestisce la previdenza ordinaria e la previdenza complementare. Vengono predisposti e trasmessi i flussi mensili previsti dalle seguenti casse previdenziali e assistenziali gestite:

• Cassa Previdenziale INPS, con la predisposizione e trasmissione dei tre seguenti flussi:

- Flusso UNIemens/ListaPosPA, per i contributi dei dipendenti pubblici (ex- INPDAP)

- Flusso UNIemens/PosContributiva, per la gestione dei dipendenti con fondo pensione privato

- Flusso UNIemens/ListaCollaboratori, per la gestione separata;

• ’Istituto Nazionale Di Previdenza Dei Giornalisti Italiani, con la predisposizione e trasmissione del flusso INPGI;

• Cassa Autonoma Di Assistenza Integrativa Dei Giornalisti Italiani, con la predisposizione e trasmissione del flusso Casagit.

Riguardo la previdenza complementare, il sistema NoiPA gestisce la contribuzione mensile a carico del lavoratore e del datore di lavoro fornendo i rendiconti relativi ai singoli Fondi gestiti sia ai Fondi stessi che alle Amministrazioni. E’ inoltre disponibile per i Fondi un’apposita funzionalità che consente l’approvazione/rifiuto della richiesta di adesione effettuata dall’amministrato tramite self-service.

2.3.5 Gestione dati fiscali e produzione del modello CU

Gli adempimenti di legge inclusi in questa area tematica sono:

1. trattamento mensile fiscale del dipendente (detrazioni fiscali e addizionali, IRPEF, IRAP)

2. elaborazione e liquidazione del conguaglio fiscale per i redditi da lavoro dipendente;

3. compilazione e rilascio del modello CU;

4. gestione dell’assistenza fiscale indiretta, con l’acquisizione dei 730/4 da CAF e da altri intermediari;

5. produzione della dichiarazione IRAP per l’Agenzia delle Entrate per la PAC nel bilancio dello Stato, e supporto alla predisposizione della stessa dichiarazione per gli enti fuori bilancio;

6. predisposizione F24EP per gli enti fuori bilancio.

il sistema NoiPa, nel rispetto dei termini di legge previsti, provvede ad elaborare i modelli di certificazione previsti, curando il tempestivo aggiornamento delle procedure preposte in relazione alle novità legislative che di anno in anno vengono introdotte.

In particolare, l’elaborazione dei modelli CU viene eseguita a valle delle operazioni di calcolo del conguaglio fiscale. Il documento compilato prodotto è consultabile per ciascun amministrato nell’area privata del portale NoiPA; per gli operatori degli uffici responsabili del trattamento economico dei vari enti, il documento è fruibile dallo strumento Modelli, di seguito descritto.

2.3.6 Flussi istituzionali

Nell’ambito delle funzionalità di supporto messe a disposizione dal sistema NoiPA sono presenti alcuni flussi telematici destinati all’alimentazione di sistemi informativi esterni, del MEF stesso o di altri Enti.

Si riportano esempi di protocolli di colloquio definiti, attualmente in essere

• Flusso per l’Ispettorato Generale per gli ordinamenti del personale e l’analisi dei costi del lavoro pubblico

L’IGOP della Ragioneria Generale dello Stato cura l’acquisizione di tutte le informazioni delle PP.AA. necessarie per l’alimentazione del SiCo, sistema conoscitivo del personale dipendente delle Amministrazioni Pubbliche.

NoiPA si pone come il partner principale sia nella fase di alimentazione del SiCo, sia nella fase di esposizione e verifica dei dati. La procedura realizzata è finalizzata alla predisposizione mensile dei flussi per l’alimentazione della banca dati del personale a partire dalle informazioni giuridiche ed economiche del personale della Pubblica Amministrazione, registrate sulla base informativa NoiPA.

La consegna dei flussi alla RGS avviene tramite il canale FTP.

I dati forniti mensilmente a SiCo vengono anche elaborati per ogni ente gestito in NoiPA e depositati in specifiche cartelle.

• Flusso per il Controllo di Gestione

La procedura in essere è finalizzata alla creazione mensile di un flusso per l’alimentazione dei sistemi automatizzati per il Controllo di Gestione (CdG).

La prima amministrazione utilizzatrice di tale flusso è proprio il MEF; in maniera congiunta è stato definito un protocollo di scambio nel quale sono riportate tutte le specifiche e le tipologie dei dati, i tracciati di tutte le tipologie di flusso che vengono consegnati e le modalità con cui avviene la consegna.

Tramite la stipula di un protocollo d’intesa, che disciplina gli aspetti operativi e tecnici relativi alla fornitura dei dati, anche altre Amministrazioni hanno aderito allo stesso servizio.

2.3.7 Gestione funzionalità per specifiche categorie di personale Tra le diverse tipologie di personale amministrato nell’ambito NoiPA è preponderante la gestione dei contratti del personale della scuola.

La modalità di colloquio con il MIUR per l’acquisizione delle informazioni necessarie per la liquidazione delle competenze spettanti a tali casistiche di personale, è stata oggetto di recente rivisitazione.

Sono, infatti, stati implementati nuovi servizi, in cooperazione applicativa tra il sistema SIDI del MIUR e NoiPA, per l’acquisizione, dei contratti delle supplenze brevi, delle supplenze per maternità e degli incarichi di religione. Sono in corso le attività di estensione di tale modalità di colloquio a tutte le varie fattispecie contrattuali del personale della scuola, attualmente gestiti con flussi quindicinali depositati su cartelle FTP.

Per il monitoraggio delle lavorazioni attinenti tali casistiche di personale è stata messa, sul Portale NoiPA, a disposizione degli operatori coinvolti nel processo la nuova area di consultazione Monitoraggio Scuola .

Anche nella componente Gesione stipendio sono presenti funzioni specifiche per la gestione dei contratti del personale della scuola.

Inoltre, sempre nella componente Gestione stipendio, sono presenti funzioni volte alla gestione di trattamenti peculiari legati al personale del Ministero degli Affari Esteri.

2.3.8 Gestione tabelle applicative

Il sistema NoiPA, comprende anche un insieme di tabelle definite come “applicative”. Si tratta di tabelle di servizio contenenti i parametri di sistema, le decodifiche generali, gli importi tabellari, ecc..

Alcune di queste anagrafiche sono funzionalmente condivise ed utilizzate da più componenti applicative del sistema NoiPA (Gestione anagrafica, Gestione stipendio e Gestione presenze). Al momento non esistono automatismi per l’allineamento di tali informazioni, ma gli aggiornamenti vengono gestiti tramite un processo amministrativo ben definito.

Le tabelle di sistema che ricadono in questo ambito soddisfano due requisiti principali:

• non contengono dati inerenti i dipendenti gestiti dal sistema;

• non possono essere aggiornate dagli uffici responsabili del trattamento economico attraverso funzionalità on-line.

2.3.9 Altre funzionalità del sistema

Nell’ambito del perimetro funzionale NoiPA-Gestione stipendio vengono considerati anche altri moduli applicativi logicamente attinenti alle competenze liquidate ma attualmente realizzati come moduli funzionali a se stanti

• Modelli

• SciopNet e AssenzeNet

• GiudiciNet

• CreditoNet

2.3.10 Modelli

Il modulo applicativo Modelli consente agli Uffici Responsabili del trattamento economico, periferici e centrali nonché agli Uffici di Servizio, di visualizzare, stampare ed archiviare alcuni documenti stipendiali relativi ai dipendenti pubblici amministrati nel sistema NoiPA. I documenti contabili e fiscali disponibili sono: i cedolini stipendiali e i modelli CU.

La provenienza e l’inalterabilità dei documenti scaricati accedendo al servizio Modelli è garantita dalla presenza del Codice Grafico Bidimensionale.

2.3.11 SciopNet e AssenzeNet

Si tratta di applicazioni dedicate agli uffici di servizio, che consentono l’inserimento e la consultazione delle assenze per sciopero o per alcune assenze per malattia del personale di propria competenza, ai fini delle decurtazioni dallo stipendio.

Dal punto di vista applicativo una delle facilities maggiori per l’utenza è quella di avere applicato un filtro in base al quale ciascun ufficio o plesso scolastico ha immediatamente la visione di tutto il personale presente nel proprio organico, senza doverlo selezionare puntualmente.

2.3.12 GiudiciNet

Il servizio permette agli uffici di servizio del Ministero della Giustizia di comunicare, ai fini del pagamento, le competenze economiche mensili spettanti ad alcune categorie di magistrati (Giudici di Pace, Giudici Onorari di Tribunale, Vice Procuratori Onorari e Giudici Onorari Aggregati) .

Ha le stesse caratteristiche applicative di SciopNet e AssenzeNet.

2.3.13 CreditoNet

CreditoNet è un servizio a favore dei dipendenti pubblici, amministrati dal sistema NoiPA, che consente di ottenere, in tempi più rapidi e con procedure semplici, l’erogazione di prestiti da parte di Istituti di credito e Finanziarie.

Tale servizio consente di gestire il processo generale di cessione del quinto dello stipendio, dalla fase di richiesta delle informazioni, alla prenotazione del prestito, fino alla registrazione della ritenuta mensile da applicare al dipendente.

In particolare, il funzionamento del servizio prevede che le banche e le finanziarie si connettano, tramite servizi residenti sui propri sistemi, per visualizzare e stampare tutte le informazioni necessarie per la concessione del credito, in sostituzione della certificazione cartacea precedentemente prodotta.

Per realizzare ciò, si è adottato il modello della cooperazione applicativa tramite web services; l’adozione di questo modello ha consentito di connettere il sistema della banca/finanziaria che usufruisce del servizio a quello del MEF in modalità sicura e autenticata, demandando al singolo ente l’identificazione ed il controllo dei propri utenti secondo gli standard di sicurezza concordati.

Il MEF viene quindi sollevato dalla gestione delle utenze e delle autorizzazioni puntuali di ciascun operatore, le cui credenziali vengono comunque fornite automaticamente nell’ambito della transazione.

È importante segnalare la “securizzazione” dei report prodotti, con apposizione di codici grafici bidimensionali, in grado di certificare il contenuto testuale e grafico del foglio stampato, con il web service “RichiestaRilascioCertificato”.

2.4 NoiPA-Gestione Accessorie

La componente di Gestione Accessorie è suddivisa in tre distinte aree tematiche:

• Attività uffici

• Funzioni di servizio

• Identificazione dipendente

2.4.1 Attività uffici

La presente area tematica raggruppa tutte le funzionalità che permettono di visualizzare e comunicare i dati relativi alle attività degli Uffici delle Amministrazioni servite dalla Gestione Accessoria e necessari per procedere al pagamento unificato delle competenze fisse e accessorie.

In particolare, le principali funzionalità presenti in questo ambito riguardano l’acquisizione dei compensi accessori, ad importi o a quantità, da erogare al personale, nonché l’acquisizione di nuovo personale allo scopo di renderlo beneficiario del pagamento dei soli compensi accessori.

In riferimento alla segnalazione dei compensi accessori mensili, il sistema mette a disposizione funzioni per effettuare comunicazioni sia ad elenchi, opportunamente prodotti, sia tramite flussi massivi, predisposti extra sistema nel rispetto dei tracciati previsti e pubblicati sul portale NoiPA.

Una volta inseriti i compensi accessori da liquidare, l’applicativo di Gestione accessoria effettua la simulazione della spesa per l’elenco indicato per un’opportuna verifica sulle quote calcolate; se i risultati corrispondono a quanto atteso, tramite la funzione di Richiesta Autorizzazione l’elenco in esame viene sottoposto all’attenzione del Responsabile per l’autorizzazione definitiva al pagamento.

Oltre a tali inserimenti finalizzati alla liquidazione degli importi spettanti a titolo di accessorie, il sistema consente anche l’acquisizione dei compensi accessori fuori sistema, ovvero dei compensi relativi a liquidazioni effettuate al di fuori del sistema NoiPA a vario titolo al personale, che devono essere considerati ai soli fini del conguaglio fiscale e contributivo di fine anno.

Sono state anche realizzate delle funzionalità specifiche per la gestione dei compensi accessori del personale della Polizia di Stato, per il quale sono previste regole di attribuzione e controlli di spettanza particolari.

Nella stessa area tematica sono presenti anche altre funzioni dedicate ad operazioni più specifiche, quali:

• Compensi vari: funzioni messe a disposizione per la comunicazione e la liquidazione delle retribuzioni spettanti a tipologie particolari di personale come, ad esempio i volontari dei VVFF. Vista la specificità di tali pagamenti tali funzioni sono state abilitate a una tipologia particolare di utenza. Le modalità operative messe a disposizione per gli operatori per questa tipologia di pagamento sono analoghe a quelle illustrate per il pagamento dei compensi accessori, ad eccezione

del fatto che per la liquidazione dei compensi vari viene effettuato, tramite sistema, anche l’invio al sistema della Ragioneria Generale dello Stato per la richiesta di autorizzazione alla liquidazione delle retribuzioni spettanti al personale in oggetto;

• Esclusione certificazione CU: funzione finalizzata alla selezione degli eventuali compensi accessori da escludere dalla certificazione CU; contestualmente il sistema consente di produrre un certificato che attesti l’esclusione dal CU;

• Assegnazione dipendenti ai Centri di costo: funzione che consente di visualizzare ed assegnare il centro di costo agli amministrati gestiti;

• Consultazione Piano di riparto: funzione che permette di visualizzare, per ogni capitolo/piano gestionale, l’importo stanziato, l’importo richiesto, l’importo autorizzato e l’importo disponibile.

2.4.2 Funzioni di servizio

La presente area tematica raggruppa tutte le funzionalità che permettono la visualizzazione e gestione di elementi di supporto alla struttura dell’Amministrazione. In particolare da questa area tematica è possibile gestire:

• Modello operativo: che raccoglie le funzioni che consentono di visualizzare e gestire gli elementi presenti in NoiPA che concorrono alla definizione della struttura organizzativa coinvolta nel processo di segnalazione delle competenze accessorie. Più precisamente tali funzioni consentono, per ciascun Ente gestito, di definire il processo autorizzativo in atto e l’anagrafica dei Punti Ordinanti della Spesa (detti POS), nonché l’elenco degli Uffici di servizio gestiti dal singolo POS;

• Compensi accessori: che consente la visualizzazione e la definizione della struttura dei compensi accessori maggiormente aderente alla singola realtà amministrativa. Tramite tali funzionalità è possibile, infatti, consultare e gestire i sottocompensi accessori utilizzabili dall’Ente su cui l’operatore è abilitato a lavorare, definendo le peculiarità del singolo sottocompenso, nonché gli importi tabellari degli stessi sottocompensi a quantità;

• Gestione utenze e ruoli: che consente di visualizzare e richiedere la modifica dei coni di visibilità e dei ruoli attribuiti agli utenti della componente Gestione Accessoria;

• Gestione Centri di costo: che consente di gestire i Centri di costo dell’ente su cui si è abilitati.

2.5 Identificazione dipendente

É il servizio che permette agli operatori a cui sia attribuito l’apposito ruolo di Responsabile dell’Identificazione (RID) la corretta creazione dell'identità digitale di ogni amministrato presente in NoiPA, qualora questa non sia stata già completata con la registrazione del dipendente nella gestione Anagrafica inserendo, insieme a tutti gli altri dati, l'indirizzo e-mail. L’operatore può modificare i recapiti personali (e-

mail e numero di telefono) e richiedere la generazione del codice PIN necessario per le operazioni effettuabili tramite le funzionalità self service nell’ambito dei servizi stipendiali.

2.6 NoiPA-Gestione Presenze (Time Management)

Il sottosistema modulo “Gestione Presenze” di NoiPA è l’applicativo finalizzato alla Rilevazione Presenze del personale delle Amministrazioni aderenti alla soluzione avanzata, rispondente alla normativa giuridica vigente per il personale della P.A. del Comparto Ministeri, degli Enti locali, ecc.

Tale componente è integrata con l’applicativo Gestione Stipendio tramite il modulo Gestione Anagrafica.

Oltre alle funzionalità core della gestione delle presenze e assenze del personale, il sistema prevede anche le funzioni per la gestione del personale esterno, ovvero del personale non presente nei ruoli dell’Ente ma che transita presso le sedi dell’Ente stesso in modalità continuativa, le funzioni per la gestione dei visitatori occasionali e le funzioni per la gestione dei badge utilizzabili per l’accesso presso le varie sedi.

Il sottosistema “Gestione Presenze” è stato realizzato come evoluzione del sistema SPRING attualmente ancora in uso presso il MEF ed integrato con il SIAP -(Sistema Informativo per l’Amministrazione del Personale del MEF). Sono in corso le attività per la migrazione da SPRING al nuovo sistema. ). Nei paragrafi successivi si riporta una breve descrizione delle aree tematiche trattate da tale applicativo.

2.6.1 Configurazione del sistema

In questo ambito sono raccolte le funzionalità preposte alla gestione dei parametri del sistema.

L’attività di configurazione, gestita centralmente, è propedeutica alla gestione delle Presenze/Assenze dei dipendenti del singolo ente. La parametrizzazione di ogni aspetto della rilevazione presenze consente l’adeguamento alle nuove disposizioni generali o il trattamento di situazioni particolari. Da questa sezione è possibile, infatti, soddisfare le esigenze più ricorrenti, quali, ad esempio, l’aggiornamento dei parametri relativi alle assenze e la codifica delle caratteristiche delle prestazioni, delle regole di assegnazione e tassazione dei buoni pasto e delle regole di colloquio con il servizio stipendiale.

2.6.2 Presenze/Assenze

La presente area tematica contiene le funzioni ed i report preposti alla gestione dei dati giornalieri di ciascun dipendente trattato, al fine di predisporre il quadro riepilogativo dell’intera attività svolta nel corso del mese dal personale di ogni ufficio gestito.

Da qui sono possibili, infatti, l’inserimento puntuale ed il controllo di ogni elemento riguardante sia le presenze sia le assenze effettuate dai dipendenti. Sono, inoltre, presenti funzioni per la verifica degli aspetti giuridico amministrativi legati alla fruizione delle assenze, all’attribuzione delle spettanze e delle indennità, nonché alla predisposizione della documentazione per la richiesta della visita fiscale da inoltrare alle Asl competenti.

Le principali funzionalità utilizzate in questa area sono:

• Dati rilevazione presenze, funzione che raccoglie tutte le informazioni di configurazione relative al trattamento della persona nell’ambito delle gestione presenze;

• Visualizzazione timbrature, funzione per la consultazione delle timbrature effettuate da un nominativo in un determinato giorno o lasso di tempo;

• Dati giornalieri, funzione che riassume tutte le informazioni relative alla presenza o assenza di un dipendente in una specifica giornata, quali la fascia oraria, le suddivisioni della giornata lavorativa con gli eventuali giustificativi di assenza, le indennità spettanti e le timbrature; da qui è possibile richiedere al sistema di effettuare la “quadratura” di tutte le informazioni registrate sulle singole giornate, ovvero di evidenziare eventuali differenze tra la prestazione lavorativa teorica e la prestazione effettivamente erogata dal singolo dipendente;

• Inserimento assenze, funzione dedicata all’inserimento delle assenze “intera giornata” comunicate alle segreterie dai singoli dipendenti. La funzione propone, in maniera dinamica, le informazioni da acquisire in funzione dello specifico codice assenza inserito, come ad esempio propone i campi necessari per l’attivazione della visita fiscale a fronte dell’inserimento di assenze per malattia.

2.6.3 Gestione mensile

In questa area sono raccolte le funzioni per la predisposizione dei dati di fine mese utili alla liquidazione dei compensi accessori al personale. Sono, infatti, presenti le funzioni per la determinazione del quadro riepilogativo dell’intera attività svolta nel mese precedente dal personale di ogni ufficio gestito. Con tale riepilogo mensile si governa l’assegnazione dell’eventuale straordinario, dei buoni pasto e delle altre indennità accessorie e si calcola l’effetto economico da applicare sulle competenze stipendiali a fronte di specifici aventi di assenza.

Le informazioni raccolte in questa fase verranno, quindi, successivamente trasferite nella componente Gestione Stipendio per essere applicate, nel rispetto dell’iter approvativo definito, nella fase di emissione delle competenze fisse ed accessorie.

Sono, inoltre, messi a disposizione degli operatori diversi report di riepilogo dei dati di fine mese, fruibili per singolo nominativo o per un intero ufficio; tra questi la stampa del “Cartellino mensile”.

Alcune funzionalità presenti in questa area sono:

• Autorizzazione preventiva, funzione che consente al Dirigente responsabile di autorizzare preventivamente le ore in eccedenza da liquidare e/o da riportare come recupero al mese successivo, anche in presenza del regime di Banca delle ore previsto dai CCN;

• Liquidazione voci, funzione che consente di trasformare l’eventuale quantità di ore eccedenti, maturate dal singolo dipendente, in ore di straordinario, ovvero un

numero di ore mensili da trasferire alla componente economica che provvederà alla liquidazione del corrispettivo al dipendente;

• Verifica stato mese, strumento di supporto per le segreterie degli uffici per il controllo dello stato dei mesi di ogni singolo ufficio.

2.6.4 Gestione Badge e Personale esterno

Questa area contiene le funzioni e la reportistica per la gestione delle informazioni dei badge per l’accesso alle sedi delle strutture organizzative per il personale dipendente e per il personale esterno all’ente, sia stabile che occasionale, e per la gestione dell’anagrafica del personale esterno e delle ditte di provenienza dello stesso personale.

2.6.5 Segnalazioni self service

La componente di rilevazione presenze offre alcuni servizi anche in modalità self service.

Ciascun dipendente, infatti, tramite specifiche funzioni messe a disposizione sul portale NoiPA può, ad esempio, stampare il proprio cartellino mensile, effettuare la richiesta di ferie o di altre tipologie di assenza, sia orarie che giornaliere, e visualizzare le proprie timbrature del giorno.

2.7 NoiPA-Sanità

Il modulo NoiPA-Sanità è la soluzione per la gestione del personale — dipendente e convenzionato — del comparto Sanità.

NoiPA Sanità gestisce i tradizionali aspetti legati all’amministrazione del personale (stato giuridico, rilevazione presenze e trattamento economico), nonché quelli relativi al capitale umano delle aziende sanitarie.

La soluzione si articola in sistemi applicativi dedicati alle singole specifiche esigenze organizzative e amministrative:

• Sistema per il trattamento economico;

• Sistema per il trattamento giuridico;

• Sistema per la gestione delle presenze;

• Sistema per la gestione del capitale umano.

Il modulo Sanità è integrato con il modulo NoiPA-Gestione anagrafica da cui l’operatore inserisce i dati anagrafici dei nuovi amministrati che vengono poi propagati, in modalità asincrona, aNoiPA-Sanità dove viene perfezionata la procedura di immatricolazione. L’integrazione è anche garantita in fase di pagamento ed elaborazione e pubblicazione dei cedolini di stipendio nell’area privata del portale NoiPA, nonché di produzione di produzione e deposito su cartelle FTP dei flussi mensili utili per il pagamento. Inoltre sono in corso una serie di progetti e sviluppi, che su

vari ambiti e aree tematiche, tendono a garantire maggiore integrazione e omogeneità con l’intero sistema NoiPA.

2.7.1 Sistema per il trattamento economico

Il Sistema per il Trattamento economico è composto da moduli applicativi in grado di supportare l’Azienda Sanitaria in tutte le fasi di trattamento dei dati del personale sia dipendente che non.

E’ articolato in due aree funzionali:

• Contabile Personale Dipendente e Collaboratori;

• Gestione Fondi.

L’applicazione permette la gestione integrata degli aspetti contrattuali, fiscali, previdenziali, contabili e statistici connessi alla gestione delle retribuzioni dei dipendenti e dei collaboratori, integrati con il sottosistema informativo contabile.

Sono, inoltre, supportate tutte le pratiche di pensione INPS avendo, come base, tutti i dati di carriera giuridica ed economica del personale.

La seconda area si occupa della gestione dei fondi, per i quali i CCNL stabiliscono i criteri per determinare l’importo iniziale, i criteri di aggiornamento o di consolidamento, i criteri di gestione dei residui con indicazione dei vincoli per lo spostamento di importi tra fondi. in questa area, integrata con il sistema di gestione giuridica del personal, è possibile gestire i vari fondi e di definire:

• la costituzione del fondo;

• le regole di accesso al fondo;

• i criteri di distribuzione;

• il pagamento delle quote individuali spettanti;

• la disponibilità;

• i costi di progetto;

• le stime annue del consumato permettendo un’analisi preventiva dell’impatto economico di eventuali rettifiche dei criteri di attribuzione, anche come supporto alla contrattazione decentrata;

• il residuo per eventuale utilizzo.

Il sistema per il Trattamento Economico permette la gestione delle figure professionali tipiche del comparto sanità quali:

• Dirigenza medica e non medica;

• Personale del comparto;

• Collaboratori a Progetto (ex coordinati e continuativi);

• Consulenti e Liberi Professionisti;

• Personale Universitario.

Per l’elaborazione degli stipendi mensili è previsto un ciclo di elaborazione, gestito centralmente, distinto in fasi eseguite in sequenza:

• Generazione e/o definizione dei dati di riduzione stipendiali (nuove assunzioni, dimissioni, aspettative, ecc.);

• Aggiornamento assegno familiare;

• Aggiornamento retribuzione contrattuale;

• Calcolo cedolini mensili per tutto il personale;

• Ricalcolo individuale o cumulativo dei cedolini mensili.

Come già descritto nel paragrafo “ Calcolo e pubblicazione del cedolino e liquidazione competenze”, anche per gli Enti fuori bilancio del comparto sanità il sistema NoiPA mette a disposizione un flusso avente il formato standard CBI (Corporate Banking Interbancario). I cedolini vengono elaborati, prodotti e pubblicati nell’area privata del portale NoiPA a disposizione dei singoli amministrati.

Sempre nell’ambito della Gestione del Trattamento economico è presente la sezione di Denunce e Stampe da Storico che permette di ottenere tutti gli elaborati necessari per gli adempimenti di legge periodici, di cui:

• DMA;

• UNIEMENS INPS;

• Conto consuntivo trimestrale;

• Modello CU e certificazioni fiscali;

• predisposizione F24EP;

• Gestione modulistica previdenziale (IPS,TFS,TFR,PA04);

• Denuncia ENPAM e Assicurazione malattia;

• Denuncia ONAOSI;

• Ruolo nominativo Regionale;

• Conto Consuntivo Annuale e trimestrale.

2.7.2 Sistema per il trattamento giuridico

Il Sistema per il Trattamento Giuridico è l’applicazione per l’amministrazione della posizione contrattuale del personale dipendente e non, nonché lo strumento di gestione di tutte le informazioni che concorrono al completo inquadramento giuridico nella struttura aziendale.

Oltre alla tipica gestione anagrafica del personale e delle qualifiche, alla gestione delle carriere, del curriculum formativo e dello stato di servizio, garantisce la completa “tracciabilità” dei dati del personale, attraverso la gestione di attività procedurali relative a provvedimenti disciplinari, permessi sindacali, gestione categorie protette, infortuni, aspettative e congedi straordinari (ovviamente questi in collegamento con la rilevazione presenze).

In termini funzionali, è possibile suddividere la gestione delle informazioni del Sistema per il Trattamento Giuridico nei seguenti gruppi oggetto di fornitura:

• Gestione dei dati individuali;

• Gestione curriculum;

• Gestione assenze.

Sono disponibili una serie di report per lo svolgimento di tutti gli adempimenti normativi e lavorativi: denunce di legge, certificazioni di servizio e retributive, elenchi di personale, schede individuali, produzione di elaborati di natura statistica, ecc.

Nella sezione di Gestione dei dati individuali vengono gestite le informazioni generali e lavorative di tutto personale (dati individuali, carriera professionale, ecc.) che vanno a definire lo Stato Matricolare del personale. Tali informazioni alimentano gli altri moduli di NoiPA-Sanità quali il trattamento economico per la predisposizione mensile degli stipendi e per la gestione previdenziale.

Oltre ai dati anagrafici, il sistema consente la completa gestione del curriculum individuale del lavoratore, con informazioni relative ai titoli acquisiti, alle pubblicazioni, agli aggiornamenti professionali, alle variazioni dello stato di servizio periodo per periodo, alla collocazione lavorativa nell’organizzazione aziendale, alle eventuali sanzioni disciplinari, alle annotazioni di merito.

2.7.3 Sistema per la gestione delle presenze

Il sistema per la Gestione delle Presenze è l’applicazione per la Rilevazione Presenze del personale rispondente alla normativa giuridica vigente per il personale del comparto Sanità. Oltre alle funzionalità proprie della gestione delle presenze e assenze del personale, sono previste funzioni per la gestione del personale esterno e le funzioni per la gestione degli accessi presso le varie sedi.

L’applicazione è integrata con le applicazioni di gestione giuridica e contabile del personale, e trasferisce, in base alla rilevazione delle presenze, al modulo Trattamento Economico dati utili per l’applicazione di compensi accessori variabili, buoni pasto e riduzioni del trattamento economico. Anche nel modulo Sanità, sono garantite tutte le funzionalità disponibili in NoiPA – Gestione presenze, seppur specifiche per il comparto.

La componente di rilevazione presenze offre alcuni servizi anche in modalità self service, tramite specifiche funzioni messe a disposizione sul portale NoiPA:

• Gestione Autorizzazioni

• Richiesta Assenza

• Omessa Timbratura

2.7.4 Sistema per la gestione del capitale umano

Il sistema per il Capitale Umano è realizzato per soddisfare le esigenze organizzative ed operative dell’area delle risorse umane nell’ambito di tutte le attività di gestione, valutazione, valorizzazione e sviluppo del capitale umano.

Il sistema è articolato in una serie di aree applicative, di seguito riportate, che coprono funzionalmente tutte le fasi dei processi di gestione del capitale umano nei loro aspetti qualitativi e quantitativi:

Gestione della pianta organica

Questa area comprende le funzioni per la gestione della pianta ufficiale del personale aziendale, suddiviso per profili e per unità organizzative, evidenziando il personale effettivamente in servizio e gli eventuali posti messi in concorso e/o in mobilità, consentendo al servizio del personale di effettuare le operazioni principali attinenti la gestione della pianta organica, avere in tempo reale la situazione del personale in servizio e la situazione dei posti vacanti ottenuti come differenza fra la disponibilità offerta dall’organico ed i posti coperti.

Il sistema

Sono anche disponibili una serie di report quali ad esempio

• dipendenti in servizio distinti fra TI e TD (in riferimento alle diverse tipologie di incarico TD);

• dipendenti a TI con altro incarico a TD;

• dipendenti assenti per aspettativa;

• dipendenti a TD su posto vacante;

• totale dipendenti in servizio ;

• totale dipendenti assenti;

• Situazione riepilogativa per DIP/U.O./CDC/Qualifica;

• Situazione riepilogativa per Qualifica/DIP/U.O./CDC;

• Situazione complessiva aziendale per Qualifica/DIP/U.O./CDC.

Gestione degli organigrammi

Questa area consente la definizione delle strutture organizzative aziendali e della loro rappresentazione grafica, con la possibilità di definire più organigrammi tra loro indipendenti e univocamente referenziati dove in ognuno di essi è possibile definire posizioni organizzative correlate e, all’interno di ciascuna, assegnare il personale definendone il ruolo ricoperto.

2.8 Gestione Pensioni Xx Xxxxxx

La presente componente applicativa è finalizzata alla gestione degli indennizzi che lo Stato riconosce a militari e civili che, in azioni di guerra, hanno perso la vita o riportano gravi invalidità.

Questi eventi danno diritto a pensione diretta o indiretta, a seconda che la pensione, riconosciuta al “dante causa”, venga goduta da seè stesso o dal coniuge superstite o, in mancanza del coniuge superstite, dai figli maggiorenni inabili. In particolare, la presente applicazione gestisce le pensioni di guerra e gli assegni vitalizi di benemerenza, quali Medaglie d’argento e di bronzo e Croce di bronzo.

Sugli importi assegnati come indennizzo agli aventi diritto non vengono calcolati né contributi né ritenute erariali. La misura del trattamento varia a seconda del grado della menomazione.

Ai trattamenti pensionistici vengono attribuiti dei codici relativi agli assegni, che definiscono il tipo di assegno ed i relativi importi: assegno principale, assegno indennità integrativa speciale, assegno di accompagnamento, assegno di 1° e 2° cumulo, assegno di incollocabilità, assegno di super-invalidità, assegno per medaglie, assegno di integrazione, assegni vari, assegni con importi non tabellari e assegno supplementare, di maggiorazione e integratore.

A ciascuno di questi assegni è associato un suffisso che specifica la sottospecie e permette l’esatta attribuzione dell’importo tabellare. Per una corretta identificazione e classificazione delle partite vengono attribuiti i codici di Capitolo e Ministero ed i codici di microqualifica, relativi alla causa che ha determinato l’assegnazione del particolare trattamento di pensione.

La categoria di appartenenza e l’anno di riferimento costituiscono gli elementi indispensabili per la determinazione dell’importo base della pensione. All’importo così definito si aggiungono, in particolari condizioni o per diritto acquisito, ulteriori assegni; questi possono o meno avere una validità limitata.

Gli assegni liquidati a titolo di pensioni di guerra vengono corrisposti con cadenza mensile a differenza degli assegni vitalizi di benemerenza, liquidati con periodicità annuale.

2.8.1 Gestione pensioni tabellari

Questa area tematica è finalizzata alla gestione delle pensioni tabellari riconosciute agli aventi diritto per danni subiti nel corso di operazioni militari, maneggiando ordigni bellici. Come per le pensioni di guerra anche questi risarcimenti non sono soggetti ad imposte erariali.

La pensione tabellare costituisce un trattamento del tutto peculiare perché la sua entità è correlata alla gravità della menomazione, subita durante il servizio di leva, che determina una riduzione della abilità al lavoro.

Ai trattamenti pensionistici vengono attribuiti dei codici relativi agli assegni, che definiscono il tipo di assegno ed i relativi importi: assegno tabellare con o senza

indennità integrativa speciale, assegno di assistenza e accompagnamento, assegno di cumulo, assegno di super-invalidità e integrativo, assegno per medaglie, assegno di integrazione al minimo INPS, assegni con importi non tabellari, assegno d’integrazione, assegni vari e assegno MOGI base, aggiunta di famiglia. Quest’ultimo assegno, che spetta solo dietro presentazione di domanda, è un’integrazione per le famiglie dei titolari di alcune tipologie di pensioni tabellari.

2.8.2 Gestione indennizzi

Accanto ai tradizionali trattamenti pensionistici il sistema effettua anche la gestione di indennizzi dovuti come risarcimento per particolari motivi non legati a cause di guerra. Per ogni indennizzo sono previsti diversi codici che identificano i vari assegni di cui è composto:

• assegno base;

• assegno indennità integrativa speciale;

• assegno di super-invalidità;

• codice di perequazione annuale.

A questi assegni sono associati dei suffissi che specificano la sottospecie e permettono l’esatta attribuzione dell’importo tabellare.

Per una corretta identificazione e classificazione delle posizioni individuali vengono attribuiti i codici di microqualifica, relativi alla causa che ha determinato l’assegnazione dell’indennizzo ed alla specifica se trattasi di personale militare o civile.

2.8.3 Pensioni all’estero

Con scadenza bimestrale vengono calcolati gli emolumenti spettanti ai titolari di pensione residenti all’estero, gestiti esclusivamente dalla RTS di Roma.

Poiché le Rappresentanze Diplomatiche Italiane fanno da tramite tra l’Amministrazione e l’amministrato, l’avviso di pagamento viene inviato dall’Ufficio competente della RTS di Roma al Consolato Italiano d’appartenenza, tramite corriere diplomatico, un’unica volta nel momento in cui viene effettuato il primo pagamento o una variazione.

I pagamenti ai titolari di pensione all’estero si effettuano attraverso gli Istituti di credito corrispondenti del Tesoro o le rappresentanze Diplomatiche o Consolari.

2.8.4 Ritenute

Il sistema gestisce le ritenute che possono gravare sulle pensioni di guerra e tabellari. In considerazione dalla particolare natura di tali pensioni, sempre esenti da IRPEF, le ritenute vengono distinte in extra erariali, associative e sindacali.

Quelle extra erariali sono di natura obbligatoria:

• ritenute per recupero di somme indebitamente riscosse;

• ritenute alimentari a favore del coniuge separato o divorziato o per il mantenimento dei figli;

• ritenute per pignoramento.

Quelle associative e sindacali sono di natura volontaria e vengono effettuate su richiesta del pensionato:

• deleghe a favore di associazioni;

• deleghe a favore di organizzazioni sindacali.

2.8.5 Liquidazione e certificato sostitutivo del libretto

Il sistema calcola mensilmente gli emolumenti spettanti ai titolari di pensione, provvedendo alla liquidazione tramite pagamenti telematici con lo stesso flusso di colloquio previsto per il pagamento degli stipendi degli Enti in bilancio gestiti in NoiPA- Gestione stipendi. Solo ad inizio anno ed in caso di variazioni viene inviato ai beneficiari, in formato cartaceo, il certificato sostitutivo del libretto con il prospetto analitico del trattamento. Tale prospetto contiene, oltre ai dati del nominativo beneficiario dell’emolumento, la data di esigibilità della pensione, le modalità di pagamento ed i dati di dettaglio dell’importo corrisposto (importo annuo lordo, tredicesima, pensione mensile base, assegni di maggiorazione, eventuali ritenute, indennità integrativa speciale, se spettante).

2.9 SIAP

Il SIAP, Sistema Informativo per l’Amministrazione del Personale, è un sistema integrato adattato secondo la normativa del pubblico impiego, rivolto alla gestione automatizzata dei processi amministrativi, giuridici e delle risorse umane del personale, realizzato dal Ministero dell’Economia e Finanze con lo scopo di automatizzare i processi interni di gestione del personale e di fornire uno strumento di supporto a tutte le strutture dell’Amministrazione coinvolte in tale gestione.

Il SIAP è stato realizzato attraverso operazioni di parametrizzazione e personalizzazione di un pacchetto di mercato (Oracle HR e-Buisiness suite) al fine di rispondere alle diverse modalità operative in essere al Ministero, di gestione del personale.

Nel SIAP è mappata tutta la struttura organizzativa del MEF, Dipartimenti, Direzioni, Uffici e le assegnazioni del personale ai vari uffici.

Con il SIAP è possibile gestire anche tramite l’utilizzo di strumenti di Work-flow management e attraverso l’integrazione con il modulo applicativo SPRING, realizzato in house per la gestione delle presenze/assenze, tutti i processi afferenti alla gestione

del personale e tutti gli eventi che caratterizzano la vita del dipendente all’interno della Amministrazione.

Di seguito sono elencati i processi amministrativi attualmente gestiti attraverso il SIAP, aggregati in 4 macrogruppi funzionali:

• Gestione struttura organizzativa/anagrafica

o Variazioni della Struttura organizzativa del Ministero

o Immatricolazione del Dipendente

o Variazione dati anagrafici

o Gestione dell’assegnazione all’ufficio

o Trasferimenti

o Gestione comandi In/Out

o Gestione fuori ruolo

o Cessazione dal servizio

• Gestione giuridica

o Gestione dei Part-time

o Permessi di studio

o Permessi sindacali

o Oonorificenze

o Anagrafe degli incarichi

o Gestione del Fascicolo Dipendente

• Gestione amministrativa

o Buoni pasto

o Straordinari

o Indennità particolari

o FUA ed altre competenze accessorie

o Missioni

• Gestione risorse umane e altri aspetti legati al personale

o Formazione

o Tessere di riconoscimento

o Dati logistici

Attraverso un’area di stage alimentata giornalmente, il SIAP rende disponibile le informazioni organizzative, anagrafiche, giuridiche , ecc. d’interesse, ad altri sistemi, DWH DAG, DWH e altri sistemi RGS, Sogei per Dipartimento Finanze, Controllo di gestione del MEF, Intranet DAG, ecc.

Nell’ambito della Intranet dell’Amministrazione, il SIAP rende fruibili a dipendenti e dirigenti funzionalità Self Service per la visualizzazione di informazioni personali, presenze/assenze, gestione delle notifiche, gestione delle deleghe, richiesta dell’Attestato di Servizio, richiesta/approvazione Missioni, ecc.

2.10 SPRING

SPRING è l’applicativo utilizzato per la gestione della Rilevazione Presenze del personale del MEF rispondente alla normativa giuridica vigente per il personale della

P.A. del Comparto Ministeri e alla legge Stanca per l’Accessibilità.

Oltre alle funzionalità core della gestione delle presenze e assenze del personale, il sistema SPRING prevede anche le funzionalità per la gestione del personale esterno, le funzioni per la gestione dei visitatori occasionali e le funzioni per la gestione dei badge utilizzabili per l’accesso presso le varie sedi.

SPRING è stato poi ampliato con le funzionalità per la gestione di alcuni processi giuridici quali Decreti e Provvedimenti, Stato matricolare, Anzianità di Servizio.

Le aree tematiche caratterizzanti il sistema di rilevazione presenze sono le seguenti:

Configurazione: gestione dei parametri e delle regole utilizzate all’interno del sistema (ad esempio codici di assenza, orari di lavoro, regole di assegnazione dei buoni pasto, accordi specifici sull’applicazione dei turni).

Presenze/Assenze:

• le funzioni ed i report per la gestione dei dati giornalieri di presenza del personale dell’Amministrazione.Lla sezione raccoglie le funzionalità di inserimento e controllo quotidiano delle presenze/assenze del personale

• visualizzazione delle timbrature acquisite in automatico dai lettori badge delle diverse Sedi del MEF

• funzioni per la gestione dei dati di una singola giornata del dipendente, attraverso l’inserimento di assenze e relativi giustificativi, timbrature, ecc. in modo da comporre la giornata per la relativa ‘quadratura’

• funzioni e report per la gestione dei dati giornalieri del personale dell’Amministrazione; la sezione raccoglie le funzionalità di inserimento e controllo quotidiano delle presenze/assenze del personale (ad esempio, Inserimento assenze e Dati giornalieri);

Gestione mensile: funzioni per le operazioni mensili propedeutiche alla liquidazione dei compensi accessori al personale ed i report correlati; la sezione raccoglie tutte le funzioni di conteggio dei dati di fine mese di ciascun dipendente (ad esempio, compensazione tra residui ed eccedenze, totalizzazione delle indennità maturate, buoni pasto, turni, …, stampa del cartellino mensile);

Esterni/Badge: funzioni e la reportistica per la gestione dei badge, del personale esterno e dei visitatori; tramite le funzionalità disponibili è possibile gestire i principali dati anagrafici del personale in esame e l’anagrafica dei badge di accesso alle sedi, nonché le associazioni dei badge a tutto il personale, interno ed esterno all’Amministrazione;

Sistema: funzioni, di carattere principalmente tecnico, che permettono di definire le regole di accesso all’applicazione, registrando gli utenti ed il relativo ruolo di abilitazione. In funzione dei ruoli assegnati, è possibile personalizzare il sottoinsieme di funzioni a cui si è abilitati e la porzione di personale su cui può operare

A queste funzioni specifiche di un sistema di Gestione delle presenze/assenze si aggiungono le seguenti ulteriori funzionalità:

• Funzioni self service in uso a dipendenti e dirigenti: consentono di stampare il proprio cartellino mensile, il dettaglio delle assenze giornaliere, la situazione di ferie/permessi usufruiti, effettuare la richiesta/approvazione di ferie e di altre tipologie di assenza, comunicare le giornate di assenza afferenti a tipologie che non prevedono l’approvazione da parte del dirigente, la gestione delle deleghe di approvazione.

• Funzioni correlate con la rilevazione presenze: calcolo delle riduzioni derivanti dalle assenze con impatto economico da trasmettere al sistema di payroll per l’applicazione sulle competenze fisse, gestione del monte ore dello straordinario, gestione dei turni, calcolo delle giornate utili ai fini della determinazione del Fondo Risorse Decentrate e delle altre competenze accessorie correlate alla presenza del personale, predisposizione della richiesta di visita fiscale da inoltre alle Asl .

• Funzioni correlate ai processi di Gestione Giuridica: predisposizione dei Provvedimenti con la gestione dei dispositivi, produzione del provvedimento comprensivo dell’iter approvativo del Decreto da parte del Dirigente Responsabile fino alla presa d’atto dell’UCB competente, predisposizione e gestione dello Stato Matricolare del personale sia in copia semplice che securizzata, Trattamento di Quiescenza e Buonuscita.

I sistemi SIAP e Spring sono integrati attraverso componenenti software che consentono il trasferimento delle informazioni necessarie ai due sistemi (anagrafica, organizzazione, dati dei buoni pasto, straordinari…)

3. ARCHITETTURA DEL SISTEMA

La descrizione del Sistema articolata nei prossimi paragrafi considera tutte le componenti tecnologiche presenti in esercizio alla data di stesura della presente documentazione di gara.

L’architettura riguarda l’attuale sistema NoiPA (legacy), mentre viene descritta a parte l’architettura del nuovo sistema in corso di realizzazione (Cloudify).

3.1 Il Portale NoiPA

Per la descrizione dell’architettura del Portale NoiPa si rimanda al paragrafo 5.2 dove si descrive il portale Cloudify essendo già rilasciata in esercizio la nuova versione target.

3.2 Gestione Anagrafica

Il sistema della Gestione Anagrafica del Personale della Pubblica Amministrazione rappresenta la base anagrafica unica per il personale della PA, in grado di accogliere tutti i dati anagrafici d’interesse quali, ad esempio, l’ente di appartenenza e la sede di servizio e di alimentare i sistemi stipendiali e di gestione presenze

Anagrafica Unica è stato sviluppato in aderenza al modello architetturale Master Data Management, e cioè come un insieme di processi, policy, e servizi utilizzati per creare, mantenere e governare i dati del dominio di differenti processi di business. La seguente figura schematizza le principali componenti del sistema:

Figura 5 – Le componenti del sistema NoiPa – Gestione anagrafica

L'application layer è quasi interamente basato su di un architettura SOA costruita su Carbon WSO2, software open source, capace di espletare i principali compiti richiesti ad una SOA come fornire dei servizi di data services, business process management, ESB routing/transformation, rules, security, logging e monitoring.

L'unica componente dell'application layer non appartenente ai prodotti WSO2 è l'application server weblogic su cui sono installati i servizi di business.

Di seguito sono brevemente descritte le principali componenti dell’infrastruttura:

Enterprise Service BUS

è un'infrastruttura software che fornisce servizi di supporto ad architetture SOA complesse. Un ESB si basa su sistemi disparati, interconnessi con tecnologie eterogenee, e fornisce in maniera consistente servizi di orchestration, sicurezza, messaggistica, routing intelligente e trasformazioni, agendo come una dorsale attraverso la quale viaggiano servizi software e componenti applicativi.

Governance registry

Governance Registry è un prodotto open source per gestire i deployments in ambiente SOA. Serve a storicizzare, catalogare e gestire i metadata dei deployments in modo scalabile.

Data Service Server

Data Service Server (DSS) è la piattaforma di hosting e gestione dei servizi per l’accesso ai dati.

Identity Management

gestisce le identificazioni, le autorizzazioni, i ruoli ed i privilegi delle singole utenze allo scopo di aumentare la sicurezza.

Elenco server di front end

Si riporta nella tabella successiva la configurazione software e il dimensionamento delle macchine virtuali, presenti nell’area WEB dedicata all’accesso intranet.

Modello	S.O.	CPU	RAM	HD
VMware	RH Enterprise 6 (64-bit)	1	8 GB	40 GB
VMware	RH Enterprise 6 (64-bit)	1	8 GB	40 GB

Prodotti installati - Server version: Apache/2.2.15 (Unix)

Elenco server di back end

Si riporta nella tabella successiva la configurazione software e il dimensionamento delle macchine virtuali presenti nell’area di backend. Il sistema operativo installato su tutte le macchine è RHEL 6 (64-bit).

Nome macchina	Modell o	CPU	RAM	HD	Funzione
Applicanaes1.scsii.tesoro.i t	VMwar e	1	8 GB	40 GB	weblogic
Applicanaes2.scsii.tesoro.i t	VMwar e	1	8 GB	40 GB	weblogic
Dataseranaes1.scsii.tesor x.xx	VMwar e	1	16 GB	40 GB	Data-services
Dataseranaes2.scsii.tesor x.xx	VMwar e	1	16 GB	40 GB	Data-services
Dataseranaes3.scsii.tesor x.xx	VMwar e	1	8 GB	40 GB	Data-services
Dataseranaes4.scsii.tesor x.xx	VMwar e	1	8 GB	40 GB	Data-services
Xxxxxxxx0.xxxxx.xxxxxx.xx	VMwar e	1	12 GB	40 GB	ESB
Xxxxxxxx0.xxxxx.xxxxxx.xx	VMwar e	1	12 GB	40 GB	ESB

Nome macchina	Modell o	CPU	RAM	HD	Funzione
Xxxxxxxx0.xxxxx.xxxxxx.xx	VMwar e	1	8 GB	40 GB	ESB
Xxxxxxxx0.xxxxx.xxxxxx.xx	VMwar e	1	8 GB	40 GB	ESB
Xxxxxxxx0.xxxxx.xxxxxx.xx	VMwar e	1	16 GB	40 GB	Governance
Xxxxxxxx0.xxxxx.xxxxxx.xx	VMwar e	1	16 GB	40 GB	Governance
Identityanaes1.scsii.tesor x.xx	VMwar e	1	16 GB	40 GB	Identity
Identityanaes2.scsii.tesor x.xx	VMwar e	1	16 GB	40 GB	Identity

ESB

Prodotti installati: WSO2 ESB 4.0.3

Data Services

Prodotti installati: WSO2 Data Services Server 2.6.3

Governance

Prodotti installati: WSO2 Governance Registry 4.1.1

Identity

Prodotti installati: WSO2 Identity Server v3.2.3

Weblogic

Prodotti installati: Weblogic server 12.1

DB Server

Il DB Oracle Server 11.2.0.4 a 64 bit è ospitato su un server AIX 6.1 .

Mappatura server

La mappatura server/funzioni applicative espletate è la seguente. Tutti i server sono virtuali, tranne il DB server.

Server_Host

Funzione

Xxxxxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxxxxx0.xxxxx.xxxxxx.xx

Application Weblogic

Xxxxxxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxxxxxx0.xxxxx.xxxxxx.xx

Data-services

Server_Host	Funzione
Xxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxx0.xxxxx.xxxxxx.xx	ESB
Xxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxx0.xxxxx.xxxxxx.xx	Governance
Xxxxxxxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxxxxxxx0.xxxxx.xxxxxx.xx	Identity
Xxxxxxxx0.xxxxx.xxxxxx.xx Xxxxxxxx0.xxxxx.xxxxxx.xx	AnaUnica-WEB
xx0xxx.xx.xxxxxx.xx	Database

Integrazione NoiPA Anagrafica Unica con altri sistemi

NoiPa – Gestione anagrafica deve integrarsi necessariamente con i seguenti sistemi e servizi trasversali:

• Portale NoiPA

• Access Manager (Oracle Access Manager)

• PDD (per il colloquio con Agenzia delle Entrate)

• NoiPA Gestione presenze

• NoiPA Gestione stipendio

• NoiPA Sanità

• DNS

• Bilanciatori

• Firewall

• DB server

3.3 Gestione Presenze Assenze

L’architettura del sistema NoiPA-Gestione Presenze è realizzata in three tier che prevede la suddivisione del sistema in tre diversi moduli dedicati rispettivamente all’interfaccia utente (presentation), alla logica funzionale (business logic) ed alla gestione dei dati persistenti (data layer), con lo scopo di disaccoppiare i livelli applicativi rendendoli indipendenti, flessibili e manutenibili.

Concettualmente l’infrastruttura si articola in:

• un front-end che interfaccia il sistema agli utenti;

• un back-end che contiene:

- la logica funzionale interna,

- la logica di integrazione della configurazione,

- l’interfacciamento con altri sistemi come le timbrature,

- il batch processing di stampe e calcoli;

• un database relazionale per la persistenza dei dati.

La seguente figura schematizza le principali componenti del sistema:

Figura 6 – Le componenti del sistema

Presentation

–

Figura 7 – Le componenti del sistema “Gestione presenze”

Figura 7

Il layer Presentation gestisce il colloquio con l’utente ed è realizzato con due componenti:

• il Controller che si occupa della lettura ed interpretazione dell’input dell’utente;

• il View che si occupa della presentazione delle informazioni richieste all’utente. Queste componenti comunicano con l’utente attraverso il Web Browser tramite il protocollo HTTP / HTTPS.

L’HTML prodotto trasmesso all’utente rispetta le regole di accessibilità previste dalla legge Stanca.

Business

Il Transaction Manager offre dei servizi per il controllo di una transazione

Il Security Manager espone servizi informativi che indicano la possibilità di utilizzo degli oggetti funzionali da parte dell’utente o di un client più in generale. Il SM fornisce:

• l’informazioni di autenticazione dell’utente;

• l’elenco delle Responsabilità assegnate all’utente;

• i filtri di visibilità del partizionamento dati legato ad una Responsabilità;

• il menù e l’elenco delle funzioni logiche abilitate all’utente/Responsabilità.

Data Access

Per l’accesso ai dati sono impiegate le tecnologie JDBC, SQLJ, Hibernate e EJB3.

Il Data Access Object disaccoppia i livelli Business e Data, esponendo servizi business di persistenza ed incapsulando le modalità di accesso ai dati. I DAO accedono direttamente al database via JDBC o tramite SQLJ e non contengono logica di Business. Pertanto, il DAO è l’unico oggetto Java coinvolto nel caso fosse necessario migrare verso diverse tipologie di database.

Service

I servizi tecnici sono finalizzati alla gestione informatica del sistema e sono concettualmente raggruppati in un insieme eterogeneo detto Service.

Nel database di sistema si collocano la configurazione sistemistica ed informatica del sistema, necessarie al perseguimento della completa configurabilità di NoiPA- Gestione presenze, e tutte le informazioni non funzionali alla tematica applicativa.

Il DB di sistema contiene:

• configurazione sistemistica: determina su quali hardware sono disponibili quali servizi;

• configurazione funzionale: mantiene l’elenco delle funzioni logiche attive deployate sul sistema e la relativa versione;

• sicurezza: contiene le utenze funzionali e tecniche con le relative autorizzazioni;

• log attività: mantiene il log delle attività che l’utente funzionale e di sistema svolge sul sistema;

• tasks: archivia i Task funzionali (calcolo e stampe) e di sistema (backup) con relative schedulazioni e status;

• report repository: archivio dei documenti prodotti a fronte di richieste utente non interattive (sincrone).

Il Service locator offre l’individuazione centralizzata dei servizi di sistema e ne incapsula la complessità legata alla configurazione sistemistica.

Il Tasker è la coppia oggetto/servizio (Task/TaskManager) per la gestione delle attività utente e di sistema. Contiene tutte le informazioni necessarie alla passivazione/archiviazione ed esecuzione di una unità di lavoro.

Lo Scheduler è il sottosistema di programmazione di attività. Invocato dal TaskManager, lo Scheduler memorizza il Task per notificare in seguito allo stesso XxxxXxxxxxx l’avvenimento dell’evento.

Data

Il data layer è deputato a gestire la persistenza dei dati. Il livello data è disaccoppiato dal business dallo strato Data Access (DAO/EJB) che incapsula le istruzioni SQL per la manipolazione dati. Il motore RDBMS di NoiPA-Gestione presenze è Oracle Database 11g. Il DB è utilizzato principalmente nelle sue funzionalità di archiviazione ed organizzazione dati.

Motore di Workflow

Per l’implementazione di alcuni processi SPRING è stato integrato con il motore di Workflow Opensoure “SPAGIC”.

L’architettura del sistema prevede:

• un database relazionale per l’archiviazione delle informazioni;

• un application server, con supporto alle specifiche J2EE 1.4 e JDK 6, per la gestione del sistema e l’interfaccia utente;

• un job server per la gestione di elaborazioni batch di calcolo, stampa ed ETL;

• un web service per l’interfacciamento non ETL con altri sistemi.

La configurazione NoiPA-Gestione presenze prevede la definizione di “Silos” auto consistenti facilmente scalabili orizzontalmente al crescere delle esigenze, di seguito viene rappresentata lo schema di uno dei due “Silos” gemelli presenti in ambiente di collaudo, mentre la descrizione di seguito conta i server presenti in uno dei due “Silos” dell’ambiente di esercizio:

• 4 Application Server Oracle AS 11G v10.3.6 per il gestionale NoiPA-Gestione presenze ed i WebServices;

• 6 Application Server Oracle AS 11G v10.3.6 per l’esecuzione del business di calcolo e dei report;

• 4 Application Server Oracle AS 11G v10.3.6 per la gestione delle code dello schedulatore Quartz

• 4 Application Server Oracle AS 11G v10.3.6 per la gestione del motore di workflow Spagic;

• un Database Server Oracle DB 11G che ospita la base informativa della rilevazione presenze e la base dati di sistema

3.4 Gestione Economica (Stipendi)

La componente NoiPA-Gestione stipendio è un’applicazione consolidata da molti anni. Le logiche e i principali componenti dell’architettura del sistema sono rappresentati in due diagrammi schematici, di seguito forniti, caratterizzati da livelli di dettaglio differenti e precisamente:

• Enterprise View: con cui si identificano, ad alto livello, le componenti presenti nel sistema.

• Service View: con cui si definiscono e classificano i potenziali servizi che compongono la soluzione architetturale.

Con tali schemi si vuole:

• rappresentare da un punto di vista concettuale le componenti del sistema;

• definire le interazioni tra le diverse componenti dell’architettura;

• facilitare la comunicazione tra le diverse comunità di soggetti interessati;

• facilitare l'orientamento di persone nuove che aderiscono al progetto e fornire elementi per indirizzare gli sviluppi futuri.

Enterprise View Diagram

Figura 8 – Enterprise view diagram NoiPA – Servizi stipendiali

Il sistema è esposto su Internet e fruibile da una vasta platea di utilizzatori che dispongono di stazioni di lavoro eterogenee sia per SO (windows, linux , system) che per browser (explorer, firefox, safari etc.).

Il sistema è acceduto dagli utenti con protocollo HTTPS da Internet e Intranet (nel dominio della rete MEF), e dalla Infranet SPC per le altre Amministrazioni.

Service View Diagram

Figura 9 – Service view diagram NoiPA – Gestione Stipendi

Servizi di front end

L’interfaccia utente di NoiPA – Gestione Stipendi CU è web-based, con supporto multi-browser (Internet Explorer, Mozilla, etc.) ed accessibile secondo la normativa vigente.

Formato dei documenti per la Firma Digitale

I documenti destinati alla firma digitale sono predisposti nel formato PDF/A ossia già compatibili per la successiva conservazione. Il formato XML deve essere utilizzato per tutti i documenti “intelligenti” il cui contenuto deve essere acquisito nei database.

Servizi di Web Enhancing

Lo strato di presentation vede la classificazione del client e di tutti i sistemi che interagiscono per controllare la presentazione dei dati, e che svolgono servizi quali: Web Server, Load, Reverse Proxy, caching devices e Rendition Engine.

Servizi applicativi di Infrastruttura

Tutte le operazioni che comportano una modifica dei dati, delle regole del business etc. devono essere registrate e tracciate in modo non alterabile. Tali dati sono disponibili per la consultazione al solo ruolo di Auditor.

Servizi applicativi di Business

Il modello architetturale descritto costituisce la linea guida per la riprogettazione e lo sviluppo dei servizi offerti da NoiPa-Gestione stipendio che devono essere ridisegnati secondo i paradigmi SOA indicati dal progetto Target (capitolo 5). La strutturazione per componenti è quella che meglio garantisce il grado di flessibilità necessario per adattarsi alle modifiche dei processi operativi/normativi (di business) propri del trattamento del personale.

Servizi ESB e Workflow

Nel Sistema Informativo del MEF sono già presenti alcune importanti componenti infrastrutturali SOA, che sono a supporto delle attività di sviluppo:

• Process server - Per il controllo dei processi di business, per la gestione dei processi di lunga durata e delle HTL (Human Task List).

• Enterprise Service Bus (ESB) - Per ottenere il disaccoppiamento necessario a garantire agilità e flessibilità richiesta dal sistema nel colloquio con gli altri sistemi.

• Registro – il registro/repository dei servizi - Per la pubblicazione e sottoscrizione dei servizi ed il governo delle politiche di utilizzo.

Presso il sistema del MEF sono presenti diversi middleware di integrazione quali strumenti di ETL applicabili qualora si tratti di caricamenti o estrazioni massicce di dati.

Servizi Esterni (Back End)

Servizi presenti nel MEF e quindi disponibili per il riuso:

• Porta di Dominio (PDD).

• Conservazione Sostitutiva.

• Verifica firma.

• Secure Paper (Glifo).

• Flusso dati (per la gestione scambio dati con applicazioni MEF).

3.4.1 Architettura delle componenti software

La figura successiva illustra il dettaglio di funzionamento in termini di componenti software.

Figura 10 – Descrizione componenti software NoiPA – Gestione Stipendi

Il sottosistema di front-end si basa sul framework MVC Struts. È costituito da componenti Java ospitati in ambiente Websphere .

I componenti comunicano scambiandosi oggetti di tipo Messaggio. L’oggetto di tipo Messaggio è rappresentato in XML. L’aver definito un oggetto di tipo Messaggio garantisce i seguenti vantaggi:

• Flessibilità: il dato trasportato all’interno di un messaggio è schematizzato in un file XML. Pertanto future specializzazioni sul dato sono facilmente rappresentabili ed implementabili. Per esempio si possono definire nuovi attributi (come attributi per indicare l’eventuale cifratura di un valore) per modificare il dato nella fase della sua costruzione.

• Mapping: il dato all’interno di un messaggio è una rappresentazione Java il più fedele possibile della struttura dati in input e output delle procedure Cobol;

• Manutenzione: Tutti i messaggi sono censiti in file XML. Pertanto si ha sempre la chiara visione dei dati in input e output tra procedure e servizi;

• Adozione del pattern Data Transfer Object (DTO).

Sebbene il Messaggio sia rappresentabile in XML questo non è serializzato in uno stream XML.

Il sottosistema di back-end è costituito da servizi Cobol ospitati in ambiente Tuxedo e accedibili dal front-end via BEA JOLT Server.

Il sottosistema Database poggia su piattaforma Oracle 11g ed ospita servizi scritti in PL/SQL.

3.4.2 Principali componenti tecnologiche e software

In una visione d’insieme di tutte le componenti del sistema NoiPA-Gestione stipendio è possibile individuare principalmente le seguenti aree:

• componenti “core”;

• componenti “.Net”

• componenti “Dom”

Per tutte le aree logiche si forniscono di seguito alcuni dettagli.

Componenti “core” del sistema

Definiremo come componenti “core” quelle dedicate all’erogazione delle funzionalità utilizzate dagli uffici responsabili per erogare il servizio. Tali componenti costituiscono una parte consistente delle funzionalità dell’applicazione relativa alle Gestioni Stipendiali, come rappresentato nella figura successiva:

Figura 11 – Le componenti core del sistema NoiPA

L’applicazione “Gestioni Stipendiali” è costruita su un sistema multitier a tre livelli. Essa è fruibile da chiunque abbia una connessione Internet, non richiedendo sulle postazioni client alcuna componente se non un browser.

Lo strato di presentation dell’applicazione è basato su programmi java (jsp e servlet); i programmi java (jsp/servlet) che gestiscono l’interazione utente – codice applicativo sono implementati in load balancing dentro 4 istanze (cloni) dell’application server IBM Websphere.

Attraverso il cluster WebSphere, viene effettuata la chiamata alle componenti “di servizio” che costituiscono la logica applicativa tramite il connettore JOLT; tali componenti sono servizi scritti in Cobol/Procobol.

I servizi Cobol/Procobol non sono quindi acceduti direttamente dall’utente, ma sono referenziati dagli application server WebSphere tramite il TP monitor Tuxedo della BEA.

Il middleware che connette il mondo java al mondo Tuxedo è il connettore Jolt della BEA.

Il database è costituito da un’istanza Oracle 11g, della quale si prevede la possibilità di implementazione della modalità RAC.

Componenti “.NET” del sistema

Oltre alle componenti “core” di NoiPA – Gestione Stipendi appena descritte, sono state sviluppate alcune componenti “a corredo” del servizio in architettura “.NET” (DetrazioniNet, SciopNet, AssenzeNet e GudiciNet), fruibili in tutti i periodi dell’anno 5/7gg nella fascia oraria 08:00 – 17:00.

L’architettura di riferimento è il Framework 1.1 di Microsoft .NET, i cui webserver eseguono il reverse proxy sugli application server. Gli application sono deputati a comunicare con il Database Oracle di NoiPA – Gestione Stipendi, per l’aggiornamento dei dati di competenza.

Tutti i dati acquisiti attraverso le quattro applicazioni, sono elaborate mediante procedure batch periodiche che provvedono ad aggiornare la base dati.

Tali servizi rappresentano un importante mezzo di acquisizione delle variazioni da apportare alle competenze fisse degli amministrati.

Componenti “Dom” del sistema

Il servizio di dematerializzazione si occupa delle elaborazioni batch per la trasformazione in formato elettronico dei supporti cartacei di interesse dell’amministrato (cedolini, CUD, 730) e la loro formattazione nel layout previsto per l’Amministrazione cliente.

Si occupa della securizzazione dei cedolini prodotti mediante apposizione di glifo bidimensionale e della loro archiviazione sul sistema e la pubblicazione sul portale NoiPA.

Architettura logica

La soluzione si basa su un’architettura SOA, con l’implementazione di servizi (web- service) che rendono possibile la collaborazione applicativa tra il MEF e diversi interlocutori (Enti aderenti ). Tali servizi consentono di:

• automatizzare, centralizzare e quindi ottimizzare i procedimenti della post- emissione;

• ridurre drasticamente il tempi della post-emissione rispetto all’attuale ;

• adottare un sistema conforme ai principi della cooperazione applicativa definiti dalla normativa del Sistema Pubblico di Cooperazione.

Lo schema seguente, insieme ai diagrammi di sequenza e degli stati, identifica i componenti di cui è costituto il processo di Dematerializzazione della Post-emissione e i paragrafi successivi ne descrivono le funzionalità. Nel processo raffigurato in figura 14 è rappresentata anche la componente "usa e getta" di trasformazione dell'attuale formato depcon ad xml.

Figura 12 – Le componenti del sistema NoiPA

Nella fase iniziale il FrontEnd acquisisce i documenti provenienti da diverse fonti (flusso emissione per NoiPA – Gestione Stipendi, web service per enti aderenti).

Se provenienti dal sistema NoiPA – Gestione Stipendi saranno opportunamente trasformati dall’attuale componente “usa e getta” DEPCONConverter. Se provenienti da sistemi esterni, saranno acquisiti direttamente dal FrontEnd e indicizzati opportunamente dal motore di ricerca per essere successivamente inoltrati allo strato di produzione e stampa.

Le informazioni necessarie al controllo e verifica vengono inviate tramite i servizi REST al sistema di monitoraggio e conservati su un database relazionale.

A seguito del corretto inoltro dei flussi all'appliance di stampa, partirà il flusso di Produzione Artefatti.

Gli artefatti prodotti, coerentemente con il tipo di flusso di appartenenza (cedolini, CU...), saranno securizzati, firmati o entrambi. Gli stati dell’elaborazione del flusso e le data collection saranno visualizzati dalle dashboard presenti sullo strato di monitoraggio e controllo.

A partire dall’acknowledge ricevuto per l’avvenuta produzione dei PDF relativi a uno specifico flusso, ci sarà un salvataggio contestuale dei file pubblicati su filesystem

condiviso, una archiviazione WORM su DB centera e un salvataggio dello stato del flusso sulla componente di monitoraggio (DB relazionale).

La contestuale pubblicazione degli artefatti sul portale NoiPA è lo step finale del flusso.

Front-End

Possiamo dividere la componente di Front-End in due macro processi:

• Il deposito del file fisico

• la ricezione della notifica dell’arrivo del flusso

Il deposito del file fisico è implementato attraverso un Servizio FTP su spazio disco accessibile da utente. Il naming dei file xml da depositare è dato.

Tramite servizio web sarà notificato l’arrivo del flusso attraverso un’interfaccia web definita da campi specifici inerenti il file di origine dati (il sottosistema, l’ente, l’unità organizzativa, la matricola, il tipo documento).

Processi scalati e in parallelo

Per lo sviluppo dei batch implementati sullo strato di front-end della post emissione si utilizza il framework Spring batch (xxxx://xxxxxxxx.xxxxxx.xx/xxxxxx-xxxxx/). La strada intrapresa è quella cosiddetta dello “Step Partitioning”.

In questo caso gli attori sono semplici istanze di Step che possono essere configurate e usate per processi locali. La logica utilizzata è fornire in input una directory contenente più files al processor per eseguire un’operazione sul singolo file.

Il job viene eseguito come sequenza di Step e si indica uno degli Step come Master. Qualunque Step può essere indicato come Master.

Il componente principale (Master) è il cosiddetto PartitionStep il quale è costituito principalmente da due componenti: il Partitioner e il concrete business step (slave). Il Partitioner ha una sola responsabilità: generare esecuzioni come parametri di Input per nuovi step di esecuzione. Il nostro parametro di input è il path di una directory contenente i files da

elaborare. Le operazioni eseguite non richiedono l’apertura del file stesso (ad esempio insert/update di uno stato) e viene creato un contesto contenente i path dei singoli file.

Terminata l’esecuzione del Partitioner il PartitionStep inizia a consumare il contesto istanziando (il numero massimo di istanze è configurabile) per ogni suo elemento (nel nostro caso il path del singolo file) un concrete business step.

Ogni concrete business step viene utilizzato per eseguire operazioni utilizzando dati contenuti nei singoli files, ad esempio conversione del file da DEPCON a xml, estrapolazione di alcuni dati, calcolo dei totali, insert in base dati, oracle o elasticsearch, copia del file in directory diverse, ecc..

Gli slaves sono tipicamente servizi esposti su macchine remote ma possono essere anche threads locali (come nel nostro caso).

Ogni Slave è eseguito una e una sola volta per ogni esecuzione del Job.

Per la compilazione e la gestione delle dipendenze si è deciso di utilizzare Apache maven

(xxxx://xxxxx.xxxxxx.xxx/) che in combinazione a spring platform fornisce uno strumento che facilità molto il versionamento delle singole dipendenze.

Motore di ricerca

Elasticsearch è un enterprise search engine open source sviluppato in Java. L'obiettivo principale di questo genere di motori di ricerca consiste nel garantire il massimo delle prestazioni in ricerca full text e indicizzazione.

Elasticsearch utilizza il linguaggio JSON + RESTful per la rappresentazione dei dati, oltre ad essere un linguaggio di programmazione neutrale, fornisce dati semi- strutturati con entità complesse. E’ un motore di ricerca senza schema quindi è sufficiente immettere un documento scritto in JSON perché questo sia automaticamente indicizzato dal sistema. Attraverso interrogazioni REST è possibile effettuare operazioni di inserimento ed interrogazione su Elasticsearch.

Elasticsearch è composto dai cosiddetti “shard” che rappresentano una singola istanza di worker a basso livello gestiti automaticamente dal software e sono distribuiti su tutti i nodi del cluster e spostati automaticamente da un nodo all’altro nel caso di aggiunta di nodi o di node failure.

Per garantire high availability, Elasticsearch viene installato in modalità cluster. Attraverso il cluster i shards sono replicati per migliorare performance ed availability, se uno shard primario non è disponibile (ad es. un nodo è down), una replica prenderà il suo ruolo di primario. Come riportato nel disegno architetturale, Elasticsearch riceve dati dal Servizio di Front End.

Produzione Artefatti, Securizzazione e Firma digitale

La produzione degli artefatti (XX.XX.XX) avviene tramite appliance LAND. Questa appliance si alimenta attraverso il flusso dati XML prodotto dallo step precedente, lo elabora attraverso trasformazioni XSLT nel formato FOP prima della effettiva trasformazione in PDF.

L’appliance si occupa della parallelizzazione del lavoro su base flusso e gestisce, inoltre, la fase di post-produzione per l’apposizione firma digitale e/o securizzazione con glifi.

L’appliance espone una directory in cui devono essere depositati i file XML di input il cui nome, dovrà iniziare con il nome del sistema emittente e avrà una naming convention descritta nel paragrafo precedente. Il nome dei file XML in input sarà univoco all’interno del sistema emittente.

L’appliance modifica l’estensione dei file in lavorazione, posponendo il suffisso .lock, modifica l’estesione in .done per i file elaborati e in .err per i file la cui elaborazione si è conclusa con errore.

L’appliance espone, inoltre, una directory in cui devono essere depositati i file output in formato zip, contenenti tutti i file di un lotto. La directory di output non conterrà lavorazioni parziali e una volta terminata la lavorazione, modificherà l’estensione dei file zip in .sec.

Le directory di input e output sono condivise tra le varie istanze dell’appliance su un filesystem GPFS.

Attualmente, i template dei file prodotti dall’appliance saranno due e diversi tra loro, uno per i cedolini emessi dal sistema ARES (aziende sanitarie) e uno per il sistema NoiPA – Gestione Stipendi. I font utilizzati sono Helvetica e Helvetica Bold, i quali possono essere embbeded anche parzialmente.

Per i nuovi enti aderenti saranno implementati nuovi template seguendo i requisiti degli enti che aderiscono.

Il file deve essere in formato PDF\A e ha due attributi custom (timestamp _firma e nome_firmatario ).

Pubblicazione

La fase di pubblicazione ha come responsabilità principale l'abilitazione alla visualizzazione o download dei documenti prodotti.

In questa fase l’operatore, può decidere di attivare la pubblicazione per ente ovvero lavorando più finemente decidere della pubblicazione o meno del singolo cedolino.

È possibile definire delle pubblicazioni automatiche su base ente-emissione in base alle regole definite in fase di adesione del nuovo ente. Ad esempio, per le amministrazioni centrali è definito come giorno di pubblicazione il 23 del mese, o il primo giorno lavorativo antecedente tale data, mentre per il comparto sanità è il 27. Per ogni ente possono essere presenti più emissioni nello stesso mese, pertanto deve essere garantita la disponibilità del documento nello stesso giorno di esigibilità dell'importo pagato.

Monitoraggio

Il monitoraggio dei diversi aspetti della procedura di PostEmissione sarà realizzata attraverso interfacce web create sul portale NoiPA ed accessibili solo ad utenti che avranno ruoli amministrativi. Le interfacce web utilizzeranno chiamate REST per la redazione dei diversi report.

I servizi possono essere facilmente integrati in una qualsiasi interfaccia o aggregati attraverso dashboard.

Relativamente le esecuzioni dei batch, nel portale NoiPA, verrà aggiunta una apposita sezione “Monitoraggio Batch”, che consente di visualizzare oltre l’attuale esecuzione, anche lo storico.

L’implementazione è basata sui servizi REST esposti nativamente dalla piattaforma open source Spring Batch Admin.

3.5 Gestione comparto Sanità

NoiPA Sanità è la soluzione realizzata in tecnologia web per la gestione del personale — dipendente e convenzionato — degli enti sanitari (attualmente la Regione Lazio).

Il MEF, attraverso questo sistema, eroga alle Aziende sanitarie un servizio unificato per la gestione del personale e in particolare assicura:

• aggiornamento del sistema in base all’evoluzione normativa per tutti gli aspetti previdenziali, fiscali e contrattuali.

• efficienza di servizio attraverso la gestione centralizzata di processi quali la configurazione, elaborazioni, adempimenti e flussi, gestione di finanziarie ed enti previdenziali.

• i massimi livelli di sicurezza, tecnica e informatica, per tutti i servizi offerti da NoiPA, in termini di modalità di accesso e fruizione di dati e servizi, securizzazione cedolino, tutela del dipendente verso finanziarie, tutela delle informazioni.

• un servizio di assistenza, in orari e modalità standard, a tutte le Aziende sanitarie ed ai loro Amministrati.

Il software NoiPA-Sanità utilizzato è un sistema unico integrato per la gestione del personale delle Amministrazioni Pubbliche aderenti ed è articolato, per le Aziende sanitarie della Regione Lazio, in varie componenti.

NoiPA Sanità combina, all’interno di un contesto di integrazione nativa estesa, i tradizionali aspetti legati all’amministrazione (rilevazione presenze, gestione dello stato giuridico e trattamento economico), con aspetti più innovativi legati alla gestione ed allo sviluppo del capitale umano delle aziende sanitarie e pertanto la soluzione si articola in sistemi applicativi dedicati alle singole specifiche esigenze organizzative e amministrative:

• Sistema per il trattamento economico

• Sistema per il trattamento giuridico

• Sistema per la gestione delle presenze

• Sistema per la gestione del capitale umano

NoiPA Sanità è integrata, mediante web services, con

• OAM (sistema centralizzato di autenticazione e profilazione del sistema NoiPA) per gestire la corretta abilitazione degli utenti;

• Anagrafica Unica (Sistema di Anagrafe Centralizzata del sistema NoiPA):

- per consentire all’ente sanitario di censire un nuovo amministrato inserendo i dati anagrafici che saranno propagati, in modalità asincrona, a NoiPA Sanità, per permettere l’immatricolazione/inquadramento dell’amministrativo;

- per consentire al sistema NoiPa – Gestione anagrafica di ricevere in modalità asincrona le informazioni in merito al periodo lavorativo censito in NoiPA Sanità;

• Portale NoiPA: per la pubblicazione di cedolini securizzati, CU, cartellini e punto di ingresso per altri self service della rilevazione presenze e anagrafica

3.5.1 Architettura concettuale del sistema

La figura seguente schematizza l’architettura concettuale del sistema.

Figura 13 – Architettura sistema Sanità

3.5.2 Architettura software

La figura seguente schematizza l’architettura software del sistema.

L’architettura applicativa del Sistema è quasi totalmente basata su tecnologia open source Java, con una componente cobol Microfocus.

Web Applicativo

E’ la componente che esporta tutte le funzionalità applicative per la gestione del singolo dipendente da parte degli utenti di gestione, in particolare:

• utenti dell’Ufficio del Personale, per la gestione quotidiana delle attività inerenti le risorse umane;

• utenti del personale medico e/o organizzativo, per la gestione dei turni di lavoro.

Web Portale

E’ la componente che esporta tutte le funzionalità applicative di tipo self-service rese disponibili per il singolo dipendente ed accedibili via Portale NoiPA Sanità, ad esempio:

• visualizzazione del proprio cedolino paga;

• visualizzazione del proprio cartellino;

• inserimento di una richiesta di assenza (xxxxx, malattia, ecc.).

Web Services Gateway

E’ la componente che riceve i dati relativi alle timbrature provenienti dalle diverse Aziende amministrate e li registra nel sistema, ad uso delle elaborazioni successive. Batch

E’ la componente che elabora i dati di timbratura e di assenza raccolti nel corso del mese e produce, in modalità batch, i cartellini consolidati ed i cedolini paga. Una volta pronti i dati, tale componente li traduce in formato PDF e li rende disponibili alla componente portale, per la visualizzazione da parte del dipendente accreditato.

RDBMS

La configurazione architetturale del database di produzione prevista nel progetto prevede Oracle RDBMS 11g Enterprise con le feature diagnostic pack, tuning pack, partitioning in configurazione RAC versione 11.2.0.3 a più nodi. Tutti i nodi del RAC sono operativi nel sito di produzione ed insistono su un unico storage esterno.

Figura 14 – configurazione database sistema Sanità

L’architettura prevede l’utilizzo di ASM per la memorizzazione dei datafile.

Spazio documentale

Per poter parallelizzare i calcoli dei cedolini è previsto un disco condiviso su cui memorizzare i programmi e l’output generato dagli stessi; il disco condiviso permette l’esecuzione di un calcolo su un nodo application e il prelievo dell’output da un altro application.

La versione di parallel filesystem utilizzata è ocfs2 (oracle cluster filesystem) versione per cui viene utilizzata una licenza “Oracle Linux support subscription”.

Per l’esecuzione dei programmi cobol è utilizzata la seguente versione:

• ACUCOBOL-GT runtime version 8.1.1;

• Acu4GL ORACLE/OCI file system (interface v8.1.1).

La versione utilizzata è per sistemi operativi linux glibc 64 bit e client oracle 11.

3.6 Gestione degli accessi al Sistema NoiPA

Il processo di autenticazione è gestito dal modulo di Access Management di ORACLE ed è unico tutte le applicazioni/servizi del Portale NoiPA.

Figura 15 – Descrizione componenti IAM

ORACLE FUSION MIDDLEWARE XX X 00X è la piattaforma IAM utilizzata da NoiPA per la gestione degli utenti/ruoli, la gestione delle unità organizzative ed infine la gestione degli accessi.

I prodotti di cui si compone la suite sono stati progettati per gestire in maniera unificata e integrata il ciclo di vita delle identità e fornire in maniera sicura l’accesso alle risorse.

I principali componenti della piattaforma sono :

• Oracle Access Manager - OAM: è il prodotto per la gestione degli accessi e single sign-on, compatibile con i principali standard industriali quali Security Assertion Markup Language (SAML), OAuth e OpenID.

• Oracle Identity Manager - OIM: fornisce servizi di provisioning, self-service, conformità e gestione delle password, nonché riconciliazione e integrazione con altri sistemi di gestione delle identità digitali tramite connettori.

• Oracle Internet Directory - OID: è un directory server certificato LDAP v3; l’archivio dati viene memorizzato in una base dati relazionale (Oracle DBMS).

Il portale NoiPA prevede molteplici modalità di accesso ognuno con un proprio livello di sicurezza:

• autenticazione effettuata mediante la digitazione di userid e password (Autenticazione Debole);

• autenticazione effettuata mediante utilizzo di CNS, necessaria per poter attivare funzioni di aggiornamento/convalida riservate a particolari tipologie di utenti (Autenticazione Forte);

• autenticazione effettuata mediante l’utilizzo di identità SPIDL1, livello sufficiente per l’acceso ai servizi base offerti dal sistema;

• autenticazione effettuata mediante identità federata MEF|MIUR|GdF;

Federated Identity Management (IdF)

L’accordo di servizio è stato stipulato tra le Amministrazioni aderenti a NoiPA per stabilire le modalità e le responsabilità sulla erogazione/fruizione dei servizi secondo un modello federato, indirizzato a garantire piena autonomia sui propri domini applicativi e di rete. La gestione della fiducia tra le Amministrazioni è ottenuta attraverso strumenti crittografici a chiave pubblica (PKI), atti a garantire l'autenticità, l'integrità e la confidenzialità delle transazioni d'identità.

Lo Standard SAML adottato su NoiPA opera in tre passi:

1. Autenticazione – indica che un utente è stato autenticato attraverso password, token hardware, chiave pubblica etc…

2. Autorizzazione – indica che un utente è stato autorizzato o meno ad accedere alle risorse.

3. Attribuzione - indica che l’utente è associato con specifici attributi.

L’Infrastruttura tecnologica offre i servizi secondo il seguente schema:

• una componente di Identity Provider del dominio chiamante e una componente Service Provider del dominio chiamato.

• SAML invia le credenziali dal dominio chiamante al dominio MEF con modalità firmate e criptate.

Si riporta a titolo esemplificativo lo schema adottato nell’accordo di servizio tra il MEF e il MIUR (Ministero dell’Istruzione, dell’Università e della Ricerca).

Figura 16 – Descrizione processo di Identità Federata MIUR/MEF

I vantaggi ottenuti dal MEF con l’adozione dell’ IdF ha consentito di:

• semplificare il processo autorizzativo all’accesso;

• estendere a una maggiore platea di utenti la fruibilità dei servizi;

• demandare la responsabilità di profilazione degli utenti al dominio chiamante;

• mantenere il controllo sulle politiche di accesso ai propri servizi;

• ottenere vantaggi per gli utenti finali nel mantenere univoco l’identificativo di accesso e nel facilitare l’utilizzo dei servizi offerti.

Gli utenti sono profilati, autorizzati e autenticati direttamente sul sistema del MIUR. Il MEF traccia gli accessi registrando i profili degli utenti MIUR inviati al sistema NoiPA

– Gestione Stipendi attraverso SAML al dominio MEF. Tali profili sono codificati dal MEF per essere riconosciuti come profili utente NoiPA – Gestione Stipendi. L’IdF e l’accordo di servizio consentono al MEF di non gestire le anagrafiche degli utenti MIUR. L’accesso a NoiPA – Gestione Stipendi da parte degli utenti MIUR, infatti, è esclusivamente basato sui ruoli descritti nell’asserzione SAML inviata da MIUR.

Access Manager Applicativo: le applicazioni .NET

La gestione degli accessi nelle Xxxxxxxxxxxx.xxx viene realizzata con una soluzione applicativa che garantisce un livello di sicurezza minimale; le applicazioni non permettono l’aggiornamento diretto della base dati NoiPA – Gestione Stipendi ma creano dei files con le variazioni da apportare che, dopo validazione applicativa, vengono elaborati via batch. Le funzionalità per la gestione delle utenze, sviluppate con il medesimo framework applicativo delle xxxxxxxxxxxx.xxx, sono raggruppate in

un servizio applicativo denominato “Gestioneutenti” per la creazione, modifica cancellazione delle utenze e gestione della password.

Autorizzazione e controllo dell’accesso in cooperazione applicativa (PDD) La sicurezza degli accessi in “cooperazione applicativa” è garantita da una serie di accorgimenti tesi al riconoscimento dell’identità delle Porte di Dominio (PDD Delegata e PDD Applicativa) e di un sistema di Firewall XML, posto logicamente davanti alla Porta di Dominio (PDD) sia nell’ambiente di esercizio che in quello di collaudo in modo da filtrare le buste e-gov in ingresso verso la PDD applicativa e di proteggere la PDD delegata dalle risposte malevole che possono provenire dai web services remoti che sono stati chiamati.

Il traffico in transito, da e per il Firewall XML, è stato separato logicamente per distinguere anche sulla rete ciò che è relativo alla PDD Collaudo da quello relativo alla PDD di Esercizio.

Per le caratteristiche tecniche del sistema Firewall XML sono stati quindi utilizzati 4 diversi indirizzi I.P. due indirizzi per ciascuna PDD (Collaudo ed Esercizio). Sul primo indirizzo il Firewall XML è in ascolto indipendentemente da chi lo sta chiamando (PDD delegata del MEF o PDD delegata di un’Amministrazione esterna) e usa il secondo indirizzo per inviare i messaggi indipendentemente dal destinatario (PDD applicativa del MEF o PDD applicativa di un’Amministrazione esterna).

La cooperazione presente in NoiPA – Gestione Stipendi consiste nella richiesta di servizio nella modalità di transazione: i servizi sono esposti, nel momento in cui sono richiamati si determina una variazione nella base dati del sistema NoiPA – Gestione Stipendi e la successiva elaborazione della richiesta con specifiche procedure.

3.7 Spring

Spring, sistema di rilevazione presenze/assenze per il solo personale del MEF, ha le medesime caratteristiche tecnologiche già descritte nel precedente paragrafo per il sistema NoiPA Gestione presenze assenze. NoiPA Gestione presenze assenze nasce infatti come evoluzione funzionale del sistema Spring per rendere disponibili parametricamente le funzionalità a più Enti, consentendo configurazioni specifiche secondo le modalità organizzative/operative di ciascuna Amministrazione.

L’interfacciamento di Spring non avviene attraverso il portale NoiPA, ma l’applicazione è raggiungibile o attraverso la Intranet del MEF o anche direttamente attraverso URL, essendo l’applicazione esposta in Internet.

Nell’ambito del monitoraggio svolto dal servizio di Assistenza Spring sul corretto funzionamento dei lettori/orologio per l’acquisizione e il trasferimento delle

timbrature a Spring,, vengono utilizzati i prodotti Solari TermTalk (ver 3.21.1.0 e 3.22.0.2) e Check&In (ver. 1.9.1.0)

3.8 Siap

Il Siap (Sistema Infomativo per l’Amministrazione del personale) si basa essenzialmente sul pacchetto di mercato Oracle HR E-Business Suite 11.5.10. Il pacchetto nel corso degli anni ha subito molteplici ‘personalizzazioni’ per adattarlo alle esigenze di implementazione dei processi amministrativi informatizzati espresse dall’Amministrazione.

L'architettura logica/applicativa del sistema SIAP è del tipo Client/Server a più livelli basato su tecnologia web.

I componenti dell’architettura sono:

• Un Web browser installato presso le postazioni utente, assieme al “java runtime environment” (jre, utlizzato per l’accesso via Intranet all’applicazione;

• Web Application Server centrale, presso il Centro Elaborazione Dati di Carucci;

• Server dati centrale, presso il Centro Elaborazione Dati di Carucci

Client

Sul client risiede l’applicazione che costituisce l'interfaccia grafica alle funzionalità del sistema SIAP/SPRING.

Il client utilizza:

• un web browser (Internet Explorer) per accedere all’applicazione;

• Java jre v. 1.6.0.27 o superiori;

• applet Java che forniscono l’interfaccia utente per il motore runtime dell’applicazione;

• eventuali pagine HTML per la visualizzazione di ulteriori interfacce utente.

Web Application Server centrale

Sul Web Server centrale risiedono i prodotti/servizi che consentono la connessione e l’autenticazione degli utenti all’applicazione:

• Oracle WebLogic ver. 10.3.5;

• Oracle Portal Server 3.0.9.8;

• Listener HTTP Apache ver. 1.3.19 per la connessione al prodotto WEBHR (Human Resource delle Oracle Application ver. 11.5.10.2);

• Listener HTTP Apache ver. 1.3.19 per la connessione al prodotto WEBABM (delle Oracle Application ver. 11.5.10.2);

• Listener HTTP Apache ver. 1.3.19 per la connessione al prodotto WEBOGL (delle Oracle Application ver. 11.5.10.2);

• APPLHR (Oracle Application) ver. 11.5.10.2 ed i relativi Oracle Forms Server 6i ed Oracle Report Server (patchset 17 (Forms 6.0.8.28.0, Report 10.1.2.0.2);

• APPLABM (Oracle Application) ver. 11.5.10.2 ed i relativi Oracle Forms Server 6i ed Oracle Report Server (patchset 17 (Forms 6.0.8.28.0, Report 10.1.2.0.2);

• APPLOGL (Oracle Application) ver. 11.5.10.2 ed i relativi Oracle Forms Server 6i ed Oracle Report Server (patchset 17 (Forms 6.0.8.28.0, Report 10.1.2.0.2);

• I prodotti HP Suite Openview.

Server Dati

Sul server dati risiede l’RDMS di riferimento:

• Oracle 11g ver. 11.2.0.4.0 – 64bit.

4. AMBIENTI OPERATIVI ATTUALI

4.1 Ambiente di Esercizio

L'ambiente di esercizio del sistema NoiPA è, in base alla configurazione esistente ad oggi (pertanto suscettibile di eventuali modifiche/aggiornamenti) composto da:

• Un bilanciatore in configurazione Hot Standby e l'algoritmo di bilanciamento è di tipo Round Xxxxx;

• Una Farm di 4 server Web Apache: “IBM_HTTP_Server/6.1 Apache/2.0.47” su RedHat ES 5.9 a 64 bit e plugin WebSphere versione 6.1.0.27 per il bilanciamento verso la Farm Application.

• Una Farm di 4 server WebSphere 6.1 su piattaforma RedHat ES 5.9 a 64 bit.

• Un Application server su piattaforma AIX 5.3 TL 11 su cui sono in esecuzione i seguenti prodotti software:

1. TPMonitor Tuxedo versione 10.3.0.0

2. Oracle client 10.2.0.4

3. Microfocus COBOL Run time versione 4.0.00-e SP3 Fixpack 40.03_85

4. Java JVM versione 1.5.0

L'application server è funzionale sia all'applicazione online che alle elaborazioni batch. Le elaborazioni batch sono scritte parte in cobol e parte in java.

Per quanto concerne l'applicazione online la comunicazione fra l'ambiente java WebSphere e i server cobol veicolati dal TPMonitor Tuxedo avviene tramite il componente JOLT.

Un server AIX 6.1 TL 11 con Oracle RDBMS versione 11.2.

Un server FTP RedHat ES 5.9 a 64 bit per le esigenze di upload di files per la parte di applicazione che ne necessita.

Un appliance IBM DataPower per la parte di applicazione che necessita di parsing XML e di XML Transformation.

Una coppia di appliance HSM per la parte di applicazione che necessita di firma digitale.

Un sottosistema per l'apposizione di grafici bidimensionali.

I server AIX sono rappresentati da partizioni LPAR su server IBM Pseries.

I vari ambienti: WEB, Application, Database sono su sottoreti separate e protette tramite Firewall.

Il DataBase di esercizio occupa circa 1 TByte di spazio disco. Il sottosistema di storage è rappresentato da una SAN EMC2.

L'intero ambiente di esercizio è sottoposto a specifiche politiche di backup.

4.2 Ambiente di Collaudo

È una copia in scala dell’ambiente di esercizio.

La parte application AIX e la parte DB RDBMS Oracle sono ospitate su partizioni LPAR su sever IBM Pseries.

Tutti gli altri componenti software sono ospitati su server virtuali VmWare.

Gli ambienti ripropongono le medesime configurazioni degli ambienti di esercizio anche in termini di versione dei prodotti software.

4.3 Ambiente di Manutenzione

L’ambiente di sviluppo/manutenzione, è una copia in scala dell’ambiente di esercizio; si tratta dell’ambiente sul quale si richiede al Fornitore di effettuare tutte le operazioni connesse al rilascio del software.

La LAN eventualmente messa a disposizione del fornitore è una LAN separata.

4.4 Ambiente di Precollaudo

Un ulteriore ambiente, definito di precollaudo, è a disposizione del fornitore per predisporre i collaudi quando il DB di collaudo è impegnato per altre attività.

Anche questo ambiente è una versione in scala dell'ambiente di esercizio.

4.5 Connessioni in Rete

Gli uffici del personale del MEF, dislocati presso:

• le Direzioni Territoriali dell’Economia e delle Finanze (DTEF) siti in tutte le regioni d’Italia;

• gli uffici di xxx XX Xxxxxxxxx x xxx Xxxxxxxx x Xxxx;

• gli Uffici Centrali del Bilancio siti presso le Amministrazioni Centrali;

• la Corte dei Conti.

sono connessi al sistema NoiPA – Gestione Stipendi tramite la rete intranet del MEF. Le altre Amministrazioni dello Stato sono connesse al sistema NoiPA tramite rete Internet.

Il browser client comunica con il web server mediante l’utilizzo dei protocolli HTTP e HTTPS e tutte le informazioni sensibili in transito tra Client e sottosistema serventi sono cifrate.

5. EVOLUZIONE DEL SISTEMA NOIPA (CLOUDIFY NOIPA) - ARCHITETTURA

L’attuale architettura del sistema NoiPA presenta limiti significativi in termini di rigidità, obsolescenza e scarsa integrazione dei diversi moduli di servizio sviluppati nel corso del tempo

L’attuale modello architetturale e di service offering sembra non più adeguato a sostenere una evoluzione della domanda sia in termini di estensione dei servizi offerti ai Clienti attuali, che di aumento della base Clienti

A tale proposito il MEF ha varato il progetto Cloudify NoiPA per l’evoluzione e re- ingegnerizzazione dell’intero sistema NoiPA attraverso il quale si vogliono perseguire importanti obiettivi di miglioramento in termini di efficienza, efficacia ed economicità dei servizi offerti finalizzati all’ampliamento del parco di Amministrazioni aderenti.

5.1 Il progetto Cloudify NoiPa

La piattaforma Cloudify NoiPA erogherà servizi applicativi per gli utenti finali e garantirà la governance centralizzata per l’Accounting, il Provisioning, lo User Profiling e il Monitoring dei servizi disponibili a catalogo, secondo il paradigma del Cloud Computing.

Il disegno della piattaforma, riportata in figura 1 , prevede una architettura applicativa modulare basata su container, con componenti indipendenti ed integrabili.

Figura 1 – Architecture vision

E’ oggetto di questo paragrafo la progettazione dell’architettura applicativa atta a erogare i servizi per gli utenti finali e l’integrazione con sistemi esterni esposti dal layer Software as a Service. I servizi sono abilitati dalle soluzioni applicative presenti nel layer Platform as a Service.

5.1.1 Architettura applicativa

Le soluzioni identificate che realizzano l’architettura applicativa sono le seguenti:

• Single Page Application: lo strato di presentation della piattaforma Cloudify NoiPA sarà organizzato in web application composte da una singola pagina HTML che si aggiorna dinamicamente senza effettuare il classico reload della pagina stessa, utilizzando servizi remoti (web services) richiamaclient javascript.

• API Manager: layer di integrazione per l’accesso ai microservizi della piattaforma NoiPA, le richieste provenienti dalle SPA ed i sistemi esterni saranno gestite dall’API Manager per esigenze di routing/composizione dei servizi e sicurezza;

• BPM: componente per la gestione dei processi di business complessi e long- running modellati utilizzando le logiche elaborative implementate nei microservizi e le regole definite nel rule engine;

• Rule Engine: componente per la gestione delle logiche di business che potranno essere scorporandole dal codice e rappresentate con delle regole;

• Microservizi: componente applicativa autonoma e indipendente che implementa i requisiti di business e comunica con meccanismi basati sul protocollo HTTP;

• DaaS: strato applicativo per la gestione della persistenza e all’accesso ai dati mediante strumenti di Master Data Management e di data virtualization.

Figura 2 - Architettura applicativa (vista logica)

I diversi strati applicativi si integreranno mediante protocolli standard e sicuri, abilitati dalle tecnologie adottate così come riportato di seguito.

AngularJS

Bootstrap

RH Web Server

Single Page Application

https (rest)

Service security

Service discovery

Service decomposition

http

BPM

Micro Servizi

Jboss BPM

http

Async Processing

Anagrafica

Time Mgm

Jboss EAP

Jboss AMQ

stomp/http

Spring Boot

Spring Security Spring Data Jboss EAP

Rule Engine

Jboss EAP

tcp

Jboss BRMS

Jboss EAP

Sqlnet/http

Data Virtualization

RED HAT DATA VIRTUALIZATION

Data abstraction

Data caching

Data security

Sqlnet/http

Sqlnet

Master Data

Database Operazionali

Sqlnet

API Gateway

3SCALE

Oracle

Informatica

Figura 3 - tecnologie e protocolli

La piattaforma Cloudify NoiPA viene realizzata in ottica cloud con caratteristiche per:

• Elaborazioni intensive - funzionalità con necessità di risorse computazionale/dati significative;

• Multitenancy applicativa - le componenti applicative implementano una multi-tenancy per Ente;

• Multitenancy dati - livello di isolamento della componente dati;

• Multitenancy infrastrutturale - livello di isolamento delle componenti architetturali indipendente dalla tenancy applicativa.

5.1.1.1 PRESENTATION LAYER

NoiPA Cloudify espone alcune funzionalità in modalità foreground ovvero usufruibili dall’utente fisico mediante le interfacce grafiche messe a disposizione dalle applicazioni stesse. Per questo strato applicativo si è scelto di utilizzare il modello Single Page Application (SPA).

5.1.1.1.1Single Page Application

Con il termine Single Page Application si intende un'applicazione web che può essere usata o consultata su una singola pagina web con l'obiettivo di fornire una esperienza utente più fluida.

Una SPA è composta da una pagina HTML che scarica i file JavaScript necessari all'applicazione. La pagina HTML contiene un tag (tipicamente un div) che diventa il contenitore dell'intera applicazione. A questo punto entra in azione il codice JavaScript che scarica dal server un frammento di HTML corrispondente alla home page della nostra SPA.

Oltre al frammento HTML, viene scaricato anche il file JavaScript responsabile dell'interazione con la home page. A questo punto il frammento di HTML viene inserito nel div che agisce come contenitore quindi all'utente viene mostrata la home page (ovviamente il frammento di HTML scaricato non è un'intera pagina ma solo la parte visuale dell'HTML).

Nel momento in cui l'utente naviga verso un'altra pagina, la navigazione viene intercettata dal JavaScript che si occupa di recuperare il frammento di HTML e il codice JavaScript della pagina a cui l'utente vuole accedere. Successivamente, il codice HTML contenuto nel frammento scaricato viene inserito all'interno del div contenitore rimpiazzando quello della home page. Essendo questa navigazione interamente gestita da codice JavaScript, la pagina sul browser non viene mai completamente ricaricata.

Figura 4 -Approccio Tradizionale Vs Single Page Application

Nell’immagine viene mostrato come nel caso di un approccio tradizionale un’applicazione ha la necessità di ricaricare la pagina con il codice HTML elaborato. Nel caso dell’applicazione che verrà presentata non sarà necessario ricaricare la pagina ma mediante delle funzionalità JavaScript sarà sostituito il codice HTML interno al div contenitore con il nuovo codice HTML.

5.1.1.1.2Angular

AngularJs è uno dei framework che supporteranno la nostra architettura nell’implementazione della Single Page Application.

In particolare AngularJS è un framework client-side MVC/MVVM totalmente estendibile che non necessita di altre librerie e si integra perfettamente anche con altri framework. La scelta di questo framework è data dalla facilità con la quale Angular si adatta alle esigenze di progetto per la realizzazione e la modifica di ogni funzionalità.

Angular permette di utilizzare HTML come template e di estendere il vocabolario HTML, in modo tale da poter dichiarare componenti applicativi ad hoc in maniera concisa e chiara. Inoltre, fornisce notevoli vantaggi per l’organizzazione del codice JavaScript ed utilizza a pieno i vantaggi del pattern di design Dependency injection (DI) e l'inversion of control (IoC).

Il principale obiettivo di questo framework strutturale è di aumentare la capacità MVC (Model View Controller) delle applicazioni web.

Il pattern architetturale MVVM è un approccio sviluppato al fine di tenere separati il livello logico e l’interfaccia utente. In questo modo, seguendo il pattern MVVM rende indipendenti i due livelli, se in futuro dovesse essere necessario cambiare il “Model”, l’applicazione continuerà a funzionare senza problemi.

I tre componenti dell’applicazione Web sviluppata con l’approccio MVVM sono quindi:

• Model

• View

• ViewModel

Separati in modo da evitare di combinare il codice che gestisce la logica da quello che gestisce l’interfaccia ottenendo in questo modo un basso accoppiamento tra i singoli layer.

Il principio del funzionamento di questo pattern è la definizione di un componente che rappresenta tutte le informazioni ed i comportamenti della vista corrispondente.

Secondo questo pattern, la View implementata mediante Angular non farà altro che presentare quello che il ViewModel espone e passare a quest’ultimo eventuali cambi di stato. Il viewmodel conterrà delle viste Java implementate mediante l’utilizzo delle annotation @JSONView del framework Xxxxxxx.

Il flusso di funzionamento è rappresentato dal seguente grafico:

Figura 5 – Pattern MVVM

Quindi l’utente interagisce con la View, quest’ultima è connessa al ViewModel che a sua volta aggiorna il model. A questo punto il model comunica il nuovo stato al ViewModel che verrà poi riflesso dalla View.

Una cosa importante è che il componente View Model oltre a conservare le informazioni ricevute dal model, mantiene anche lo stato attuale di visualizzazione riuscendo quindi a “sganciarsi” completamente dalla View.

I principali vantaggi della scelta di questo pattern architetturale sono:

• Facilità di manutenzione vista la distinzione dei tre componenti

• Semplicità nella fase di testing e in particolare test di unità

• Possibilità di lavorare sul design senza preoccuparsi di altro (il designer non deve avere conoscenze particolari riguardo la logica di business)

5.1.1.1.3Bootstrap

NoiPA Cloudify farà uso del framework Bootstrap per rendere web responsive la fruizione delle funzionalità di front-end. Si parla di responsiveness e più in particolare di Responsive Web Design quando lo stile CSS utilizzato nell’applicazione è pensato e sviluppato per rendere il contenuto della pagina Web fruibile e utilizzabile a prescindere dalle dimensioni dello schermo del dispositivo su cui gira, sia esso un pc, un notebook, uno smartphone o un tablet.

La scelta di utilizzo di questo framework per la realizzazione del sistema NoiPa Cloudify è dovuta a:

• La sua caratteristica principale di essere compatibile praticamente con tutti i browser più aggiornati e di facilitare allo sviluppatore front end il compito di scrivere codice che si adatti ad ogni tipo di dispositivo.

• Bootstrap fornisce una vera e propria struttura, organizzata in elementi e funzioni per il web design, che risulta essere semplice da calare all’interno di tutti quasi tutti i contesti applicativi e funzionali.

Un Applicazione Web che si pone l’obiettivo di essere responsive, deve rispettare alcuni princìpi cardine:

• utilizzare elementi che non hanno dimensioni fissate da pixel o point ma preferire utilizzare unità percentuali che calcolano la loro dimensione in base a quella dello schermo;

• utilizzare le Media Queries che consentono alla pagina di utilizzare diverse regole CSS in base alle caratteristiche del dispositivo, che in generale coincide con la dimensione dello schermo;

• nascondere gli elementi non essenziali nei dispositivi dotati di schermo piccolo;

• adattare le dimensioni delle immagini in modo da evitare la visualizzazione delle stesse fuori dal loro elemento contenitore.

Figura 6 - Responsive Web Design

5.1.1.2 API MANAGER

L’API manager costituisce l’entry point per l’acceso ai servizi della piattaforma e costituisce un layer di disaccoppiamento tra i microservizi ed i consumer (SPA e sistemi esterni) con logiche di composizione, routing e sicurezza. Presenta le seguenti caratteristiche:

- Formato dei dati: supporto per JSON o XML in base alla specificità dei consumer, per le SPA è previsto il formato JSON;

- Organizzazione delle interfacce: sono previsti metodi specifici che implementano specifiche logiche di business evitando metodi general purpose;

- Modello dei dati: la struttura dei dati sarà la stessa esposta dai microservizi a meno di esigenze specifiche di message transformation;

- Sicurezza: l’accesso ai servizi sarà regolato dalle policy di autenticazione e autorizzazione ereditate dalla piattaforma utilizzando il portocollo OAUTH v2;

- Logging: tracciatura delle chiamate ai servizi per l’analisi e l’audit sul loro uso.

Risorse

Microservizi

API Manager

Sicurezza Interfaccie Trasformazione Dati

Logging

Presentation

External System

Single Page Application

Figura 7 - API Layer

5.1.1.3 APPLICATION LAYER

5.1.1.3.1Model View Layer

Con il termine View Model Xxxxx si intende lo strato di logica di back-end e di recupero del dato che verrà fornito successivamente alla componente di front-end per essere elaborato. Per la realizzazione di questo layer si è scelto di utilizzare una struttura applicativa formata da microservices mediante SpringBoot.

5.1.1.3.2Microservices

I microservices rappresentano l’evoluzione delle architetture con approccio SOA (Service Oriented Architecture), ovvero come suggerisce il nome, orientata ai servizi. Si è scelto l’utilizzo di questo pattern architetturale perché punta ad ovviare alle limitazioni imposte dalle applicazioni monolitiche. Infatti, l’obiettivo è quello di creare un applicazione per la quale sia quanto più semplice la sua manutenzione e la sua evoluzione.

Figura 8 - Architettura Monolitica Vs Architettura Microservices

Il vero vantaggio dell’implementazione dei microservices si avrà nell’ottica del Cloudify, ovvero, quando si prenderà in considerazione l’intero parco applicativo, e verranno messi in comune diversi servizi, rendendo più semplice e meno ridondante il lavoro di manutenzione. In questo modo, si avrà la possibilità di comporre le applicazioni di più servizi già esistenti, funzionanti, testati e già disponibili nei vari

ambienti. Nel momento in cui uno degli N servizi viene aggiornato, la modifica è recepita da ogni applicazione che ne fa uso. L’architettura a microservices è orientata allo sviluppo di componenti di base, in modo tale da riutilizzare quante più funzionalità possibili ed evitare uno spreco di sforzi, realizzando applicazioni web con diversi livelli di presentazione ma con gli stessi (o simili) servizi lato back end.

La scelta di utilizzo di spring boot è dovuta agli strumenti che fornisce per la realizzazione e per il supporto di microservices ed inoltre, perché sfrutta a pieno in maniera più consistente e semplice tutto il potenziale delle librerie Spring. Per la realizzazione, i microservices utilizzano il protocollo RESTful (Representational State Transfer), mentre per lo scambio di dati con il front-end si preferisce l’utilizzo dello standard JSON (JavaScript Object Notation).

Utilizzando Spring Boot, è possibile creare applicazioni indipendenti in formato JAR, complete di un server Tomcat, Undertow o Jetty embedded. Non c’è necessità di impiegare file WAR, anche se resta ancora disponibile la funzionalità per compilare file tradizionali in formato WAR.

5.1.1.3.3Integration

Lo strato di Integration racchiude alcuni strumenti esterni che saranno utilizzati ai fini dell’elaborazione dei dati da inviare allo strato di front-end.

5.1.1.3.4ActiveMQ

ActiveMQ è un message-oriented middleware (detto anche broker di messaggistica) open source scritto in Java che dispone di un client per Java Message Service (JMS). Un broker è la parte di soluzione JMS lato server che si occupa di routing, recovery e persistenza. Per quest’ultimo aspetto, il provider JMS memorizza i messaggi su un persistent storage, in modo tale che sopravvivano a un riavvio del broker.

Figura 9 - ActiveMQ

Inoltre, saranno utilizzate le API Java Message Service che consentono lo scambio di messaggi tra applicazioni Java distribuite sulla rete.

Con il termine messaging ci si riferisce ad un meccanismo che consente la comunicazione asincrona tra client remoti:

• Un client invia un messaggio ad un ricevente (o ad un gruppo di riceventi)

• Il destinatario riceve il messaggio ed esegue le operazioni corrispondenti, in un secondo momento

E’ basato su paradigma peer-to-peer: un client può ricevere e spedire messaggi a qualsiasi altro client attraverso un provider:

Ciascun client si connette all’agente (gestore) della messaggistica che fornisce gli strumenti per creare, spedire, ricevere e leggere messaggi.

Questi strumenti permettono di avere una comunicazione distribuita del tipo loosely coupled (debolmente accoppiata) cioè il mittente ed il ricevente, per comunicare, non dovranno essere disponibili allo stesso tempo. Inoltre, grazie all’intermediazione del messaging agent (o server) i client che inviano/ricevono messaggi non hanno bisogno di avere conoscenza reciproca delle caratteristiche dell’altro per poter

comunicare, tutto ciò che il mittente ed il ricevente devono conoscere è il formato (message format) e la destinazione (destination) del messaggio.

5.1.1.3.4.1 Rule Engine

Un sistema BRMS (Business Rule Management System) fornisce i criteri organizzativi e le decisioni operative associate a tali criteri, da definire, distribuire, monitorare e gestire separatamente dalle applicazioni cruciali. L’introduzione di questo strumento permetterà di definire e modificare esternamente alcune regole delle diverse funzionalità senza dover modificare necessariamente l’applicazione o dover interrompere l’esecuzione della stessa.

Le soluzioni BRMS automatizzano i criteri in applicazioni di business composite e personalizzate. Queste soluzioni riducono i costi di gestione delle applicazioni, semplificano l’implementazione di criteri di business più coerenti e precisi all’interno delle applicazioni.

L’utilizzo di un Rule Engine è consigliato nei seguenti casi:

• Modifiche frequenti dei sistemi di business che richiedono risposte e attenzione immediate.

• Decisioni estremamente variabili che richiedono l’automazione per supportare il modello di business aziendale e le offerte di prodotti/servizi.

Figura 10 - Rule Engine

5.1.1.3.4.2 Logging

NoiPA Cloudify si avvale della libreria Log4j per la gestione dei Log. La libreria permette di configurare le informazioni che si vuole visualizzare nei log, mediante un pattern specifico; di seguito si riporta la struttura dei log presenti sull’applicazione:

La seguente tabella riporta i livelli di log previsti.

PARAMETRO

CONFIGURAZIONE SULLA AP LI

Livelli di log previsti

• Debug

• Info

• Error

NoiPA Cloudify, tramite log, persiste su file tutte le transazioni che avvengono verso di esso, e nel caso in cui una di queste va in errore, sul file di error.log, viene lasciata traccia dell’intero trace di errore.

Per ognuno degli appender sono state definite le seguenti proprietà, interamente configurabili:

• file: proprietà che definisce il path dove viene salvato il file di log;

• Append: proprietà che indica se concatenare o meno i log istanziati;

• MaxFileSize: definisce la massima grandezza del file di log (impostato a 5000KB);

• MaxBackupIndex: indica il massimo numero di file da creare dopo il raggiungimento della massima grandezza (impostato a 20);

• Encoding: indica l’encoding dei file di log creati (impostato ISO-8859-1);

• ConversionPattern: definisce il formato delle righe di log che formano i file (impostato “%d{dd-MMM-yyyy HH:mm:ss}:%-5p:logSSS:%t: %m%n”).

NoiPA Cloudify, come default, avrà le impostazioni sopra elencate ad eccezione della proprietà “file”, la quale dovrà essere impostata per definire il path preciso dei log.

Sotto, viene riportato una sezione del file di properties log4j.xml.

</layout>

</appender>

5.1.1.3.5Business Process Manager

L’obiettivo del sistema di Business Process Management è la gestione del ciclo di vita di un processo complesso o long-running, composto da task di sistema o da un’azione dell’utente e attivabile mediante API.

I task di sistema operano con microservizi e rule engine per l’esecuzione automatica di logiche e regole di business, utilizzando il protocollo di comunicazione http. I task utente sono assegnati a gruppi o persone e saranno presentati all’interno delle SPA, in una todo list dedicata, agli utenti responsabile dell’attività.

Figura 11 - Architettura di un BPMs

La definizione di un processo di business con uno strumento di BPM è un approccio dichiarativo, viene rappresentata la definizione, la struttura e la sequenza di task ma non contiene l’implementazione del task i quali vengono elaborati da microservizi, dalle regole definite nel Rule Engine oppure da azioni dell’utente in caso di human task. I processi restano in attesa dell’esecuzione del task, in un stato “dormiente” e il motore del bpm ne memorizza lo stato.

Utilizzando un approccio alla definizione di sotto processi modulari potrà garantire maggiore flessibilità e velocità di modellazione.

Figura 12 - modellazione sotto processi

5.1.1.4 DATA LAYER

Il Data Layer rappresenta lo strato applicativo incaricato della persistenza dei dati. In questo strato sono posizionati i tool di Master Data Management per la gestione centralizzata delle entità fondamentali, il database relazionale e uno strumento di data virtualization utilizzato dai microservizi per l’acceso ai dati utilizzando API esposti tramite web services e direttamente con tecnologia JDBC.

5.1.2 Build

Per la fase di building sarà fornito un pacchetto Maven contenente tutti gli oggetti software afferenti alla release.

5.1.3 Sonar

Sarà effettuata un’analisi statica del codice mediante l’uso di Sonar per evidenziare eventuali vulnerabilità di sicurezza e di violazione di buone pratiche di programmazione.

5.2 Architettura del Portale Cloudify

Il piano di realizzazione del portale prevede una transizione progressiva della componente dal sistema legacy al sistema Cloudify

Durante la vita del progetto e l’entrata di nuovi componenti, tali architetture potranno essere modificate in funzione delle esigenze tecnologiche/funzionali sorte.

L’architettura descritta rappresenta discostamenti dall’architettura definita per il progetto Cloudify Noipa per la mancanza dei componenti di sicurezza Oracle IDCS ed Oracle CloudGate previsti per Settembre 2020

Architettura logica

Il Portale Internet dell’ Area Privata, si basa su un sistema suddiviso tra cinque ambienti di esecuzione:

o Attuale sistema NoiPA ( di seguito legacy)

o IAAS Cloudify NoiPA (di seguito iaas)

o PAAS Cloudify NoiPa ( di seguito paas)

o EIM

o Liferay 7.0 ( di seguito portale pubblico)

5.2.1 Ambiente di esecuzione Portale Pubblico

Rappresenta il portale pubblico di NoiPA. Deve essere raggiungibile dall’ambiente Cloudify poiché, tramite API native di Liferay esposte tramite REST, recupera i contenuti da visualizzare nelll’area privata. I contenuti saranno pubblicati tramite il sistema redazionale di Liferay e fruiti dalle SPA. I contenuti non contengono dati sensibili e non potranno essere utente/specifico. Saranno informazioni generali sul sistema o news da indirizzare agli utenti registrati.

5.2.2 Ambiente di esecuzione IAAS

In questo ambiente vengono collocati gli HttpServer dedicati all’accesso da intranet con a bordo il componente WebGate per l’interfacciamento con il sistema di autenticazione OAM.

5.2.3 Ambiente di esecuzione Cloudify

Rappresenta l’ambiente in cui verranno eseguiti i processi di business del portale privato. E’ realizzato mediante Container RedHat Openshift su sistema infrastrutturale RedHat OpenStack. L’ambiente conterrà il layer di dsaccoppiamento mediante API Gateway, edi layer di business mediante Microservizi

I pods previsti in questa fase risultano essere:

LAYER	MIDDLEWARE CONTAINERIZZATO
API Gateway	3Scale
Microservices	JBoss EAP 7.0
Logging	EFK

5.2.4 Ambiente di esecuzione Legacy

Rappresenta l’ambiente attuale del portale privato di NoiPA. Deve essere raggiungibile dall’amiente Cloudify poiché è prevista una navigazione Web lato utente tra i due portali. In pratica l’utente potrà navigare da un portale all’altro tramite weblik. I due portali devono essere sotto SSO OAM poiché per la navigazione non verrà richiesta nuova autenticazione.

5.2.5 Ambiente di esecuzione EIM

Rappresenta l’ambiente di esecuzione dell’EIM di Cloudify Noipa per il sitema di Business Intelligence. Dovrè essere raggiungibile al sistema Legacy per il recupero di informazioni di BI e fornirà i dati, tramite web, all’ambiente Cloudify per la presentazione sul portale privato di dati, grafici, indicatori, etc.

I nuovi servizi risiederanno nella nuova infrastruttura Cloudify / IAAS, mentre i vecchi servizi fino a che non saranno migrati saranno raggiungibili mediante il portale privato NoiPA su Liferay attraverso l’infrastruttura Legacy.

Mediante opportuna configurazione dell’infrastruttura, è previsto che la radice del dominio risponda al nuovo portale area pubblica, che il vecchio path dell’area privata resti invariato e che per la nuova area privata venga utilizzato un nuovo path.

Gli utenti dell’area privata possono avere 3 ruoli:

• Operatore

• Amministrato

• Operatore/Amministrato

E’ previsto che gli utenti Operatori, poiché inizialmente non avranno servizi sulla nuova infrastruttura, vengano reindirizzati, a valle della login, sull vecchio portale NoiPA.

I contenuti del Portale saranno strutturati in una area riservata mediante la quale gli utenti potranno evadere tutte le funzioni messe a loro a disposizione.

− area riservata:

• l’utente potrà accedere all’area solo previa autenticazione;

L’architettura prevede un modello a tre livelli Presentation, Business, Data, realizzato mediante Single Page Application e Microservizi.

I pattern architetturali utilizzati risultano essere:

• MVVM

• PROXY

• MVC

• MEDIATOR

• DAO

• DTO

In generale il FrontEnd viene realizzato mediante applicazioni custom realizzate tramite SinglePage Application (SPA) e microservizi (MS). Sulle SPA è presente la sola logica di presentation dei dati e di interazione utente. Mentre i MS, sul backend, realizzano tutte le funzionalità e sono esposti mediante API Gateway.

La fase di autenticazione all’area privata dovrà prevedere una redirect al vecchio portale NoiPA qualora l’utente risulti avere il ruolo di Operatore.

Per mantenere una coerenza fra i nuovi servizi nell’area privata Cloudify NoiPA e i vecchi in NoiPA occorrerà rivedere la testata dell’area autenticata del vecchio portale in modo da poter ritornare alla nuova area privata.

I nuovi servizi si avvalgono di servizi REST esposti dall’EIM, di servizi REST dell’ambiente Liferay della nuova area pubblica, che esporrà dati testuali in modalità Headless per consentire l’editing di tali informazioni agli utenti di tipo redattore, e di alcuni servizi dell’ambiente Legacy di tipo SOAP o REST (esposti tramite WebLogic) per il recupero dei dati dalla vecchia infrastruttura, tali servizi sono quelli dei cedolini e delle CU (detti servizi di post emissione) e di AU, SPT e AREAS.

La protezione delle SPA è garantita dal componente WebGate che si occupa di proteggere le risorse il cui accesso è consentito soltanto dopo aver effettuato l’autenticazione mediante OAM.

Il componente EIM in questo documento, viene trattato come semplice erogatore di servizi di tipo REST/SOAP, tali servizi non sono protetti e andrebbe al più presto prevista la messa in sicurezza allo stesso modo di quella implementata per i servizi Legacy (vedi architettura di sicurezza).

Architettura Applicativa

L’architettura applicativa della parte privata prevede l’utilizzo di SPA, per la parte di Presentation, e di un componente per la verifica del Token basato su Spring MVC. Tali componenti vengono erogati tramite l’infrastruttura OpenStack (vedi architettura di Sistema). Il componente per la verifica del token provvede ad invocare un microservizio di integrazione, realizzato mediante Spring boot, che realizza la funzionalità di Business richiesta mediante l’ìinvocazione di servizi di backend quali:

• servizi REST esposti dall’EIM

• servizi SOAP o REST esposti dall’ambiente legacy

Inoltre si occupa di invocare altri microservizi trasversali di uso comune all’interno di Cloudify, necessari alla funzionalità di business e di predisporre i dati per la fruizione dalla SPA.

Il componente di integrazione si occupa anche della conversione da SOAP a REST e della cifratura/decifratura dei dati al fine di garantirne l’integrità nel passaggio dal frontend al backend.

Il componente realizza uno strato proxy tra il frontEnd ed i servizi di BackEnd e svolge anche la funzione di orchestratore dei servizi legacy oltre che della conversione dei formati e la preparazione all’invocazione delle chiamate inserendo i parametri autorizzativi nell’header.

La SPA, inoltre provvede direttamente ad invocare i servizi REST esposti, in modalità headless, dal nuovo ambiente Liferay

Di seguito il disegno architetturale:

5.2.6 Navigazione tra i Portali

Il sistema prevede la presenza di 3 portali web contemporaneamente attivi per servire aree e porzioni differenti dell’intero sistema Cloudify. I portali risultano essere:

• Portale pubblico

• Portale Privato Cloudify

• Portale Privato Legacy

I portali Privati risultano essere sotto SSO dell’OAM, quindi saranno accedibili ai soli utenti autenticati, e l’OAM provvederà ad inviare i dati relativi degli utenti

abilitati mediante HTTPHeaders ai componenti applicativi presenti nei due portali.

Il portale Pubblico non risulta essere sotto OAM, quindi non è previsto alcun livello di protezione, né sistemi di trasporto di dati degli utenti. Viene realizzato un sistema di scambio dati tra il portale Pubblico ed il Portale Privato Cloudify basato su WebStorage di tipo Session per informare il portale Pubblico della avvenuta autoenticazione di un utente nell’Area privata.

5.2.7 Componenti e Servizi

Di seguito viene riportata la lista dei componenti e dei servizi previsti per il primo sprint

Servizio	Componente	Prodotto
IAAS	Single Page Application UI	Tomcat 8.x
PaaS	API Management	Red Hat 3Scale (2.0.0)
PaaS	Appl Platform (Microservices)	Red Hat JBoss EAP 7.0
PaaS	Load Balancer	Service OpenShift
PaaS	Gateway	Router OpenShift
PaaS	Logging	EFK

Architettura di sicurezza

La sicurezza viene gestita vari livelli di autorizzativi:

• Sicurezza tramite OAM

• Sicurezza Applicativa SPA

• Sicurezza API Gateway

• Sicurezza servizi Legacy

Per rendere il sistema il piu possibile compliant con l’architettura Cloudify definita nel doc [CloudifyNoiPA_DocumentoArchitettura.docx], e minimizzare i reworking nelle succesive fasi di reallizazione dell’intero sistema Cloudify, l’ambiente di esecuzione per l’API Gateway ed il microservizio di integrazione risulta essere il PAAS Cloudify. Questo implica la non protezione da parte dell’OAM di tutti i componenti presenti nel PAAS che in questa fase risultano essere l’ApiGateway, ed i Pods Jboss EAP in cui vie eseguito il microservizio di Integrazione.

5.2.8 Sicurezza tramite OAM

Il portale privato è accedibile ai soli utenti registrati ed attivi del sistema NoiPA.

La verifica delle credenziali di accesso viene effattuata mediante sistema IAM Oracle Access Manager (di seguito OAM). Il sistema OAM permetterà di effettuare:

• Login di utente registrato mediante user/password e redirect alla SPA

• Login mediante SPID

• Cambio password

• Recupero password

Per soddisfare il requisito di mantenere inalterata l’attuale modalità di integrazione con l’OAM, nel periodo transitorio è necessario che i dati del profilo utente oggi instradati verso le applicazioni mediante HTTPHeaders, vengano inviati alle SPA contenute nell’ambiente di esecuzione IAAS.

La protezione delle SPA presenti nell’aree privata è demandato ad un sistema di access gateway che, mediante reverse proxy permetterà l’accesso alle aree protette soltanto se l’utente risulta autenticato, altrimenti rimanderà alla pagina di login.

Una volta eseguito il login, l’OAM eseguirà il redirect alla pagina richiesta, popolando i dati dell’utente nell’ http Headers della richiesta.

Gli ambienti di esecuzione Cloudify e Legacy saranno sotto SSO poiché è prevista una unica richiesta di credenziali per l’accesso ai due portali privati.

5.2.9 Sicurezza Applicativa SPA

Viene realizzato un strato di sicurezza applicativa sulle SPA per criptare i dati sensibili che vengono scambiati tra il FrontEnd Angular ed il componente SpringMVC . In questo modo al browser arriveranno dati criptati così da rendere impossibile la loro manipolazione. La criptazione/decriptazione avverrà mediante tramite chiave privata e algoritmo AES. Non è previsto il transito della chiave tra FrontOffice e BackOffice, e la politica di rigenerazione della chiave avrà un eviction time di un giorno.

5.2.10 Sicurezza Api Gateway

L’ambiente di esecuzione Cloudify PAAS risulta essere in una area di rete privata non accedibile dall’esterno. Nessun componente risulta essere raggiungibile dalla DMZ. Anche l’API Gateway risulta essere completamente in una area di networking interna. Tuttavia viene realizzato un strato per securizzare le API esposte mediante token di autorizzazione. Ogni API viene securizzata da un token autorizzativo configurato sull’API Gateway e fornito al BackOffice dell SPA. Il token deve essere fornito dalla SPA all’API Gateway per ogni chiamata alle API. Sulla SPA, l token vengono memorizzati come variabilie d’ambiente dell’Application Server e recuperati dal BackOffice al momento dell’invocazione delle API.

5.2.11 Sicurezza servizi Legacy

Poiché i servizi Legacy sono esposti verso il Tenant OpenShift mediante un HttpServer con il plugin WebGate configurato con un’utenza di servizio, le chiamate dal microservizio di integrazione avverrano in Basic Authentication e passando nell’Header tutti i parametri provenienti dal frontend (tali parametri sono propagati dal componente SpringMVC, che a sua volta li riceve dai WebGate di frontend, verso il microservizio).

Architettura di sistema

Fase	Uso	Application Stack	Macro Requisiti
Integrazione	Ambiente di test integrato, inclusivo dei sistemi Legacy.	Tutti, tranne la componente Portale & CMS	Architettura logica ed architetturale come l’ambiente di produzione, Componenti in alta affidabilità Sottodimensionato rispetto all’ambiente di produzione

Di seguito si riporta la lista degli ambienti previsti per il progetto Cloudify in linea con il modello di gestione del software e del delivery flow.

Fase	Uso	Application Stack	Macro Requisiti
Collaudo	Ambiente di test funzionale	Tutti	Architettura logica ed architetturale come l’ambiente di produzione, Componenti in alta affidabilità Sottodimensionato rispetto all’ambiente di produzione
Pre-Produzione	Ambiente di test per le Operation e Performance Test.	Tutti	Architettura logica ed architetturale come l’ambiente di produzione, Componenti in alta affidabilità Dimensionato come ambiente di produzione.
Produzione	Ambiente di test di performance pre produzione.	Tutti	-

Architettura di Rete

Tra gli ambienti Clodufy, Legacy ed OAM sussite una disomogeneità di ambienti. Di seguito viene riportato uno schema esplicativo delle interconnessioni tra gli ambienti che verranno instaurate.

AMBIENTE PORTALE PUBBLICO	AMBIENTE IAAS	AMBIENTE PAAS	AMBIENTE LEGACY	AMBIENTE OAM	AMBIENTE EIM
Collaudo Integrato	Collaudo Integrato	Collaudo Integrato	Xxxxxxxx	Xxxxxxxx	[TBD REPLY]
Xxxxxxxx	Xxxxxxxx	Xxxxxxxx	Xxxxxxxx	Xxxxxxxx	[TBD REPLY]
Preproduzione	Preproduzione	Preproduzione	Xxxxxxxx	Xxxxxxxx	[TBD REPLY]
Produzione	Produzione	Produzione	Produzione	Produzione	[TBD REPLY]

Document Metadata

Table of Contents

PREINFORMATIVA PER L’AFFIDAMENTO DI SERVIZI APPLICATIVI DI SVILUPPO, MANUTENZIONE E GESTIONE DEL SISTEMA NOIPA

Document Metadata