Alessio Mattolini

Transcript

1 Dati identificativi dell applicazione Nome dell applicazione NAVO Protocollo informatico Numero di revisione 2.5 Data rilascio 20/12/2007 RFC applicativi di riferimento Standard RFC Protocollo Responsabile del prodotto Alessio Mattolini Referente tecnico Alessio Mattolini Storico versionamento Versione Data sottomissione Esito Revisione N/A 2 Aprile 2009 Presentazione della documentazione con descrizione solo superficiale dell applicativo Aprile 2009 Aggiunta delle interazioni: Use Case e Sequence Diagrams non conformi e non corretti peraltro con mancanza di Use Case Diagrams Aprile 2009 Corretta la conformità degli Use Case e dei Sequenzer Diagrams, aggiunti Use Case Diagrams ma sono presenti ancora alcune imprecisionie i Sequence Diagrams non sono completi Maggio 2009 Richiesta revisione della documentazione: sono presenti ancora alcune imprecisioni Luglio 2009 Rispetto all ultima versione ( la 2.0 dell 11 Maggio) E stato specificato il versionamento corrente del documento ed è stato aggiunto un riepilogo dettagliato delle modifiche apportate alla precedente documentazione Sono stati corretti alcuni errori nel nome degli attori dei casi d uso ( ) che in questa nuova documentazione nonostante siano descritti in casi d uso separati tutti appartengono al caso d uso UCD_04 E stato alterato il UCD_12 per la gestione della coda dei messaggi. E stata tolta la possibilità di invio i notifiche in quanto scenario non previsto dal CART Aggiunta dei casi d uso e diagramma relativo alla ricezione di messaggi per la comunicazione a soggetti esterni Specifica dei dettagli sullo scheduler: Tempi di aggiornamento e parametri di default Sono stati aggiunti casi d uso per la ricezione di messaggi protocollo di tipi E2,E4 ed E5

2 2.5 3 Agosto 2009 Rispetto all ultima versione ( la 2.1 del 1Luglio) Sono stati modificati gli scenari principali del caso d uso 4 (UCD 04) che descrive tutti i messaggi di tipo notifica (E-1, E- 2,E-3,E-4) E stato inserito un nuovo UDC e un nuovo diagramma, il numero 14 che descrive lo scenario di invio di un messaggio di tipo Protocollo E-3 Notifica eccezione ottobre 2009 Aggiunti i casi d uso 15 e 16 previsti dal progetto InterPro nelle RFC 121 sullo scambio di documentazione tra una PA e un soggetto privato (cittadino, impresa) Aggiunto il caso d uso 17 previsto dal progetto InterPro nella RFC 122 sull aggiornamento della banca dati ADE Aggiunto il caso d uso 18 previsto dal progetto InterPro nella RFC 110 sull aggiornamento della banca dati IPAR degli inici AOO e UO A pagina 6 le nuove specifiche descrittive sul comportamento del Servizio di aggiornamento in base alle nuove funzionalità aggiunte. Modifica del diagramma dei casi d uso, con l aggiunta dei nuovi 4 casi d uso (15,16,17,18) ottobre 2009 Sono stati rimossi i casi d uso 15 e 16 perché ridondanti e non utili al fine dell integrazione E stato creato un extension point per la descrizione del caso d uso 01(Invio messaggio di protocollo) considerando i 3 casi d uso (02,04,06) possibili. Sono stati aggiunti 2 casi d uso 03 e 05 rispettivamente inclusi nei casi d uso 02 e 04 per la gestione dell aggiornamento delle banche dati ADE e AOO e sono stati aggiornati i relativi diagrammi di sequenza. E stato ridisegnato il diagramma dei casi d uso per l aggiunta delle estensioni. E stata alterata la descrizione del servizio di aggiornamento che a differenza della precedente versione adesso è revocato dall incarico di aggiornare gli indici AOO/UO e l archivio ADE ottobre 2009 In attesa di approvazione e.toscana Compliance 03/03/2009 Categoria: Applicativa Destinatari: Regione Toscana, Amministrazioni locali (Secondo il DPR 445 e il DPCM , i destinatari sono tutte le amministrazioni definite dal DL 165/2001)

3 Indice 1. Descrizione 2. Architettura dell applicativo 3. Casi d uso 4. Diagrammi di flusso 5. Descrizione dell interfaccia

