1 1 Casi d uso 1.1 Anagrafica Anagrafica privati: sincronizzazione completa iniziale LOOP Recupera contatti 1 : Invio richiesta - pagina n: getade() 2 : Dati pagina n 3 : BPM aggiorna il database locale - pagina n() ID 1 Nome Anagrafica privati Descrizione Sincronizzazione completa iniziale BPM Orchestrator modulo di inizializzazione invocato all avvio del sistema Attori secondari Scenario 1. Il modulo effettua tante chiamate (GetAde RFC 122.7) verso il proxy per ricavare i contatti di ciascuna pagina 2. Il proxy restituisce i dati paginati 3. Il modulo aggiorna il database dell applicazione Scenario Errore Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
2 Anagrafica privati: aggiornamento LOOP Recupera contatti 1 : Invio richiesta: getvariazioniade() 2 : Dati aggiornati 3 : BPM aggiorna il database locale() ID 2 Nome Anagrafica privati 2 Descrizione Aggiornamento Anagrafica privati BPM Orchestrator modulo schedulato a frequenza impostabile, tipicamente una volta al giorno, di notte. Attori secondari Scenario 1. Il modulo effettua una chiamata (getvariazioniade RFC 122.7) verso il proxy per ricavare i dati nuovi o modificati dell anagrafica privati 2. Il proxy restituisce i dati aggiornati 3. Il modulo aggiorna il database dell applicazione Scenario Errore Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
3 Anagrafica AOO: sincronizzazione completa iniziale LOOP Recupera contatti 1 : Invio richiesta - pagina n: getallaoo() 2 : Dati pagina n 3 : BPM aggiorna il database locale - pagina n() ID 3 Nome Anagrafica AOO Descrizione Sincronizzazione completa iniziale BPM Orchestrator modulo di inizializzazione invocato all avvio del sistema Attori secondari Scenario 1. Il modulo effettua tante chiamate (getallaoo RFC 110.5) verso il proxy per ricavare i contatti di ciascuna pagina 2. Il proxy restituisce i dati paginati 3. Il modulo aggiorna il database dell applicazione Scenario Errore Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
4 Anagrafica AOO: aggiornamento LOOP Recupera contatti 1 : Invio richiesta: getvariazioniaoo() 2 : Dati aggiornati 3 : BPM aggiorna il database locale() ID 4 Nome Anagrafica AOO 2 Descrizione Aggiornamento Anagrafica AOO BPM Orchestrator modulo schedulato a frequenza impostabile, tipicamente una volta al giorno, di notte. Attori secondari Scenario 1. Il modulo effettua una chiamata (getvariazioniaoo RFC 110.5) verso il proxy per ricavare i dati nuovi o modificati dell anagrafica privati 2. Il proxy restituisce i dati aggiornati 3. Il modulo aggiorna il database dell applicazione Scenario Errore Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
5 Anagrafica UO: sincronizzazione completa iniziale LOOP Recupera contatti 1 : Invio richiesta - pagina n: getalluo() 2 : Dati pagina n 3 : BPM aggiorna il database locale - pagina n() ID 5 Nome Anagrafica UO Descrizione Sincronizzazione completa iniziale BPM Orchestrator modulo di inizializzazione invocato all avvio del sistema Attori secondari Scenario 1. Il modulo effettua tante chiamate (getalluo RFC 110.5) verso il proxy per ricavare i contatti di ciascuna pagina 2. Il proxy restituisce i dati paginati 3. Il modulo aggiorna il database dell applicazione Scenario Errore Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
6 Anagrafica UO: aggiornamento LOOP Recupera contatti 1 : Invio richiesta: getvariazioniuo() 2 : Dati aggiornati 3 : BPM aggiorna il database locale() ID 6 Nome Anagrafica UO 2 Descrizione Aggiornamento Anagrafica UO BPM Orchestrator modulo schedulato a frequenza impostabile, tipicamente una volta al giorno, di notte. Attori secondari Scenario 1. Il modulo effettua una chiamata (getvariazioniuo RFC 110.5) verso il proxy per ricavare i dati nuovi o modificati dell anagrafica privati 2. Il proxy restituisce i dati aggiornati 3. Il modulo aggiorna il database dell applicazione Scenario Errore Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
7 1.2 Invio di messaggi di protocollo La procedura di invio di un messaggio di protocollo è divisa in due parti: 1. Predisposizione / Invio logico di un messaggio 2. Invio fisico del messaggio La predisposizione dell invio/invio logico di un messaggio di protocollo prevede la possibilità di impostare un elenco di destinatari associati al messaggio, recuperati dall anagrafica di ArchiflowWEB, il documento del messaggio ed una serie di documenti allegati. L applicativo prevede che la predisposizione dell invio di un protocollo (E1) possa essere eseguita da un utente, mentre l invio logico possa essere eseguito da un altro utente che ha visibilità sul protocollo. Dopo aver completato la predisposizione dell invio del messaggio di protocollo, l utente, tramite il bottone Spedisci, avvia la procedura di invio logico del messaggio di protocollo durante la quale l applicativo ArchiflowWEB si connette al servizio di accodamento del motore BPM creando un record nel database di spedizione relativo all invio di messaggi di protocollo (E1). Cliccare Spedisci per l invio logico del documento. Predisporre i dati per l invio. L invio fisico prevede che il motore di spedizione BPM recuperi il messaggio dal database di invio di messaggi di protocollo, si colleghi all infrastruttura InterPro ed invii fisicamente il messaggio tramite le chiamate dei metodi putprotocollo (E1), putprotocollorisposta (E2, E3, E4, E5).
8 Predisposizione messaggio Interoperabilità La predisposizione dei messaggi di interoperabilità fa riferimento all invio di messaggi protocollati verso Enti o verso privati. ArchiflowWEB, personalizzato per la Regione Toscana, esegue la spedizione dei messaggi sia verso Enti sia verso Privati esclusivamente tramite il canale di InterPro. /Archiflow / : Actor 1 : Selezione protocollo da spedire() 2 : Selezione destinatari e definizione messaggio() 3 : Selezione allegati da spedire() 4 : Spedizione() 5 : Composizione messaggio() 6 : Salvataggio in DB temporaneo() 7 : In Spedizione ID 7 Nome Predisposizione Descrizione Predisposizione messaggio interoperabilità ArchiflowWEB Attori secondari BPM Engine Scenario 1. L utente seleziona il protocollo con i documenti da inviare 2. L utente definisce Oggetto, corpo del messaggio e seleziona destinatari e destinatari in CC 3. L utente seleziona gli eventuali allegati del protocollo da inviare con il
9 Scenario Errore messaggio 4. L utente clicca il pulsante Spedisci 5. ArchiflowWEB compone il messaggio e lo invia al BPM Engine 6. Il BPM Engine memorizza il messaggio in un database temporaneo 7. Il protocollo viene marcato In spedizione Lo stato del protocollo non verrà marcato In spedizione ed un messaggio descrittivo segnalerà l errore all utente Invio fisico messaggio Interoperabilità L applicativo ArchiflowWEB personalizzato per Regione Toscana utilizza InterPro (Gateway PEC) per l invio di qualsiasi tipo di messaggio a qualsiasi tipo di destinatario, anche verso PEC esterna ad InterPro. /DB di transito Scheduler Task schedulato 1 : Richiesta dati messaggio() 2 : Restituzione messaggio 3 : Invio messaggio: putprotocollo - RFC 218() 4 : Stato aggiornato in 'Spedito' ID 8 Nome Invio Descrizione Invio fisico messaggio interoperabilità La BPM Engine prende in carico il messaggio da inviare in modalità asincrona impostabile, tipicamente ogni 5 minuti. Attori secondari Database di transito Scenario 1. Il BPM Engine consulta il database temporaneo per leggere eventuali nuovi messaggi da spedire (task schedulato) 2. Il DB di transito restituisce i dati dei messaggi da inviare 3. Prima di inviare il messaggio, il sistema ne analizza i destinatari allo
10 Scenario Errore scopo di capire se si tratti di Enti o privati. In caso il messaggio sia indirizzato ad uno o più privati, il sistema provvede a modificare il file Segnatura.xml nel modo opportuno. 4. Il BPM Engine chiama il metodo (putprotocollo RFC 218) con i dati letti dal database di transito. In caso il messaggio sia indirizzato ad una PEC esterna ad InterPro, il sistema chiama il metodo putprotocollo nel modo opportuno. 5. Il protocollo verrà aggiornato con lo stato Spedito Lo stato del protocollo non verrà marcato Spedito ed un messaggio descrittivo segnalerà l errore all utente Invio dei messaggi di notifica L invio di messaggi di protocollo di risposta (E2, E3, E4, E5) segue lo stesso iter applicativo dell invio (E1) ma i messaggi vengono generati automaticamente alla protocollazione di un messaggio di interoperabilità in ingresso/rifiuto della protocollazione di un messaggio di interoperabilità in ingresso/annullamento di un protocollo legato ad un messaggio di interoperabilità in ingresso. /DB di transito Scheduler Task schedulato 1 : Richiesta dati messaggio() 2 : Restituzione messaggio 3 : Invio messaggio: putprotocollorisposta - RFC 218() 4 : Stato aggiornato in 'Spedito' ID 9 Nome Notifica Descrizione Invio dei messaggi di notifica La BPM Engine prende in carico il messaggio da inviare in modalità asincrona impostabile, tipicamente ogni 5 minuti. Attori secondari Database di transito
11 Scenario Scenario Errore 1. Il BPM Engine consulta il database temporaneo per leggere eventuali nuovi messaggi da spedire (task schedulato) 2. Il DB di transito restituisce i dati dei messaggi da spedire 3. Il BPM Engine chiama il metodo (putprotocollorisposta RFC 218) con i dati letti dal database di transito Lo stato di spedizione viene marcato come errato ed un messaggio descrittivo segnalerà l errore all utente 1.3 Ricezione dei messaggi di interoperabilità Ricezione messaggio di interoperabilità L applicativo ArchiflowWEB, nella procedura di ricezione, si appoggia all infrastruttura InterPro utilizzando i metodi gelallids e getmessaggio. Dopo aver scaricato un messaggio da InterPro, il sistema cerca di analizzarne la tipologia distinguendo: a) messaggi di Protocollo (E1) provenienti da Enti o da privati, b) messaggi non conformi alle specifiche di Protocollo provenienti da Gateway PEC, c) messaggi di protocollo di risposta della tipologia E2/E3/E4/E5 (Conferma Ricezione/Notifica Eccezione/Aggiornamento/Annullamento Protocollazione), d) messaggi di notifica E1/E2/E3/E4 (accettazione / non accettazione / avvenuta consegna / errore di consegna) prodotti dall'infrastruttura InterPro. Protocolli ricevuti.
12 /Archiflow 1 : Invio richiesta identificativi nuovi messaggi() 2 : Restituzione lista id 3 : Richiesta messaggio() 4 : Restituzione messaggio 5 : Archiviazione messaggio() 6 : Archiviazione OK 7 : Conferma ricezione corretta() ID 10 Nome Ricezione Descrizione Ricezione messaggio interoperabilità La BPM Engine verifica l esistenza di messaggi presenti nel Proxy in modalità asincrona impostabile, tipicamente ogni 5 minuti. Le successive richieste al Proxy sono immediate. Attori secondari ArchiflowWEB Scenario 1. Il motore BPM, ad intervalli regolari, richiede (getallids 218) la lista degli identificativi di tutti i messaggi disponibili 2. Il Proxy Protocollo restituisce la lista degli ID 3. Il motore BPM richiede (getmessaggio 218) il messaggio con un ID specificato 4. Il Proxy Protocollo restituisce il messaggio richiesto 5. Il motore BPM recapita il messaggio ad ArchiflowWEB: a) In caso di messaggi di Protocollo (E1) provenienti da Enti o da privati, il sistema archivia il messaggio come una bozza di messaggio di protocollo in ingresso recuperando dallo stesso le informazioni che lo caratterizzano (Mittente, Data spedizione, Data ricezione, ecc.). I dati salvati nel file Segnatura.xml vengono conservati lato
13 Scenario Errore database per distinguere il messaggio dalle altre tipologie di messaggi in ingresso. b) In caso di messaggi non conformi alle specifiche di Protocollo provenienti da Gateway PEC, il sistema archivia il messaggio come una bozza di messaggio di protocollo in ingresso recuperando dallo stesso le informazioni che lo caratterizzano (Mittente, Data spedizione, Data ricezione, ecc.). c) In caso di messaggi di protocollo di risposta della tipologia E2/E3/E4/E5 il sistema, basandosi sui dati del protocollo, trova nel proprio database il messaggio di protocollo in uscita di riferimento e ne aggiorna lo stato. Il corpo del messaggio viene salvato nel database del sistema per l eventuale successiva consultazione. d) In caso di messaggi di notifica E1/E2/E3/E4 prodotti dall'infrastruttura InterPro, il sistema aggiorna lo stato del messaggio di protocollo in uscita di riferimento rintracciato tramite l ID contenuto all interno del messaggio di notifica. Il corpo del messaggio viene salvato nel database del sistema per l eventuale successiva consultazione. 6. ArchiflowWEB conferma l archiviazione del messaggio 7. Il motore BPM conferma (sendack 218) al Proxy Protocollo la ricezione corretta del messaggio con l'identificativo specificato Ad ogni attività viene associato un record nel database contenente le informazioni sullo stato di avanzamento e su eventuali errori
14 Sommario 1 CASI D USO... 1 1.1 ANAGRAFICA...1 Anagrafica privati: sincronizzazione completa iniziale... 1 Anagrafica privati: aggiornamento... 2 Anagrafica AOO: sincronizzazione completa iniziale... 3 Anagrafica AOO: aggiornamento... 4 Anagrafica UO: sincronizzazione completa iniziale... 5 Anagrafica UO: aggiornamento... 6 1.2 INVIO DI MESSAGGI DI PROTOCOLLO...7 Predisposizione messaggio Interoperabilità... 8 Invio fisico messaggio Interoperabilità... 9 Invio dei messaggi di notifica... 10 1.3 RICEZIONE DEI MESSAGGI DI INTEROPERABILITÀ... 11 Ricezione messaggio di interoperabilità... 11 SOMMARIO... 14