Manuale d'uso. Infrastruttura CART

Transcript

1 Manuale d'uso Infrastruttura Versione /05/ L'ultima versione di questo manuale è disponibile al seguente URL

2 Lista delle modifiche Autore Data Oggetto della modifica Leonardo Trotti 22/10/09 Inserimento riferimenti ad OSCAT per la consegna del software sviluppato Leonardo Trotti 30/11/09 Rimozione riferimenti a: Deploy di un proxy applicativo ; Consegna di un proxy applicativo ; Consegna Suite di Test resi obsoleti e/o integrati in Manuale uso piattaforma OSCAT Leonardo Trotti 12/01/10 Inserimento riferimenti a PMC ( Proxy Monitoring Controller ) Leonardo Trotti 10/05/10 Inserimento riferimenti a SLC ( Service Life Cycle )

3 1 Scopo del manuale NOTA Il Ambiente di Produzione e Staging del Sistema di monitoraggio PMC Dispiegamento tipico di un servizio Linee guida sull'attivazione dei servizi nel contesto Erogazione di un nuovo servizio tramite l'infrastruttura Sviluppo del software che eroga il servizio e dispiegamento in ambiente di staging Definizione e condivisione dell'analisi del servizio (RFC e.toscana Applicativo) Sviluppo del software che implementa l'erogazione del servizio Dispiegamento in ambiente di Staging del software che eroga il servizio: Test in ambiente di Staging del software che eroga il servizio Dispiegamento del software erogatore del servizio in ambiente di produzione Configurazione dell'ambiente di produzione Erogazione del servizio Certificazione delle applicazioni Fruizione di un servizio erogato tramite l'infrastruttura Sviluppo del software che fruisce del servizio e dispiegamento in ambiente di staging Raccolta delle informazioni del servizio erogato in ambiente di staging Raccolta delle informazioni necessaria ad implementare un fruitore di un servizio Implementazione delle interfacce per la fruizione del servizio Richiesta utilizzo del servizio erogatore in ambiente di Staging Test del servizio in ambiente di Staging Dispiegamento del software fruitore del servizio in ambiente di produzione Richiesta utilizzo del servizio in ambiente di Produzione Esercizio del fruitore del servizio Certificazione del software che fruisce del servizio Lista dei documenti Riferimenti per Help-Desk...25

4 Legenda icone ICONA Significato Rappresenta una risposa a domande ricorrenti. Rappresenta un momento di verifica. Indica che cosa deve avvenire ossia lo scopo di un passo in una fase. Suggerimento. 4/26

5 1 Scopo del manuale Lo scopo del manuale è quello di fornire delle utili indicazioni sui processi da implementare per fruire correttamente dell'infrastruttura. 1.1 NOTA Nel documento sono citati i seguenti ruoli: Utente Gestore Progetto Ditta Responsabile Infrastruttura Gestore Infrastruttura Tali ruoli sono chiariti nel documento Introduzione infrastruttura. In tale documento sono indicate anche le responsabilità e i riferimenti per contattare gli attori che rivestono tali ruoli. La lettura del documento Introduzione infrastruttura è prerequisito essenziale alla fruizione di questo manuale. 5/26

6 2 Il L'evoluzione tecnologica e normativa consente oggi la possibilità ad una Amministrazione di fruire di servizi informatici messi a disposizione da altra Amministrazione. La fruizione di un servizio messo a disposizione dai sistemi informatici di altra Amministrazione consente di migliorare il grado di sinergia di sistemi diversi con il fine di offrire servizi o funzionalità nuove. Si vuole quindi realizzare l'interoperabilità delle pubbliche amministrazioni. L'interoperabilità delle pubbliche amministrazioni è oggi fattibile grazie ad un nuovo contesto favorevole: legalmente riconosciuta: lo scambio di documenti tra le pubbliche amministrazioni costituisce invio documentale valido (CAD art. 76 comma 1); economicamente vantaggiosa: tramite la maggiore efficienza nei processi e la riduzione dei costi degli archivi cartacei; tecnicamente realizzabile: grazie all'esistenza della rete della pubblica amministrazione, all'esistenza di un modello condiviso (SPCoop), all'esistenza di formati aperti che consentono la condivisione delle informazioni. Il è lo strumento che Regione Toscana mette a disposizione di RTRT al fine di realizzare l'interoperabilità tra i sistemi informativi dei soggetti della rete regionale sia con quelli di soggetti esterni (Ministeri, Istituti,...). La piena realizzazione dell'interoperabilità si basa sull'esistenza di: una infrastruttura condivisa dai soggetti per la trasmissione di qualsiasi informazione o documento elettronico. Nel contesto questo strumento è l'infrastruttura. la definizione di un linguaggio condiviso che stabilisca quali informazioni devono essere scambiate e quale significato hanno. Nel contesto la definizione di tale linguaggio è garantita dal processo e.toscana Compliance. un soggetto che garantisca il pieno rispetto delle specifiche di trasmissione e dei contenuti delle informazioni. Nel contesto tale ruolo è ricoperto dal Comitato e.toscana Compliance che amministra l'albo delle applicazioni e.toscana Compliant. Il contribuisce dunque ad attuare una strategia organica e unitaria per lo sviluppo della società dell'informazione e della conoscenza (LR 26/2004 Art.2 comma 1.b)) fornendo supporto alla creazione condivisa di servizi erogati. 6/26