4 1. Descrizione Navo è un applicativo che si occupa di eseguire operazioni di protocollo informatico e archiviazione digitale. Creazione protocollo in uscita Ricezione protocollo in ingresso Registrazione protocollo in ingresso Digitalizzazione dei documenti cartacei e gestione del repository Distribuzione del protocollo agli uffici responsabili E una soluzione che si basa sul collegamento tra il client dell operatore e un server centrale IIS / SQL Server. Il server espone un interfaccia di chiamate a WebServices utilizzando lo standard SOAP. Gli utenti configurati nel sistema possono identificarsi con username e password ed eseguire le operazioni. Il server oltre ad archiviare tutte le informazioni relative ai protocolli e ai servizi/privati mittenti/destinatari si occupa anche di conservare e gestire l archivio dei file digitali collegati ai singoli protocolli. Il sistema si servirà quindi anche di un applicativo SCANNER per la digitalizzazione del cartaceo. Quando un protocollo viene ricevuto deve essere distribuito ai vari uffici di competenza. Gli uffici rappresentati dai servizi vengono prima configurati secondo la gerarchia dell amministrazione e ad ognuno di essi assegnati i responsabili e collaboratori. Quando il protocollo viene digitalizzato e distribuito, ogni responsabile identificato al sistema può prendere visione dei propri documenti e salvarli nei propri fascicoli, oppure deviarli ad un proprio collaboratore o responsabile servizio annesso che ha l incarico di elaborarli. In questo modo il sistema tiene traccia del documento e conosce il responsabile che ne è in possesso. L applicativo dialogherà con l infrastruttura CART per scambiarsi i protocolli con le altre amministrazioni aderenti al progetto del protocollo informatico o privati in possesso di posta elettronica certificata. Notificherà: Le varie anomalie in fase di invio L avvenuta ricezione dei protocolli in ingresso L eventuale aggiornamento al mittente su eventi rilevanti in fase di ricezione Comunicazione di annullamento protocollo al mittente

5 2. Architettura dell applicativo L operatore del protocollo interagendo con l interfaccia dell applicativo può attraverso il WebService Protocollo effettuare le operazioni per la pubblicazioni di messaggi sul CART. Il WebService Anagrafica è utile per la richiesta di nominativi esistenti già in rubrica. Ad ogni operazione di protocollo il WebService Protocollo viene incaricato di registrare i dati nel Database, salvare il file digitale nel repository e referenziarlo con il record e dialogare con il WebService Invio/Ricezione messaggi che si occupa di preparare i messaggi e ricevere dal Proxy Protocollo tornando l esito al WebService Protocollo.

6 Servizio di aggiornamento Oltre all operatore del protocollo che è responsabile delle procedure di protocollazione in entrata e in uscita, sul Server Navo gira anche un Servizio di aggiornamento permanente che oltre ad aggiornare lo stato dei protocolli in funzione di aggiornamenti, annullamenti o richieste di lettura del mittente gestisce anche una coda di messaggi (protocollo e notifica ) in attesa di invio nel caso di errori sul proxy al momento del dialogo. Di Default lo scheduler fa una richiesta di messaggi ogni 5 min ed elabora nuove richieste in attesa. Questo valore può essere impostato da pannello di configurazione. Sempre da pannello di configurazione possono essere specificate le mail da notificare in caso di errori in fase di ricezione o invio e il tempo di attesa prima che lo scheduler faccia un nuovo tentativo. Di default ogni 30 minuti fa un nuovo tentativo. 3. Casi d uso Diagramma in sintesi dei casi d uso.

7 ID Use Case Descrizione UCD_01 Registrazione protocollo in uscita Operatore del protocollo Client Navo WebService Protocollo WebService Invio/Ricezione messaggi WebService Anagrafica Il sistema registra il protocollo e il documento digitale allegato. Prepara e pubblica il protocollo sul CART al destinatario specificato L utente ha effettuato l autenticazione al sistema Pubblicazione del messaggio sul CART che si occuperà di recapitarlo al proxy protocollo destinatario e archiviazione del protocollo sull applicativo SIL 1) L operatore specifica l oggetto del protocollo. a. L oggetto può essere anche aggiunto alla lista dei preferiti così da poterlo selezionare la volta successiva senza stare a scriverlo ogni volta 2) <<extension Point:tipo_destinatario>> 3) L operatore specifica il codice di classificazione del protocollo. Il sistema riconosce dalla stringa digitata se la classificazione è esistente o meno 4) Se l operatore ha già un documento digitale da allegare o se ha già archiviato nel Navo un file in un fascicolo allora specifica il file. 5) L operatore specifica il servizio o la persona fisica mittente del protocollo 6) L operatore può decidere se richiedere la conferma di ricezione da parte del destinatario. Di default l applicativo è impostato per non richiedere la conferma di ricezione 7) L operatore può decidere se il protocollo comporta per il mittente un ulteriore aggiornamento di conferma. Di default questa impostazione è False. 8) L operatore conferma i dati 9) Il WebService Protocollo registra il protocollo sul database assegnando il numero progressivo disponibile 10) Se il documento digitale è stato specificato, il WebService Protocollo salva il file nel repository e lo associa al record sul database 11) Se tutto avviene senza nessuna eccezione WebService Protocollo incarica WebService Invio/Ricezione messaggi di preparare un messaggio di trasporto di tipo Protocollo E-1 Messaggio protocollato con tutti i dati relativi al protocollo registrato e di pubblicarlo sul CART 12) Ricezione sincrona del messaggio ACKnowladge che indica l esito dell operazione (Positivo/Negativo). Viene aggiornato lo stato del protocollo in base all esito: Viene aggiornato lo stato del protocollo e viene informato l operatore del successo dell operazione Scenario di errore 13a ) Aggregazione del messaggio alla coda dei messaggi in attesa In caso di esito negativo verrà visualizzata la descrizione del problema. Il protocollo viene mantenuto registrato sul SIL mittente e se ne occuperà il servizio di aggiornamento che a intervalli regolari ripeterà l operazione di inoltro al proxy. Viene inoltre registrato l errore nello storico degli errori del protocollo in questione.

