Il workflow di un'adesione

Un'adesione rappresenta la richiesta, da parte di un soggetto aderente, di fruire di un servizio pubblicato sul catalogo. Una volta creata, segue un workflow che determina nomi degli stati, attori abilitati a cambiarli e campi richiesti in ciascuno stato.

Nota

Come per il servizio (si veda Il workflow di un servizio), lo stato dell'adesione è pilotato da configurazione. La sequenza descritta qui è quella di default.

Attori coinvolti

  • Qualsiasi utente, non può vedere le adesioni a meno di assumere un ruolo su di esse (referente o richiedente).

  • Richiedente, la possibilità di richiedere un'adesione dipende dalla configurazione del prodotto. Un qualsiasi utente può indicare l'organizzazione aderente, oppure la maschera propone automaticamente (non modificabile) l'organizzazione di appartenenza dell'utente. Fa eccezione il caso in cui l'utente sia Gestore o Referente Servizio del servizio per cui si sta chiedendo l'adesione. In questo caso resta possibile scegliere organizzazione e soggetto.

  • Referente Adesione (ruolo derivato), può vedere l'adesione in qualsiasi stato, modificarne i dati di configurazione rispettando i vincoli obbligatori, e richiedere la configurazione in collaudo o produzione.

  • Referente Tecnico Adesione (non obbligatorio), può vedere l'adesione in qualsiasi stato e modificarne i dati quando anche il Referente Adesione è autorizzato a farlo, ma non può cambiare lo stato. È autorizzato a inviare comunicazioni e a consultare le transazioni dell'API.

  • Referente Servizio e Referente Dominio, hanno gli stessi diritti del Referente Adesione sul workflow, con in più il compito di autorizzare la configurazione in collaudo e in produzione, modificando i dati se necessario prima di autorizzare.

  • Gestore, si occupa principalmente di configurare e pubblicare un'adesione in collaudo e produzione, ma può effettuare qualunque cambio di stato e modificare qualsiasi campo (es. modalità di autenticazione collaudo/produzione), sempre nel rispetto delle regole di transizione e dei requisiti minimi di ciascuno stato.

Sequenza tipica degli stati

        stateDiagram-v2
    [*] --> Bozza
    Bozza --> RichiestoCollaudo: Referente Adesione
    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 Servizio / Dominio
    AutorizzatoCollaudo --> ConfigurazioneCollaudo: Gestore
    ConfigurazioneCollaudo --> PubblicatoCollaudo: Gestore
    PubblicatoCollaudo --> RichiestoProduzione: Referente Adesione
    RichiestoProduzione --> AutorizzatoProduzione: Referente Servizio / Dominio
    AutorizzatoProduzione --> ConfigurazioneProduzione: Gestore
    ConfigurazioneProduzione --> PubblicatoProduzione: Gestore
    PubblicatoCollaudo --> Archiviato: Gestore
    PubblicatoProduzione --> Archiviato: Gestore
    Archiviato --> [*]
    

Il processo gestisce le attività che portano un'organizzazione aderente a richiedere e ottenere l'attivazione di un servizio pubblicato, al fine di accedervi con i propri client tramite la piattaforma di interoperabilità dell'organizzazione erogatrice:

  1. Un utente di un'organizzazione aderente richiede l'adesione a un servizio pubblicato. Lo stato iniziale dell'adesione è Bozza.

  2. Chi ha richiesto l'adesione può nominare i referenti dell'adesione e fornire i dettagli tecnici necessari per l'attivazione in collaudo (si veda anche Il wizard di creazione e configurazione). Completata la configurazione, transita lo stato in Richiesto in Collaudo.

  3. Il Referente Servizio o il Referente Dominio autorizzano la richiesta in collaudo, transitando lo stato in Autorizzato in Collaudo.

  4. Il Gestore verifica la congruità delle informazioni fornite (ad es. associa i certificati richiesti), quindi prende in carico l'attivazione in collaudo, transitando lo stato in In Configurazione in Collaudo.

  5. Completata la configurazione sulla piattaforma di interoperabilità, il Gestore transita lo stato in Pubblicato in Collaudo. Il servizio è pronto per l'uso da parte dell'aderente in collaudo.

  6. In una fase successiva, il Referente Adesione può richiedere l'attivazione in produzione, previo inserimento dei dati di configurazione necessari, transitando lo stato in Richiesto in Produzione.

  7. Analogamente a quanto avvenuto per il collaudo, il Referente Servizio o il Referente Dominio autorizzano la richiesta, transitando lo stato in Autorizzato in Produzione.

  8. Il Gestore verifica la congruità dei dati forniti ed effettua eventuali integrazioni, quindi prende in carico l'attivazione in produzione, transitando lo stato in In Configurazione in Produzione.

  9. Completate le attività di attivazione, il Gestore transita lo stato in Pubblicato in Produzione. Da questo momento il servizio è utilizzabile in produzione dai client dell'organizzazione aderente.

  10. Se in una fase successiva si volesse revocare l'adesione su entrambi gli ambienti, il Gestore transita lo stato in Archiviato.