Il workflow di un servizio
Una volta creato, un servizio segue un workflow che determina:
i nomi degli stati;
gli attori che possono effettuare ciascun cambio di stato;
i campi richiesti per transitare in un dato stato.
Nota
Lo stato del servizio è una macchina a stati pilotata da configurazione (si veda Concetti trasversali: ambienti, stati, visibilità). I nomi degli stati e le regole di transizione possono variare da un'installazione all'altra. La sequenza descritta di seguito è quella di default e serve a illustrare il processo tipico di pubblicazione di un servizio.
Attori coinvolti
Qualunque utente, può vedere i servizi almeno pubblicati in collaudo, tramite la consultazione pubblica.
Richiedente, un qualsiasi utente che ha avviato la creazione di un servizio assume questo ruolo; può completare i dati di configurazione per portare il servizio in richiesto in collaudo o richiesto in produzione.
Referente Servizio (ruolo derivato, si veda Struttura dei ruoli ), chi ha creato il servizio, o vi è stato assegnato come referente. Ha gli stessi diritti del richiedente sul workflow del servizio, con in più i poteri di gestione delle adesioni ricevute (si veda Adesioni).
Referente Tecnico, utente assegnato al supporto tecnico della compilazione. Può vedere e modificare i dati del servizio quando il Referente Servizio è autorizzato a farlo, ma non può cambiare lo stato del servizio. Può inviare comunicazioni e consultare le transazioni dell'API.
Referente Dominio, può fare tutto ciò che fa il Referente Servizio e, in più, ha il compito di autorizzare la configurazione in collaudo e in produzione, potendo modificare i dati prima di autorizzare.
Gestore, si occupa principalmente di configurare e pubblicare un servizio in collaudo e produzione, ma può effettuare qualunque cambio di stato e modificare qualsiasi campo (specifica, schemi, URL di collaudo e produzione), sempre nel rispetto delle regole di transizione e dei requisiti minimi di ciascuno stato.
Regole sulle modifiche dei campi
Un campo può essere modificato da un utente se il suo ruolo è autorizzato a effettuare il passaggio allo stato successivo. Fa eccezione il Referente Tecnico, che può modificare il campo senza poter effettuare la transizione di stato.
Il Gestore può editare i campi esistenti in qualunque stato.
Sequenza tipica degli stati
stateDiagram-v2
[*] --> Bozza
Bozza --> RichiestoCollaudo: Referente Servizio
state "Richiesto in Collaudo" as RichiestoCollaudo
state "Autorizzato in Collaudo" as AutorizzatoCollaudo
state "In Configurazione in Collaudo" as ConfigurazioneCollaudo
state "Pubblicato in Collaudo" as PubblicatoCollaudo
state "Richiesto in Produzione" as RichiestoProduzione
state "Autorizzato in Produzione" as AutorizzatoProduzione
state "In Configurazione in Produzione" as ConfigurazioneProduzione
state "Pubblicato in Produzione" as PubblicatoProduzione
RichiestoCollaudo --> AutorizzatoCollaudo: Referente Dominio
AutorizzatoCollaudo --> ConfigurazioneCollaudo: Gestore
ConfigurazioneCollaudo --> PubblicatoCollaudo: Gestore
PubblicatoCollaudo --> RichiestoProduzione: Referente Servizio
RichiestoProduzione --> AutorizzatoProduzione: Referente Dominio
AutorizzatoProduzione --> ConfigurazioneProduzione: Gestore
ConfigurazioneProduzione --> PubblicatoProduzione: Gestore
PubblicatoCollaudo --> Archiviato: Gestore
PubblicatoProduzione --> Archiviato: Gestore
Archiviato --> [*]
Il processo gestisce le attività che portano al dispiegamento di un nuovo servizio sulla piattaforma di interoperabilità, con la relativa pubblicazione sul catalogo e la successiva possibilità, per gli aderenti, di richiederne l'attivazione:
Un utente (Richiedente) registra un nuovo servizio (si veda Creare un servizio), inserendo le proprietà che lo descrivono (nome, versione, tag, ecc.), i referenti, un eventuale logo, il livello di visibilità e la documentazione a corredo. Il servizio viene registrato e assume lo stato iniziale Bozza; chi lo ha creato diventa Referente Servizio (ruolo derivato).
Sempre il Referente Servizio, dall'area di gestione, fornisce tutti i dettagli necessari alla pubblicazione: API componenti, referenti, gruppi di appartenenza, categorie di classificazione e allegati. In questa fase possono intervenire nella compilazione dei dati anche i Referenti Tecnici del servizio. Quando la descrizione risulta completa, il Referente Servizio richiede la pubblicazione in ambiente di collaudo, transitando lo stato in Richiesto in Collaudo.
Il Referente Dominio autorizza l'attivazione del servizio in collaudo, transitando lo stato in Autorizzato in Collaudo.
Il Gestore verifica la congruità delle informazioni inserite, effettua eventuali integrazioni/modifiche, quindi prende in carico il dispiegamento sulla piattaforma di interoperabilità, transitando lo stato in In Configurazione in Collaudo.
Il Gestore completa il dispiegamento del servizio in collaudo sulla piattaforma di interoperabilità. Non appena il servizio risulta attivo, transita lo stato in Pubblicato in Collaudo. Da questo momento le organizzazioni aderenti possono richiedere l'attivazione del servizio in collaudo.
In una fase successiva, il Referente Servizio può richiedere il passaggio del servizio all'ambiente di produzione, dopo aver fornito i relativi dettagli tecnici, transitando lo stato in Richiesto in Produzione.
Analogamente a quanto avvenuto per il collaudo, il Referente Dominio autorizza l'attivazione in produzione, transitando lo stato in Autorizzato in Produzione.
Il Gestore verifica la congruità delle informazioni fornite e prende in carico il dispiegamento in produzione, transitando lo stato in In Configurazione in Produzione.
Completato il dispiegamento in produzione, il Gestore transita lo stato in Pubblicato in Produzione. Il servizio è ora attivo in produzione e le organizzazioni aderenti possono richiederne l'attivazione anche in questo ambiente.
Se in una fase successiva si volesse dismettere il servizio, escludendolo dai flussi di adesione su entrambi gli ambienti, il Gestore transita lo stato in Archiviato.