Connettore SQL diretto (Postgres)

Il connettore SQL diretto legge i ticket direttamente da un database Postgres del cliente, in sola lettura, e li porta in ServiceBoard come tutti gli altri: consultabili nella pagina Ticket e utilizzabili in dashboard, widget e report. Ti serve quando il cliente non ha un PSA/helpdesk da collegare via API, ma i dati vivono già in un database (un gestionale, un applicativo interno, un data warehouse): invece di esportare file a mano, colleghi il database una volta e ServiceBoard lo mantiene sincronizzato.

Il connettore lavora solo in lettura: non crea, non modifica e non cancella nulla sul database di origine. La sola lettura è garantita su più livelli (vedi «Sicurezza»), non è una semplice buona intenzione.

Come si fa

1. Apri Impostazioni (visibile solo agli amministratori) e vai su Connettori.
2. Scegli la card SQL diretto (Postgres) e premi Aggiungi istanza.
3. Inserisci i parametri di connessione: Host, Porta (di norma 5432), Database, Utente (con i soli privilegi di lettura SELECT), Password (cifrata a riposo, sempre mascherata) e SSL (lascialo su «Richiesto» per le connessioni di rete).
4. Scrivi la query SELECT che elenca i ticket (vedi «La query»).
5. Mappa le colonne del risultato sui campi del ticket e aggiungi gli eventuali campi personalizzati. Un'anteprima ti mostra colonna → campo man mano che compili.
6. Premi Testa la connessione: ServiceBoard esegue la query su un piccolo campione, senza importare nulla.
7. Abbina la connessione al cliente di ServiceBoard e salva. Da qui i ticket vengono sincronizzati periodicamente.

La query

Il connettore importa esattamente le righe restituite da una sola query SELECT (oppure WITH … SELECT). Le regole tengono tutto in sola lettura: niente istruzioni multiple, niente parole chiave di scrittura (INSERT/UPDATE/DELETE), di struttura (CREATE/ALTER/DROP) o di accesso a file. Esempio valido: SELECT id, oggetto, stato, priorita, cliente, creato_il FROM ticket WHERE creato_il >= '2024-01-01'. Per sicurezza vengono sempre applicati un tetto di righe e un timeout: se il database è enorme, restringi il periodo nella WHERE.

Mappare le colonne

• Campi standard del ticket — abbini ogni colonna al campo corrispondente (ID, oggetto, stato, priorità, cliente, date…). La colonna ID è la chiave con cui ServiceBoard riconosce i ticket ed evita i doppioni.
• Campi personalizzati — per le colonne senza un campo standard crei un campo personalizzato, poi utilizzabile nei widget (lo ritrovi nel Widget Builder), esattamente come per l'import da file.

La mappatura riusa lo stesso motore dell'Import universale (CSV/Excel): stessa logica, stessa anteprima.

Sicurezza

• Utente di sola lettura — usa un utente Postgres con i soli privilegi SELECT. È la barriera più solida.
• Transazione di sola lettura — ogni query gira in una transazione READ ONLY: è il database stesso a rifiutare qualunque scrittura.
• Controllo della query — prima dell'esecuzione ServiceBoard verifica che sia una singola SELECT e blocca le parole chiave pericolose.
• Rete — ammessi host su reti private e VPN (i database aziendali stanno spesso lì); bloccati loopback e metadata cloud.
• Password cifrata a riposo (AES-256-GCM), mai nei log; errori sintetici senza host o credenziali.

Limiti e connettività

• Entità: oggi importa ticket. Le altre entità restano sugli altri connettori e sull'import da file.
• Database: oggi Postgres; MySQL e SQL Server sono previsti in seguito.
• Raggiungibilità: ServiceBoard gira in cloud, quindi il database deve essere raggiungibile — direttamente, tramite replica di sola lettura, o via VPN/tunnel. Per un database on-premise dietro firewall senza accesso in ingresso servirà l'agente gateway (in arrivo).

Domande frequenti

• Può modificare il mio database? No: sola lettura su tre livelli (utente SELECT, transazione READ ONLY, controllo della query).
• Il test risponde ma non vedo ticket. Controlla la mappatura: senza la colonna ID i ticket non vengono creati. Verifica anche il filtro periodo nelle dashboard.
• Posso collegare più database? Sì, è multi-istanza: più connessioni SQL, ciascuna con le proprie credenziali, query e cliente abbinato.

Vedi anche