8 ID Use Case Descrizione Scenario di errore UCD_02 Inivo messaggio ad AOO interna al CART Operatore protocollo Client NAVO L operatore del protocollo seleziona il destinatario del messaggio L operatore del protocollo ha aperto la finestra per inviare un messaggio Il destinatario AOO interno è stato aggiunto 1. L operatore del protocollo apre la finestra di selezione del destinatario 2. Il Client Navo aggiorna l elenco AOO (<<include>> Aggiornamento elenco AOO) 3. L operatore del protocollo seleziona la AOO di destinazione 2a) nel caso in cui ci sia un problema di connessione l operatore non visualizzerà l elenco aggiornato alla data attuale e verrà informato a quale data è aggiornata la lista mostrata. ID Use Case Descrizione UCD_03 Aggiornamento dell indice della pubblica amministrazione regionale (IPAR) Operatore del protocollo Client Navo, Proxy AOO, WebServices Invio/Ricezione messaggi L operatore del protocollo seleziona l AOO di destinazione per l invio del messaggio. Apre quindi la finestra di selezione e il client navo invia una richiesta di variazioni rispetto all ultima data di aggiornamento per aggiornare la banca dati locale da mostrare all operatore L operatore del protocollo ha da selezionare la AOO di destinazione Banca dati aggiornata localmente 1) L operatore del protocollo apre la finestra di selezione AOO per l invio del messaggio 2) Il client NAVO invia la richiesta di aggiornamento delle AOO al Proxy AOO, invocando il metodo getvariazioniaoo 3) Il client NAVO invia la richiesta di aggiornamento delle UO al Proxy AOO, invocando il metodo getvariazioniuo 4) Per ogni variazione aggiorna la banca dati locale disponibile all operatore di protocollo tenendo di conto che per quanto riguarda le AOO, solo quelle con la flag AttivatoPaRtrt impostata su true valgono per il protocollo informatico Scenario di errore1 2a) Il client navo non riesce a contattare il proxy 2b) Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico Scenario di errore2 3a) Il client navo non riesce a contattare il proxy 3b) Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico

9 Note Da precisare che questo caso d uso è da considerarsi valido una volta che l applicativo è a regime, nel senso che ha già una banca dati sincronizzata con quella resa disponibile a livello pubblico. Come inizializzazione l applicativo dovrà costruire da zero la banca dati ricorrendo alla chiamata getallaoo(iniziopag, dimensionepag) per quanto riguarda le AOO e getalluo(iniziopag, dimensionepag) per quanto riguarda le UO ID Use Case Descrizione UCD_04 Inivo messaggio a Privato Operatore protocollo Client NAVO L operatore del protocollo seleziona il destinatario del messaggio Scenario alternativo 1 Scenario alternativo 2 Scenario di errore L operatore del protocollo ha aperto la finestra per inviare un messaggio Il destinatario privato è stato aggiunto 1. L operatore del protocollo apre la finestra di selezione del destinatario 2. Il Client Navo aggiorna l elenco AOO (<<include>> Aggiornamento elenco ADE) 3. L operatore del protocollo seleziona il destinazione dalla lista 4. Client Navo inserisce automaticamente PRI.WEB fra le AOO destinatarie 3a ) L operatore del protocollo decide di filtrare la lista di indirizzi specificando la provincia 3b) Client Navo recupera la lista filtrata interrogando il database locale già aggiornato all ultima variazione 3c)L operatore seleziona il destinatario 3a ) L operatore del protocollo decide di ricercare un destinatario per Codice fiscale o partita iva 3b) Client Navo recupera la lista filtrata interrogando il database locale già aggiornato all ultima variazione 3c)L operatore seleziona il destinatario 2a) nel caso in cui ci sia un problema di connessione l operatore non visualizzerà l elenco aggiornato alla data attuale e verrà informato a quale data è aggiornata la lista mostrata. ID Use Case Descrizione UCD_05 Aggiornamento banca dati ADE (Attributi di domicilio elettronico) Operatore del protocollo Client Navo, Proxy ADE, WebServices Invio/Ricezione messaggi L operatore del protocollo seleziona il privato di destinazione per l invio del messaggio. Apre quindi la finestra di selezione e il client navo invia una richiesta di variazioni rispetto all ultima data di aggiornamento per aggiornare la banca dati locale da mostrare all operatore L operatore del protocollo deve inviare un messaggio ad un privato Banca dati aggiornata localmente 1) L operatore del protocollo apre la finestra di selezione del Privato per l invio del messaggio

