Concetti fondamentali
Tenant
Un tenant è una singola installazione di un applicativo per un cliente specifico.
Il termine non indica il cliente, né il Comune: indica l'istanza. Questo significa che lo stesso cliente può avere più tenant attivi contemporaneamente, uno per ogni applicativo che ha attivato.
Esempio pratico:
Il Comune di Bugliano ha attivi:
un tenant di tipo Integrazione Atti Sicraweb
un tenant di tipo Stanza del Cittadino
un tenant di tipo Payment Proxy (Efil)
Sono tre tenant distinti, ciascuno con il proprio identificativo, la propria configurazione e il proprio ciclo di vita indipendente.
Cliente
Il cliente è l'ente che utilizza uno o più applicativi: tipicamente un Comune, una ASL, una Regione o un'altra pubblica amministrazione.
Nel Tenant Manager ogni cliente è una voce nell'anagrafica clienti. La relazione è uno a molti: un cliente può avere N tenant.
Applicativo
Un applicativo è il tipo di prodotto o integrazione che un tenant rappresenta. È il "cosa" di un tenant.
Gli applicativi disponibili sono definiti nel backoffice del Tenant Manager dagli sviluppatori. Ogni tipo di applicativo ha:
uno schema Form.io che determina quali campi di configurazione mostrare
un insieme di workflow Windmill associati alle transizioni di stato (provisioning, deploy, archiviazione)
Esempi di applicativi: Chatbot, Sito Comunale, Stanza del Cittadino, Integrazione Atti Sicraweb, PDND Connector, Payment Proxy, Protocol Proxy.
Piano
Il piano è un'etichetta commerciale che indica il livello di servizio acquistato dal cliente. I valori possibili sono: S, M, L, XL, XXL.
Il piano viene dall'ordine in Odoo, è il team delivery che lo legge e lo imposta sul tenant al momento della creazione. Il Tenant Manager lo memorizza come metadato; il significato tecnico del piano (es. quanti documenti al mese sono inclusi nel piano L) è configurato internamente a ciascun applicativo o workflow Windmill, non nel Tenant Manager stesso.
Nota: per gli applicativi di tipo integrativo (es. Atti Sicraweb, PDND Connector) i piani non sono ancora definiti nel catalogo prodotti. In questi casi il campo piano può essere lasciato vuoto o ignorato fino a indicazioni diverse.
UID e Slug
Ogni tenant ha due identificatori:
UID
UUID v4 (es. a3f2...)
Globale, univoco su tutta la piattaforma
Riferimento cross-service, eventi Kafka, API interne
Slug
Stringa leggibile (es. comune-bugliano-sdc)
Specifico per applicativo
Configurazione interna dell'applicativo
L'UID viene generato automaticamente alla creazione del tenant. Lo slug dipende dall'applicativo: alcuni lo generano autonomamente, altri richiedono che venga impostato manualmente.
Ambiente del Tenant Manager
Come descritto nell'Introduzione, il Tenant Manager esiste in due istanze: QA e Produzione.
È importante non confondere l'ambiente del Tenant Manager (dove stai operando) con lo stato del tenant (il punto del ciclo di vita in cui si trova l'applicativo). Sono due dimensioni ortogonali:
Tenant in stato attivato
Test, nessun impatto reale
Configurazione reale, nessun accesso cittadini
Tenant in stato in produzione
Test, nessun impatto reale
Servizio live, cittadini attivi
Last updated
Was this helpful?