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:

  1. 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).

  2. 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.

  3. Il Referente Dominio autorizza l'attivazione del servizio in collaudo, transitando lo stato in Autorizzato in Collaudo.

  4. 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.

  5. 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.

  6. 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.

  7. Analogamente a quanto avvenuto per il collaudo, il Referente Dominio autorizza l'attivazione in produzione, transitando lo stato in Autorizzato in Produzione.

  8. Il Gestore verifica la congruità delle informazioni fornite e prende in carico il dispiegamento in produzione, transitando lo stato in In Configurazione in Produzione.

  9. 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.

  10. 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.