10 2) Il client NAVO invia la richiesta di aggiornamento ADE al Proxy ADE, invocando il metodo getvariazioniade 3) Per ogni variazione aggiorna la banca dati locale disponibile all operatore di protocollo. Scenario di errore 2a) Il client navo non riesce a contattare il proxy 2b) Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico Note Da precisare che questo caso d uso è da considerarsi valido una volta che l applicativo è a regime, nel senso che ha già una banca dati sincronizzata con quella resa disponibile a livello pubblico. Come inizializzazione l applicativo dovrà costruire da zero la banca dati ricorrendo alla chiamata getallade(iniziopag, dimensionepag) che ritorna la lista completa di tutti gli Attributi di domicilio elettronico registrati pubblicamente al momento. ID Use Case Descrizione UCD_06 Inivo messaggio ad AOO esterna al CART Operatore protocollo Client NAVO L operatore del protocollo seleziona il destinatario del messaggio Il destinatario AOO esterna è stato aggiunto Il destinatario è stato aggiunto 1. L operatore del protocollo specifica la PEC del destinatario Scenario di errore - ID Use Case Descrizione UCD_07 Registrazione protocollo in ingresso Operatore del protocollo Client Navo WebService Protocollo WebService Invio/Ricezione messaggi WebService Anagrafica Il client navo fa una richiesta a Web Service Protocollo per ottenere il successivo messaggio protocollo dalla coda dei messaggi in attesa di processione. L applicativo mostra all operatore il protocollo da processare ed esso lo registra in ingresso specificando il servizio responsabile destinatario. Poi il protocollo viene messo in coda per la distribuzione L utente ha effettuato l autenticazione al sistema Registrazione del protocollo e aggiornamento della coda di distribuzione. 1) L operatore recupera un messaggio dalla coda di messaggi protocollo in

11 attesa di essere processati 2) WebService Protocollo restituisce una lista di messaggi protocollo in attesa 3) L operatore seleziona il messaggio per estrapolare le informazioni. a. L oggetto può essere anche aggiunto alla lista dei preferiti così da poterlo selezionare la volta successiva senza stare a scriverlo ogni volta 4) In funzione dell indirizzo del mittente viene effettuata una ricerca per recuperare tutti i dati del contatto. Nel caso in cui il contatto non fosse presente l applicativo navo dialoga con il WebService Anagrafica per aggiungere il nuovo contatto con tutti i dati completi 5) L operatore specifica il codice di classificazione del protocollo. Il sistema riconosce dalla stringa digitata se la classificazione è esistente o meno 6) L operatore specifica il servizio destinatario del protocollo 7) L operatore specifica i servizi da mettere in copia conoscenza per la visione di questo protocollo 8) L operatore conferma i dati 9) Il WebService Protocollo registra il protocollo sul database assegnando il numero progressivo disponibile. Salva il file, estrapolato dal messaggio, nel repository e lo associa al record sul database 10) Se tutto avviene senza nessuna eccezione il WebService Protocollo controlla se il messaggio chiedeva una conferma da parte del mittente. In questo caso WebService Invio/Ricezione messaggi viene incaricato di preparare un messaggio di trasporto di tipo E-2 Conferma ricezione che comunica al mittente la corretta ricezione e processione del documento 11) Ricezione sincrona di un messaggio di ACKnowledge con la comunicazione dell esito dell operazione. Il record del protocollo viene aggiornato al nuovo stato consegnato. 12) Il protocollo adesso può essere distribuito negli uffici Scenario di errore 11a ) In caso di esito negativo il record del protocollo non verrà aggiornato e il protocollo verrà mantenuto nella lista dei protocolli ancora da essere notificati al mittente. Se ne occuperà il servizio di aggiornamento che ad intervalli ripeterà l inoltro ID Use Case Descrizione UCD_08 Digitalizzazione documento per protocollo in uscita Operatore del protocollo Applicativo scanner WebService Protocollo WebService Invio/Ricezione messaggi Dallo scanner viene preso il documento cartaceo e digitalizzato. L operatore a quel punto può selezionare il protocollo in uscita ancora in attesa di un documento primario. Una volta associato il file il protocollo viene pubblicato sul CART. L utente ha effettuato l autenticazione al sistema L utente ha un protocollo in uscita senza ancora un documento associato Protocollo in uscita pubblicato sul CART 1) L operatore passa il cartaceo dallo scanner 2) L applicativo scanner fa un batch dei fogli cartacei e crea un unico pdf pronto per essere referenziato.