7 3 Ambiente di Produzione e Staging del Il è un'infrastruttura, capillarmente distribuita sul territorio regionale, che consente l'erogazione e la fruizione di servizi agli Enti del territorio regionale. L'infrastruttura è capillarmente distribuita sul territorio regionale. Sul territorio regionale sono attualmente dispiegati 125 Nodi Applicativi Locali (NAL). Un NAL è un apparato hardware collocato presso un Ente le cui interfacce esposte tramite Proxy Applicativi consentono di inviare le informazioni ad un altro NAL e quindi ad un altro Ente. La seguente tabella riassume la distribuzione dei NAL sul territorio regionale. Tipo Ente Regione Toscana 3 Numer o di NAL Aziende Ospedaliere (AO) 4 Aziende Sanitarie Locali (ASL) 12 Comunità Montane 17 Comuni 64 ESTAV 3 Province 10 TIX 4 ALTRO 8 Totale 125 Tabella 1 Numero di NAL dispiegati sul territorio regionale al 15/4/2009 La mappa completa dei NAL è riportata sul sito del. Dunque se un Ente vuole utilizzare un servizio messo a disposizione dell'infrastruttura dovrà utilizzare le interfacce che il proprio NAL (ossia il NAL assegnato) presenta. Lo stesso discorso vale qualora l'ente eroghi un servizio. Qualora l'ente voglia utilizzare un servizio ma non dispone di un NAL può utilizzare un NAL messo a disposizione di un Ente limitrofo (accordandosi con l'ente ospitante) oppure utilizzare uno dei NAL condivisi messi a disposizione presso il TIX. 7/26

8 Un servizio viene messo a disposizione sull'infrastruttura di Produzione del dopo che è stato verificato in ambiente di Staging. L'ambiente di Staging del è una infrastruttura identica dal punto di vista della tipologia delle risorse ma utilizzabile per verificare i componenti realizzati prima del dispiegamento in ambiente di Produzione. L'ambiente di Staging e quello di Produzione sono ambienti completamente separati e quindi non è possibile erogare un servizio in ambiente di Staging e fruirlo in ambiente di Produzione o viceversa. L'ambiente di Staging è attualmente composto da 6 NAL alcuni dei quali dispiegati presso il TIX ed altri dispiegati presso Regione Toscana. Alcuni NAL sono raggiungibili attraverso Internet fornendo una piattaforma per lo sviluppo dei componenti utilizzabili dai Fornitori software. Infine alcuni NAL hanno già installato dei componenti software specifici per la Sanità. La seguente tabella riassume le caratteristiche dei NAL in ambiente di Staging: Nome NAL Localizzazione Visibile da Internet Componenti della sanità già installati carttestnal Regione Toscana SI NO cartestanl2 Regione Toscana SI SI nal-tix2 TIX SI SI statixgen01 TIX SI NO nal-san-tdgroup nal-tdgroup Gestore infrastruttura Gestore infrastruttura Ad esempio, se un Fornitore desidera verificare i componenti sviluppati per la Sanità può richiedere al Gestore dell'infrastruttura, il dispiegamento su nal-tix2 o carttestnal2 in modo da poter erogare e fruire i servizi direttamente dal proprio laboratorio di sviluppo. NO NO SI NO 3.1 Sistema di monitoraggio PMC Il sistema di monitoraggio PMC è un sistema che consente di monitorare lo stato dei messaggi di un dato servizio. Consta di una componente centrale e di più componenti periferiche. La componente centrale riceve dalle componenti periferiche, installate sui proxy applicativi dei rispettivi NAL, le notifiche relative ai messaggi del servizio sotto monitoraggio. Tali notifiche coincidono con i quattro stadi del percorso di un messaggio attraverso l'infrastruttura : messaggio ricevuto dal SIL erogatore, messaggio preso in carico dalla PdD fruitore, messaggio preso in carico dalla PdD erogatore, messaggio inviato al SIL erogatore. E' possibile stabile delle regole, temporali e dimensionali, violate le quali il sistema di monitoraggio segnali un allarme. Con regola temporale si intende una regola atta a verificare che un messaggio attraversi l'infrastruttura entro un dato lasso di tempo mentre con regola dimensionale una regola atta a verificare che su un dato servizio transitino almeno una quantità stabilita di messaggi al giorno. 8/26

9 4 Dispiegamento tipico di un servizio Un servizio risulta correttamente dispiegato quando sia in ambiente di Staging che Produzione è presente ogni componente software e configurazione presente in figura: Fig. 1 Communication Diagram dei principali componenti Come indicato in figura l'utente inteso come soggetto che sviluppa il servizio ha: dispiegato il Proxy Erogatore del servizio dispiegato il Proxy Fruitore del servizio inoltre richiesto la configurazione: dell'erogatore del servizio (freccia 3 nella figura) della fruizione del servizio (freccia 2 nella figura) facoltativamente del servizio di monitoraggio PMC (frecce (n1,n2) ed (n3,n4) ) 9/26

10 Nei successivi paragrafi il manuale illustra i workflow delle azioni che l'utente inteso come sviluppatore o Capo Progetto richiede al gestore dell'infrastruttura al fine di dispiegare correttamente un servizio. Per la configurazione dei servizi sono state approntate le schede indicate nell'appendice da utilizzare nei workflow indicati, per l'installazione del proxy su NAL sono stati elaborate una serie di indicazioni sotto riportate. E' inoltre da notare che le interfacce relative alle frecce (1), (2), (3), (4) sono indicate negli RFC relativi al servizio (documenti obbligatori per il dispiegamento del servizio). Le interfacce dei Proxy (freccia (1) e (4)) sono tipicamente dei web services definiti in WSDL le cui specifiche sono riportate negli RFC mentre Le frecce (2) e (3) sono aspetti di configurazione infrastrutturale. Il sistema di monitoraggio PMC, ove attivato, si compone di una componente centrale che riceve le notifiche inviate dalle componenti installate su ciascun nal. Le intreazioni dei proxy con la componente PMCNal sono atte ad espletare l'invio di 4 notifiche n1,n2,n3 ed n4 che rispettivamente rappresentano i quattro stadi del percorso di un messaggio: messaggio ricevuto dal SIL erogatore, messaggio preso in carico dalla PdD fruitore, messaggio preso in carico dalla PdD erogatore, messaggio inviato al SIL erogatore. Per l'utilizzo del sistema di monitoraggio PMC e il corretto modo di predisporre i proxy per interfacciarsi al PMC inviando le notifiche necessarie è possibile riferirsi a quanto descritto nei documenti indcati in appendice. 10/26

11 5 Linee guida sull'attivazione dei servizi nel contesto L'attivazione di un nuovo servizio viene, generalmente, effettuata in due fasi: 1. erogazione di un nuovo servizio. In questa fase un Utente intende erogare un nuovo servizio tramite l'infrastruttura. Tale servizio verrà successivamente fruito da almeno un altro Utente utilizzando il. 2. fruizione di un servizio esistente. In questa fase un Utente intende fruire di un servizio già erogato da altro Utente tramite l'infrastruttura. L'infrastruttura dispone di due ambienti gemelli quello di Staging e quello di Produzione. Nel primo avvengono i test di integrazione del servizio nell'infrastruttura mentre nel secondo l'effettiva erogazione e fruizione da parte degli Enti. La prima fase di sviluppo del software che implementa un servizio avviene sempre in ambiente di Staging procedendo prima con lo sviluppo dell'erogatore e poi del fruitore. Una volta che il servizio è stato erogato correttamente in ambiente di staging può iniziare ad essere erogato anche in produzione. Analogamente una volta che il servizio viene fruito correttamente in ambiente di staging può iniziare ad essere fruito anche in ambiente di produzione. Il diagramma delle attività risultante è il seguente. Al fine di unificare e standardizzare il processo di attivazione dei servizi è stata realizzata l applicazione per la gestione integrata delle richieste di configurazione dei servizi e per la configurazione automatica degli accordi di servizio SLC (Service Life Cycle), il cui utilizzo sarà illustrato nei paragrafi seguenti. Fig. 1 Diagramma delle attività per lo sviluppo completo di un servizio 11/26

12 Ogni attività indicata nella figura viene ripresa nel documento e ulteriormente spiegata. I passi: sviluppo del software che eroga il servizio e dispiegamento in ambiente di Staging dispiegamento del software che eroga il servizio in ambiente di produzione sono finalizzati all'erogazione di un nuovo servizio dunque nel documento vengono sviluppati nella sezione Erogazione di un nuovo servizio tramite l'infrastruttura mentre i passi: sviluppo del software che fruisce del servizio e dispiegamento in ambiente di staging dispiegamento del software fruitore del servizio in ambiente di produzione sono finalizzati alla fruizione del servizio e dunque nel documento vengono sviluppati nella sezione Fruizione di un servizio erogato tramite l'infrastruttura. 6 Erogazione di un nuovo servizio tramite l'infrastruttura I principali passi per implementare il software attraverso il quale un Utente fornisce il servizio (od integrare un servizio esistente via ) sono i seguenti: sviluppo del software che eroga il servizio e dispiegamento in ambiente di staging dispiegamento del software che eroga il servizio in ambiente di produzione Un software sviluppato può essere dispiegato (installato) su più Utenti erogatori del servizio. 6.1 Sviluppo del software che eroga il servizio e dispiegamento in ambiente di staging Il risultato di questo passo è la definizione del servizio lato erogatore, l'implementazione del software che lo realizza, il suo dispiegamento in ambiente di Staging. Nell'ambito di questo passo le attività da compiere sono descritti nel seguente diagramma. 12/26

13 Fig. 2 Sviluppo del software erogatore di un servizio L'obiettivo di queste attività è l'effettivo dispiegamento di un servizio in ambiente di staging come indicato nella seguente figura: Fig.3 - Esempio di servizio dispiegato nell'ambiente di staging 13/26

14 Di seguito verranno descritte e meglio definite le singole attività Definizione e condivisione dell'analisi del servizio (RFC e.toscana Applicativo) 1. Il primo passo da compiere è quello di definire il servizio che si intende realizzare. Poiché si tratta di un servizio che un altro Utente dovrà fruire si rende necessario condividere l'analisi. Verrà quindi organizzato un incontro che dovrà coinvolgere il responsabile del Servizio di Regione Toscana, il personale del gestore dell'infrastruttura e gli sviluppatori del servizio stesso. Nella riunione verranno delineate le configurazioni e le funzionalità che dovranno essere erogate dall'infrastruttura. In questa sede verrà compilato e condiviso un documento di progettazione del servizio. L'infrastruttura inoltre mette a disposizione il sito quale strumento per la definizione e la condivisione delle analisi di servizi erogati tramite l'infrastruttura. Tutti i documenti di analisi, chiamati RFC e.toscana Applicativi, hanno lo stesso formato (si veda il documento indicato con RFC#17 ). La produzione della definizione del servizio si compone dei passi indicati alla sezione Scrittura di un RFC e.toscana Applicativo del documento Manuale e.toscana Compliance. E' consigliato all'utente richiedere al Centro Tecnico e.toscana Compliance un parere tecnico dell'rfc e.toscana Applicativo che si è realizzato. A questo punto esiste un documento pubblico i cui contenuti sono condivisi da tutti gli Utenti interessati; le specifiche del servizio da implementare sono formulate in un documento il cui formato è standard (RFC e.toscana Applicativo) e questo consente una facile fruizione anche da quegli Utenti che potrebbero essere interessati al servizio in un secondo momento; il documento sarà comunque utilizzato da tutti gli Utenti che dovranno implementare il software per fruire del servizio implementato Sviluppo del software che implementa l'erogazione del servizio L'Utente implementa il software che realizza la soluzione esposta al passo precedente. Il documento Architettura infrastruttura fornisce le informazioni essenziali per lo sviluppo del software. I sotto passi da compiere sono i seguenti: 1. L'Utente scarica il pacchetto SDK- ; il SDK- è un pacchetto contenente documentazione tecnica e codice di esempio utile ad implementare un nuovo servizio; 2. nel caso in cui il software sia un Proxy Applicativo si rende necessario: 14/26

15 A) consegnare il software nel formato nel documento Manuale d'uso della Piattaforma ; B) consegnare le componenti software da installare sul NAL rispettando quanto indicato nel documento Deploy di Proxy su piattaforma NAL ; L'utente sviluppa ed infine consegna il software avvalendosi della piattaforma OSCAT ( ). OSCAT è la Piattaforma per lo Sviluppo e Rilascio di Componenti Software di Regione Toscana per l'uso della quale si rimanda all'apposito Manuale d'uso della Piattaforma scaricabile all'indirizzo Per ulteriori dettagli rivolgersi al Responsabile Infrastruttura. SLA: L'evasione della richiesta è garantita dal gestore dell'infrastruttura entro le 72 ore a meno di problemi tecnici o di non conformità del materiale fornito. Qualsiasi tipo di problema verrà comunque comunicato tempestivamente al richiedente. Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura Nel caso non ci siano vincoli temporali importanti (es. un cittadino che richiede un servizio presso uno sportello) è preferibile utilizzare i profili asincroni a quello sincrono. Questo perché tecnicamente i servizi risultano essere più robusti e scalabili. Inoltre l'interfaccia per tale modalità di utilizzo dell'infrastruttura (Integration Manager) risulta essere già definita e quindi i tempi di sviluppo dei servizi risultano sensibilmente ridotti. A questo punto l'utente ha realizzato il software che implementa l'erogazione e, tipicamente, anche quello che fruisce del servizio Dispiegamento in ambiente di Staging del software che eroga il servizio: L'ambiente di Staging è un'insieme di macchine che simulano l'infrastruttura utilizzato per verificare la corretta implementazione del servizio implementato al passo precedente. Il punto di ingresso dell'infrastruttura è un NAL pubblico (ossia le cui interfacce sono fruibili da tutte le Amministrazioni o Ditte). Per ulteriori dettagli sull'ambiente di Staging si veda il documento Architettura infrastruttura. 15/26

16 1. L'Utente, qualora non ne sia già fornito, richiede un utenza per l'utilizzo del sistema SLC, attraverso il quale potrà generare le richieste di erogazione e di fruizione del servizio, inviando un' al Gestore Infrastruttura e per conoscenza al Responsabile Infrastruttura; 2. Il Gestore Infrastruttura fornisce l'utenza all'utente che attraverso SLC sottopone la richiesta di Erogazione del servizio; 3. Il Gestore Infrastruttura, ricevuta richiesta, configura l'ambiente di Staging secondo le informazioni ricevute oppure richiede all'utente ulteriori informazioni. Quando le indicazioni fornite sono ritenute chiare il Gestore Infrastruttura esegue la configurazione e restituisce all'utente, tramite SLC, i parametri necessari all'utente per configurare il software che dovrà erogare il servizio. 4. l'utente configura il software e inizia ad erogare il servizio utilizzando i parametri ricevuti al passo precedente, se necessari. Per ulteriori dettagli rivolgersi al Gestore Infrastruttura. SLA: L'evasione della richiesta è garantita dal gestore dell'infrastruttura entro le 48 ore a meno di problemi tecnici o di non conformità del materiale fornito. Qualsiasi tipo di problema verrà comunque comunicato tempestivamente al richiedente. Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura Test in ambiente di Staging del software che eroga il servizio L'Utente che implementa il servizio deve concordare con il Gestore dell'infrastruttura un metodo oggettivo per testare il corretto funzionamento del servizio. Per i servizi che si appoggiano esclusivamente sulle funzionalità dell'infrastruttura è auspicabile la fornitura di un xml di test che può essere invocato attraverso lo strumento Service Browser messo a disposizione dal (vedi documento Service Browser ). Per quei servizi che utilizzano i proxy è obbligatorio il rilascio di una test suite tramite l'infrastruttura OSCAT Per ulteriori dettagli rivolgersi al Gestore Infrastruttura 16/26

17 Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura A questo punto l'utente ha realizzato il software che implementa l'erogazione del servizio; la Test Suite rilasciata verrà utilizzata dagli Utenti che fruiranno del servizio; l'utente che vuole fruire del servizio ha tutti gli strumenti per farlo: l'rfc e.toscana Applicativo definisce le specifiche del servizio, il servizio è effettivamente dispiegato in ambiente di staging, esiste la Test Suite quale esempio di software fruitore del servizio che può essere quindi ridistribuito. Questa fase è da ritenersi conclusa quando: L'Utente ha pubblicato l'rfc e.toscana Applicativo associato al servizio L'Utente giudica condiviso dalla Comunità e.toscana Compliance il documento sviluppato il software che eroga il servizio secondo le specifiche descritte nell'rfc e.toscana Applicativo sviluppata e consegnata la Test Suite del servizio tutti i test definiti nella Test Suite hanno successo Una volta che è stato realizzato il servizio in ambiente di staging si può passare allo sviluppo della controparte fruitore del servizio o proseguire lato erogatore dispiegando il servizio in ambiente di produzione. 17/26

18 6.2 Dispiegamento del software erogatore del servizio in ambiente di produzione Fig.4 Dispiegamento del software che eroga il servizio in ambiente di produzione Il risultato di questo passo è il dispiegamento del software che eroga un servizio in ambiente di produzione. Alla fine di questo passo il servizio è quindi completamente fruibile. Nell'ambito di questo passo le attività da compiere sono descritti nel seguente diagramma. Di seguito vengono descritte e meglio definite le singole attività Configurazione dell'ambiente di produzione 1. L'Utente implementa il servizio in ambiente di produzione; 2. L'Utente, se il servizio lo prevede, richiede tramite la console SLC al gestore dell'infrastruttura il passaggio in produzione del Proxy Applicativo precedentemente dispiegato in staging; 3. Utente compila la Richiesta di Erogazione del servizio in ambiente di produzione tramite la console di SLC; Per ulteriori dettagli rivolgersi al Gestore Infrastruttura. 18/26

19 SLA: L'evasione della richiesta è garantita dal gestore dell'infrastruttura entro le 48 ore a meno di problemi tecnici o di non conformità del materiale fornito. Qualsiasi tipo di problema verrà comunque comunicato tempestivamente al richiedente. Supporto utilizzabile per compiere questo passo: Gestore Infrastruttura Erogazione del servizio 1. L'Utente dopo aver impostato la configurazione necessaria per erogare il servizio contatta il Gestore dell'infrastruttura il quale invoca il servizio per verificarne il corretto funzionamento. Eventualmente, insieme, risolvono gli eventuali problemi. Per ulteriori dettagli rivolgersi al Responsabile Infrastruttura. Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura Certificazione delle applicazioni. 1. Se il progetto ha richiesto lo sviluppo di un proxy è necessaria la certificazione di questa componente software. I passi da compiere per la certificazione del proxy sono descritti nel documento Manuale e.toscana Compliance. Per ulteriori dettagli rivolgersi al Centro Tecnico e.toscana Compliance. Supporto da utilizzare per compiere questo passo: Centro Tecnico e.toscana Compliance L'intero processo verrà a breve automatizzato utilizzando uno strumento di work-flow. Per ulteriori informazioni e/o dettagli si può richiedere a Responsabile dell'infrastruttura. 7 Fruizione di un servizio erogato tramite l'infrastruttura I principali passi necessari per sviluppare il software che fruisce di un servizio erogato dall'infrastruttura sono: sviluppo del software per la fruizione del servizio erogato via e dispiegamento in ambiente di Staging dispiegamento in ambiente di produzione del software che fruisce di un servizio erogato via Il software utilizzato per la fruizione di un servizio può essere dispiegato più volte in ambiente di produzione. Quindi più Utenti possono fruire del servizio attraverso lo stesso software. 19/26

20 7.1 Sviluppo del software che fruisce del servizio e dispiegamento in ambiente di staging Partendo dal presupposto che, in ambiente di Staging, sia già erogato il servizio che ci interessa fruire il risultato delle azioni di seguito illustrate è l'effettiva fruizione del servizio. Graficamente il workflow dei passi che devono essere eseguiti per fruire di un servizio in ambiente di Staging è il seguente: Fig.5 - Sviluppo del software per la fruizione del servizio erogato via e dispiegamento in ambiente di Staging Di seguito vengono illustrati i passi per sviluppare il software fruitore di un servizio erogato da un soggetto tramite l'infrastruttura Raccolta delle informazioni del servizio erogato in ambiente di staging In questa fase l' Utente che fruirà del servizio raccoglie tutte le informazioni per implementare le interfacce che consentono l'utilizzo del servizio. Le informazioni necessarie a tale scopo sono: 1. RFC e.toscana Applicativo. Tutti gli RFC e.toscana Applicativi sono documenti pubblici liberamente reperibili al seguente sito;è necessario scaricare l'rfc associato al servizio che deve essere sviluppato; richieste di chiarimenti sull'rfc possono essere effettuate tramite il forum associato; 20/26

21 Nel caso in cui l'utente non sia un soggetto di RTRT è possibile che non sia stato pubblicato l'rfc e.toscana Applicativo del servizio. In questo caso l'utente fruitore deve comunque pubblicare la documentazione del servizio preferibilmente come RFC e.toscana Applicativo o, se non è possibile, nel formato rilasciato dall'utente erogatore (ad esempio Ministero, INPS,...). 2. Procurarsi la Test Suite rilasciata dall'utente che ha implementato il software che provvede alla fornitura del servizio deve aver rilasciato (si veda il punto 4. del processo di Erogazione di un nuovo servizio in ambiente di Staging ). Tale Test Suite è reperibile traminte OSCAT. Per ulteriori dettagli rivolgersi al Gestore Infrastruttura. Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura Nel caso in cui l'utente non sia un soggetto di RTRT (ad esempio Ministero, INPS,...) è possibile che non sia disponibile alcuna Test Suite. In questo caso l'utente fruitore deve implementare e rilasciare anche la Test Suite. Qualora i documenti sopra indicati non siano reperibili è necessario chiedere chiarimenti all'utente erogatore di un servizio. A questo punto l'utente ha a disposizione almeno le informazioni necessarie per la realizzazione del software che fruisce il servizio erogato da altro Utente Raccolta delle informazioni necessaria ad implementare un fruitore di un servizio L'Utente scarica il SDK- ; il SDK- è un pacchetto contenente documentazione tecnica e codice di esempio utile alle Ditte che devono implementare del software che fa uso del ; Implementazione delle interfacce per la fruizione del servizio L'Utente implementa le interfacce per utilizzare il servizio. Il software prodotto è chiamato nel contesto con l'acronimo SIL (Sistema Informativo Locale) 21/26

22 L'Utente erogatore del servizio dovrebbe avere implementato e rilasciato tramite OSCAT la Test Suite per la verifica del corretta implementazione del servizio. La Test Suite è dunque un fruitore del servizio. Tale Test Suite può essere utilizzata come esempio di implementazione di un fruitore del servizio. Potrebbe essere utile richiedere all'utente erogatore del servizio tale software Richiesta utilizzo del servizio erogatore in ambiente di Staging L'Utente deve richiedere l'attivazione di un servizio in ambiente di Staging in modo da effettuare i test il cui scopo è quello di verificare il corretto utilizzo (in accordo a quanto indicato nella documentazione fornita) del servizio. E' quindi necessario eseguire i seguenti passi: 1. L'Utente compila, tramite la console SLC, una nuova Richiesta di Fruizione del servizio in l'ambiente di Staging; 2. Il Gestore dell'infrastruttura configura l'ambiente di Staging secondo quanto richiesto e successivamente restituisce all'utente, tramite SLC, la scheda completa delle informazioni necessarie alla configurazione ( es. URL, user/passwd,...) Per ulteriori dettagli rivolgersi al Gestore Infrastruttura. Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura SLA: L'evasione della richiesta è garantita dal gestore dell'infrastruttura entro le 48 ore a meno di problemi tecnici o di non conformità del materiale fornito. Qualsiasi tipo di problema verrà comunque comunicato tempestivamente al richiedente. A questo punto la Ditta è in grado di fruire del servizio in ambiente di staging Test del servizio in ambiente di Staging L'Utente esegue il test del servizio in ambiente di Staging. Durante questa fase può avvalersi della collaborazione del Gestore dell'infrastruttura e utilizzare degli strumenti di debugging messi a disposizione dell'infrastruttura in ambiente di staging. 22/26

23 7.2 Dispiegamento del software fruitore del servizio in ambiente di produzione In questo caso un Utente (Comune, Provincia, ASL,...) richiede la fruizione di un servizio erogato via. Prima di procedere con questo passo è necessario che l'utente fruitore del servizio abbia eseguito i passi descritti in Sviluppo del software fruitore di un servizio erogato via. Di seguito vengono illustrati i passi necessari alla fruizione di un servizio erogato via in ambiente di produzione Richiesta utilizzo del servizio in ambiente di Produzione L' Utente che intende fruire di un servizio erogato via deve richiederne l'attivazione in ambiente di Produzione. E' quindi necessario eseguire i seguenti passi: 1. L'Utente compila, tramite la console SLC, una nuova Richiesta di Fruizione del servizio in l'ambiente di Produzione e attende, in risposta, i parametri necessari per la fruizione del servizio, consegnati attraverso SLC. Esegue i test di verifica della configurazione e al termine invia al Gestore dell'infrastruttura una mail che conferma l'esito positivo della configurazione; 23/26

24 Per ulteriori dettagli rivolgersi al Gestore Infrastruttura. Supporto da utilizzare per compiere questo passo: Gestore Infrastruttura SLA: L'evasione della richiesta è garantita dal gestore dell'infrastruttura entro le 48 ore a meno di problemi tecnici o di non conformità del materiale fornito. Qualsiasi tipo di problema verrà comunque comunicato tempestivamente al richiedente. Adesso l'infrastruttura è configurata correttamente e il servizio è correttamente raggiungibile dall'applicazione dell'utente. Resta solo da verificare che l'applicazione funzioni correttamente Esercizio del fruitore del servizio L' Utente fruitore può verificare la corretta fruizione del servizio avvalendosi di servizi messi a disposizione dall'infrastruttura : FEED-RSS Monitoraggio Applicativo Help Desk Infrastrutturale L'Utente fruisce del servizio in ambiente di produzione dell'infrastruttura Certificazione del software che fruisce del servizio L' Utente fruitore del servizio deve certificare la soluzione (si veda il documento Manuale uso e.compliance ). 8 Riferimenti per Help Desk Indirizzo posta elettronica: cart@regione.toscana.it Numero verde: /26

25 9 Lista dei documenti Titolo Descrizione Responsabilità RFC#17 L'obiettivo di questo documento è quello di concordare la struttura standard di un RFC e.toscana di Tipo Applicativo ed illustrare il processo a cui il documento è sottoposto. Comunità e.toscana Compliance SDK- Manuale Uso Piattaforma OSCAT Documenti e software di esempio da utilizzare per sviluppare un servizio erogato tramite l'infrastruttura Piattaforma per lo Sviluppo e Rilascio di Componenti Software di Regione Toscana Responsabile Infrastruttura Responsabile Infrastruttura Richiesta apertura Documento da utilizzare per richiedere l'apertura dell'infrastruttura ad un soggetto esterno ad RTRT (es. Minitero, INPS, INAIL, altra Regione,...) Responsabile Infrastruttura SLC Produzione Service Life Cycle per l'ambiente di Produzione: l'applicazione consente di unificare e standardizzare il processo di richiesta e di attivazione dei servizi Responsabile Infrastruttura SLC Staging Service Life Cycle per l'ambiente di Staging: l'applicazione consente di unificare e standardizzare il processo di richiesta e di attivazione dei servizi, Responsabile Infrastruttura SLC Manuale d'uso Manuale d'uso di SLC Service Life Cycle Responsabile Infrastruttura Test Connettività SIL-NAL Il documento illustra i test di connettività. Il test di connettività è finalizzato a verificare il corretto colloquio a livello di protocollo di comunicazione tra la macchina dove è installato l'applicativo (SIL) e l'infrastruttura ossia con il NAL punto di erogazione e fruizione del servizio. Gestore Infrastruttura Introduzione infrastruttura Introduzione infrastruttura Responsabile Infrastruttura 25/26

26 Titolo Descrizione Responsabilità Architettura infrastruttura Il documento fornisce le informazioni essenziali sull'architettura del Responsabile Infrastruttura Manuale uso e.compliance Chiarimenti sul processo e.toscana Compliance Responsabile Infrastruttura PMC: Invocazione Sistema di Monitoraggio PMC : Invocazione Sistema di Monitoraggio e Controllo Servizi Responsabile Infrastruttura 26/26