12 3) L applicativo scanner propone i protocolli non ancora associati ad un file digitale 4) L operatore seleziona il protocollo e conferma l associazione con la scansione fatta 5) Il WebService Protocollo salva il file nel repository e lo associa al record sul database 6) Se tutto avviene senza nessuna eccezione WebService Protocollo incarica WebService Invio/Ricezione messaggi di preparare un messaggio di trasporto di tipo Protocollo E-1 Messaggio protocollato con tutti i dati relativi al protocollo registrato e di pubblicarlo sul CART 7) WebService Protocollo riceve un messaggio di ACKnowledge per comunicare l esito dell operazione Scenario di errore 7a ) Aggregazione del messaggio alla coda dei messaggi in attesa In caso di esito negativo verrà visualizzato la descrizione del problema. Il protocollo viene mantenuto registrato sul SIL mittente e il servizio di aggiornamento si occuperà di ripetere l inoltro ad intervalli regolari. Viene inoltre registrato l errore nello storico degli errori del protocollo in questione ID Use Case Descrizione UCD_09 Notifica di accettazione protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento scarica un messaggio di trasporto Notifica di tipo E1 Messaggio di accettazione e aggiorna lo stato del protocollo ad accettato contrassegnando il protocollo da leggere per l operatore del protocollo Che esista un messaggio di notifica E1 da essere processato Aggiornamento stato del protocollo 1) Il servizio di aggiornamento scarica il messaggio di trasporto notifica di tipo E1 Messaggio di accettazione dal Proxy Protocollo 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio da parte di Web Service Protocollo 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) WebService Protocollo aggiorna lo stato del protocollo di riferimento come accettato contrassegnando il protocollo da leggere per l operatore del protocollo Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico

13 ID Use Case Descrizione UCD_10 Notifica di non accettazione protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento scarica un messaggio di Notifica di tipo E2 Messaggio di non accettazione e aggiorna lo stato del protocollo a non accettato con tutte le specifiche dell errore, contrassegnando il protocollo da leggere per l operatore del protocollo Che esista un messaggio di notifica E2 da essere processato Aggiornamento stato del protocollo 1) Il servizio di aggiornamento scarica il messaggio di trasporto notifica di tipo E2 Messaggio di non accettazione dal Proxy Protocollo 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio da parte di Web Service Protocollo 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) WebService Protocollo aggiorna lo stato del protocollo di riferimento come non accettato contrassegnando il protocollo da leggere per l operatore del protocollo Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case Descrizione UCD_11 Notifica di consegna protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento scarica un messaggio un Messaggio di trasporto Notifica di tipo E3 Messaggio di avvenuta consegna e aggiorna lo stato del protocollo come consegnato contrassegnando il protocollo da leggere per l operatore del protocollo Che esista un messaggio di notifica E3 da essere processato Aggiornamento stato di consegna 1) Il servizio di aggiornamento scarica il messaggio di trasporto notifica di tipo E3 Messaggio di avvenuta consegna dal Proxy Protocollo 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio da parte di Web Service Protocollo 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per

14 comunicare la corretta ricezione del messaggio 5) WebService Protocollo aggiorna lo stato del protocollo di riferimento come consegnato contrassegnando il protocollo da leggere per l operatore del protocollo Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case Descrizione UCD_12 Notifica di errore di consegna protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento scarica un messaggio di trasporto Notifica di tipo E4 Messaggio di errore di consegna e aggiorna lo stato del protocollo come non consegnato con specifiche sull errore contrassegnando il protocollo da leggere per l operatore del protocollo Che esista un messaggio di notifica E4 da essere processato Aggiornamento stato di consegna 1) Il servizio di aggiornamento scarica il messaggio di trasporto notifica di tipo E4 Messaggio di avvenuta consegna dal Proxy Protocollo 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio da parte di Web Service Protocollo 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) WebService Protocollo aggiorna lo stato del protocollo di riferimento come non consegnato con specifiche sull errore contrassegnando il protocollo da leggere per l operatore del protocollo Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case UCD_13 Comunicazione di aggiornamento Operatore del protocollo Client NAVO WebService Protocollo WebService Invio/Ricezione messaggi

15 Descrizione Se il protocollo ricevuto dall operatore comporta l inizio di qualche attività, procedura o collegamento ad un processo più vasto e nel caso in cui il mittente ne richieda un aggiornamento di conferma, l operatore deve comunicarlo. Il sistema per questo pubblicherà sul CART un messaggio di trasporto protocollo di tipo E-4 Aggiornamento di conferma con la descrizione di tutti gli eventi accaduti. L utente ha effettuato l autenticazione al sistema L utente ha una richiesta di aggiornamento di conferma sul protocollo Aggiornamento stato del protocollo 1) L operatore specifica l aggiornamento da segnalare 2) L operatore conferma i dati inseriti 3) Il WebService invia/ricevi messaggi invia un messaggio di trasporto protocollo di tipo E-4 Aggiornamento di conferma 4) Il WebService invia/ricevi messaggi ricevi dal proxy un messaggio di ACKnowledge per l esito positivo dell operazione 5) L aggiornamento sul protocollo viene confermato ed accertato Scenario di errore 4a ) Se l esito è negativo la richiesta non è stata inoltrata quindi rimane sospesa ed in coda. Viene messa in coda ai messaggi da inoltrare e processata dal servizio di aggiornamento. 4b ) All operatore viene mostrata la descrizione dell errore verificatosi. ID Use Case Descrizione UCD_14 Annullamento del protocollo Operatore del protocollo Client NAVO WebService Protocollo WebService Invio/Ricezione messaggi Se l operatore del protocollo ritiene non valido, non idoneo il contenuto del protocollo può effettuare un annullamento che comporta delle valide motivazioni. Il WebService Invio/Ricezione messaggi prepara un messaggio di trasporto protocollo di tipo E-5 Annullamento protocollazione L utente ha effettuato l autenticazione al sistema L utente ha un protocollo non idoneo da annullare Protocollo annullato 1) L operatore specifica le motivazioni dell annullamento 2) L operatore conferma i dati 3) Il WebService invia/ricevi messaggi invia un messaggio di trasporto protocollo di tipo E-5 Annullamento protocollazione 4) Il WebService invia/ricevi messaggi ricevi dal proxy un messaggio di ACKnowledge per l esito positivo dell operazione 5) Il protocollo viene annullato Scenario di errore 4a )

16 Se l esito è negativo il mittente non verrà informato dell annullamento quindi il protocollo non è da considerarsi annullato. Rimane in attesa di conferma annullamento. Il servizio di aggiornamento si occupa di inoltrare il messaggio appena il proxy sarà disponibile 4b ) All operatore viene mostrata la descrizione dell errore verificatosi. ID Use Case Descrizione Scenario di errore UCD_15 Ricezione conferma ricezione protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento riceve dal proxy un messaggio di trasporto protocollo di tipo E-2 Conferma ricezione per comunicare il la corretta ricezione di un messaggio di trasporto protocollo di tipo E-1 Messaggio protocollato. Viene contrassegnato il protocollo di riferimento come letto L utente ha effettuato l autenticazione al sistema L utente ha un protocollo inviato in attesa di essere letto Aggiornamento storico errori del protocollo 1) Il servizio di aggiornamento scarica il messaggio di trasporto protocollo di tipo E-2 Conferma ricezione 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) Il protocollo viene contrassegnato come letto 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case Descrizione UCD_16 Ricezione eccezione protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento riceve dal proxy un messaggio di trasporto protocollo di tipo E-3 Notifica di eccezione per comunicare il verificarsi di un eccezione in riferimento ad un messaggio di trasporto protocollo di tipo E-1 Messaggio protocollato. Viene aggiornato lo storico errori del protocollo con la descrizione dell errore L utente ha effettuato l autenticazione al sistema L utente ha un protocollo non idoneo da annullare

17 Scenario di errore Aggiornamento storico errori del protocollo 6) Il servizio di aggiornamento scarica il messaggio di trasporto protocollo di tipo E-3 Notifica di eccezione 7) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 8) Lettura del messaggio 9) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 10) L eccezione viene registrata nello storico errori del protocollo 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case Descrizione Scenario di errore UCD_17 Ricezione aggiornamento di conferma Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento riceve dal proxy un messaggio di trasporto protocollo di tipo E-4 Aggiornamento di conferma per comunicare un evento rilevante verificatosi durante la ricezione presso il SIL ricevente di un messaggio protocollo di tipo E-1 Messaggio protocollato. Viene aggiornato lo stato del protocollo inviato L utente ha effettuato l autenticazione al sistema L utente ha inviato un protocollo con la conferma di aggiornamento specificata da parte del ricevente (Vedi punto 7 di UCD_01) Aggiornamento storico errori del protocollo 1) Il servizio di aggiornamento scarica il messaggio di trasporto protocollo di tipo E-4 Aggiornamento di conferma 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) Lo stato del protocollo viene aggiornato 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case Descrizione UCD_18 Ricezione annullamento protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento riceve dal proxy un messaggio di trasporto protocollo

18 di tipo E-5 Annullamento protocollazione per comunicare l annullamento da parte del SIL ricevente di un messaggio protocollo di tipo E-1 Messaggio protocollato. Viene annullato il protocollo inviato Scenario di errore L utente ha effettuato l autenticazione al sistema Aggiornamento storico errori del protocollo 1) Il servizio di aggiornamento scarica il messaggio di trasporto protocollo di tipo E-5 Annullamento protocollazione 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) Il protocollo viene annullato 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case UCD_19 Ricezione messaggio di protocollo Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Descrizione Il servizio di aggiornamento scarica un messaggio di trasporto protocollo di tipo E-1 Messaggio protocollato. Il messaggio viene salvato e messo in coda ai messaggi da processare da parte dell operatore di protocollo. Esiste un messaggio di protocollo da scaricare Aggiornamento coda dei protocolli da processare dall operatore 1) Il servizio di aggiornamento scarica il messaggio di trasporto protocollo di tipo E-1 Messaggio protocollato 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura e salvataggio del messaggio da parte di Web Service Protocollo 4) Aggiunta del messaggio alla coda dei protocolli da processare. Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, Web Service invio/ricezione messaggi registra nel log degli eventi l errore di connessione ed invia una di notifica al responsabile tecnico ID Use Case UCD_20

19 Descrizione Coda dei messaggi in attesa di invio Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento ogni volta che un invio di messaggio al proxy fallisce con risposta ACKnowledge negativa, inserisce il messaggio in una coda di messaggi ancora da inoltrare AckNowledge negativo in risposta all invio di un messaggio protocollo Messaggio inoltrato e rimosso dalla coda 1) Recupero del messaggio alla coda dei messaggi in attesa di invio. 2) A intervalli regolari fa un tentativo di inoltro inviando nuovamente il messaggio al proxy protocollo 3) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito positivo dell invio 4) Rimozione del messaggio dalla coda di messaggi in attesa di invio Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, il messaggio rimane registrato nella coda e attende il successivo intervallo ID Use Case Descrizione UCD_21 Ricezione messaggi di comunicazione a soggetti esterni Servizio di aggiornamento WebService Protocollo WebService Invio/Ricezione messaggi Il servizio di aggiornamento scarica un messaggio di comunicazione che può essere E1 Messaggio anomalia di trasporto Viene inviato da un'apposita applicazione dislocata su CART quando il server di posta certificata di RT riceve una mail da un sistema di posta non certificata oppure quando riceve una mail da un sistema di posta certificata ma falliscono controlli formali (firma non presente o non valida). E2 "Comunicazione da soggetto non pubblico accreditato via web" Viene generato da un'apposita applicazione dislocata su CART che crea il messaggio a partire dai dati inseriti da un soggetto non pubblico accreditato (in possesso di un certificato rilasciato da una CA riconosciuta da RT) attraverso un'interfaccia web. Comunicazione-E3 : "Comunicazione da soggetto non pubblico accreditato via intermediario certificato" Viene inviato quando il server di posta certificata di RT riceve una mail inviata da soggetto non pubblico accreditato attraverso un sistema intermediario di posta certificata.

20 Aggiorna il database delle comunicazioni e notifica per Nessuna Aggiornamento database 1) Ricezione di un messaggio di tipo comunicazione di tipo E1,E2 o E3 2) Il WebService invia/ricevi messaggi riceve un ACKnowledge con l esito della ricezione 3) Lettura del messaggio 4) Il WebService invia/ricevi messaggi invia un ACKnowledge per comunicare la corretta ricezione del messaggio 5) Il database delle comunicazioni viene aggiornato Scenario di errore 2a ) Nel caso in cui l ACKNowledge da esito negativo, il messaggio rimane registrato nella coda e attende il successivo intervallo ed invia una di notifica al responsabile tecnico ID Use Case Descrizione UCD_22 Comunicazione di notifica eccezione Operatore del protocollo Client NAVO WebService Protocollo WebService Invio/Ricezione messaggi Se il protocollo ricevuto dall operatore presenta eventuali anomalie, l operatore deve comunicarlo al mittente. Il sistema per questo pubblicherà sul CART un messaggio di trasporto protocollo di tipo E-3 Notifica eccezione con la descrizione di tutte le anomalie riscontrate. L utente ha effettuato l autenticazione al sistema L utente ha ricevuto un protocollo che presenta alcune anomalie Aggiornamento stato del protocollo 1) L operatore specifica le anomalie riscontrate 2) L operatore conferma i dati inseriti 3) Il WebService invia/ricevi messaggi invia un messaggio di trasporto protocollo di tipo E-3 Notifica eccezione 4) Il WebService invia/ricevi messaggi ricevi dal proxy un messaggio di ACKnowledge per l esito positivo dell operazione 5) L aggiornamento dello stato del protocollo viene confermato Scenario di errore 4a ) Se l esito è negativo la richiesta non è stata inoltrata quindi rimane sospesa ed in coda. Viene messa in coda ai messaggi da inoltrare e processata dal servizio di aggiornamento. 4b ) All operatore viene mostrata la descrizione dell errore verificatosi.

21 6. Diagrammi di sequenza 01 Scenario di registrazione protocollo in uscita

22 02 Invio messaggio ad una AOO interna al CART (UCD 02, UCD 03)

23 03 Invio messaggio ad un soggetto privato (UCD 04, UCD 05) 06 Invio messaggio ad una AOO esterna al CART

24 07 Scenario di registrazione protocollo in ingresso

25 08 Scenario di associazione file digitale da applicativo scanner

26 09 Scenario di ricezione notifiche (UCD 09, UCD 10, UCD 11, UCD 12)

27 13 Scenario di aggiornamento di conferma

28 14 Scenario di annullamento protocollo

29 15 Scenario ricezione conferma ricezione protocollo

30 16 Scenario ricezione notifica di eccezione

31 17 Scenario ricezione aggiornamento di conferma

32 18 Scenario ricezione annullamento protocollazione

33 19 Scenario di ricezione nuovi messaggi protocollo

34 20 Scenario di gestione della coda messaggi

35 21 Ricezione messaggi di comunicazione

36 22 Comunicazione di notifica di eccezione

37 7. Descrizione dell interfaccia In figura è mostrato il modulo del protocollo pronto per registrare un protocollo in uscita In alto a destra le 7 cifre ancora non assegnate al protocollo che sta per essere processato. L oggetto deve essere specificato e attraverso il pulsante + può essere memorizzato per un riutilizzo successivo. E obbligatoria la specifica del tipo che può essere Documento cartaceo tradizionale PEC Fax Raccomandata Prioritaria Ecc Figura 1 Per la classificazione è necessario specificare il codice dopodiché il sistema si accerta dell esistenza e se non trova nessuna corrispondenza evidenzia il campo di rosso altrimenti passando il mouse sul pulsante? appare in un fumetto il dettaglio della classificazione specificata.

38 Se esiste un file digitale può essere allegato, sia da file che da archivio. Da archivio significa che l applicativo aprirà il modulo dell archivio e permetterà all utente di selezionare il file già presente nel repository. Per la selezione invece del destinatario è possibile effettuare una ricerca e selezionare il record dalla lista di risultati. Oppure inserirne uno nuovo dall apposito menu evidenziato anche nella figura. Figura2 Questa finestra si apre se l utente decide di selezionarlo o aggiungerlo, altrimenti può limitarsi a compilare i campi del modulo in figura 1. Per aprire questa finestra l utente preme sul pulsante delle 3 faccine accanto al campo Destinatario. I campi automaticamente si riempiranno alla selezione del contatto.

39 Alla fine dell operazione, la cifra del protocollo è stata assegnata e la procedura è conclusa. Il protocollo è stato trasmesso al CART nel caso di documento digitale presente, altrimenti messo nello stato di attesa di associazione che l operatore dovrà procedere a fare tramite l applicativo scanner. Figura 3

40 Figura 4 Per quanto riguarda invece l interazione con il CART dell applicativo nel caso di ricezione di un protocollo, l operatore dovrà richiedere i nuovi messaggi da processare. Tra i nuovi messaggi possono esserci 8. Nuovi protocolli da registrare 9. Notifiche su protocolli già processati 10. Aggiornamenti per protocolli già processati Per iniziare un elaborazione l operatore deve selezionare il messaggio e automaticamente il modulo del protocollo in ingresso viene compilato per tutti i campi che già conosce. I campi rimanenti vengono compilati dall operatore dopodiché la procedure è la stessa vista per il primo caso d uso. Viene assegnata una cifra al protocollo e viene comunicato al CART eventuali variazioni, annullamenti o conferme di lettura.