Introduzione
Docebo permette di creare webhook attivabili su base evento, al fine di inviare informazioni riguardo l’evento stesso ad uno specifico URL di Payload. In questo modo è possibile utilizzare i dati della piattaforma per popolare report e dashboard, gestire integrazioni e altro ancora. È inoltre possibile connettersi al proprio sistema di Human Capital Management (HCM), inviare email a utenti non presenti in piattaforma riguardo eventi avvenuti in piattaforma, o aggiornare il proprio sistema di Content Storage Management (CSM).
Una volta attivata la app Webhooks in piattaforma, è possibile creare l’input di un evento iniziale, in modo che Docebo possa inviare un post all’URL definito nel webhook dell’evento. I dati relativi all’evento sono inseriti in un messaggio JSON e inviati attraverso una chiamata HTTP POST (non via email o come notifica). È inoltre possibile creare dei webhook attraverso un set completo di API webhook messo a disposizione da Docebo. Fare riferimento alla documentazione ufficiale API per ulteriori informazioni.
Le funzionalità webhook saranno estese nel tempo, al fine di includere più integrazioni e più eventi, quindi mantieniti aggiornato consultando la pagina degli Aggiornamenti di Prodotto.
Domande e Risposte
Questa sezione raccoglie le domande più frequenti sulla creazione e la gestione dei webhook.
Come approcciare la scrittura dei webhook?
Cerca di pensare ai webhook come a delle notifiche, e non come a chiamate API. Un webhook è un'allerta che informa un sistema esterno che è successo qualcosa in piattaforma. Il sistema esterno elabora poi l'informazione in base alle necessità dell'integratore. Non scrivere i webhook come se fossero chiamate API automatiche che scatenano azioni in remoto, perché non sempre accadono in tempo reale.
Quanti eventi può contenere un singolo payload quando gli eventi sono raggruppati?
La piattaforma raggruppa gli eventi dello stesso tipo in base alle performance del sistema, fino ad un massimo di 25 eventi per gruppo. Docebo si riserva il diritto di limitare il numero di payload per gruppo per garantire le performance dell'infrastruttura.
Dopo quanto tempo una “mancata risposta” è considerata come un "invio non riuscito"?
L'integratore DEVE rispondere entro 5 secondi dall'invio del webhook. Dopo 5 secondi, il webhook entra nella coda di reinvio, che tenterà di inviare nuovamente il messaggio fino a 10 volte nelle successive 48 ore.
Quanti webhook possono essere messi in coda prima che si verifichi un troncamento? C'è un limite al numero di messaggi che possono essere inviati (al netto dei limiti del server ricevente)? Qual è il rischio che i messaggi vengano eliminati dalla coda in caso di volumi estremamente grandi?
Dal punto di vista del client non ci sono limiti, quindi non c'è rischio che i messaggi vengano eliminati. I messaggi sono considerati persi SOLO nel caso in cui l'endpoint ricevente non risponda con una risposta “200” durante i 10 tentativi di invio nel periodo di invio di 48 ore, come indicato nella risposta precedente.
L'invio di ogni messaggio deve essere identificato come invio riuscito o non riuscito affinché venga inviato il messaggio successivo? Il secondo messaggio sarà inviato prima di ricevere la risposta di ricezione del primo messaggio?
Ogni messaggio è indipendente dagli altri; tuttavia, dopo 10 tentativi con lo stesso payload, il webhook viene disattivato (si veda la domanda “Dopo quanto tempo una “mancata risposta” è considerata come un "invio non riuscito"?”).
I messaggi sono inviati in sequenza (uno dopo l'altro) o su richiesta (a prescindere dallo stato degli altri messaggi)?
Il sistema organizza le code in base al dominio dell'endpoint del webhook. Gestisce quindi le priorità dei messaggi di ogni coda. Di conseguenza, il secondo messaggio è inviato dopo un timeout di 5 secondi.
I messaggi inattivi in coda sono crittografati?
Non sono crittografati, ma sono protetti dalla nostra infrastruttura via autenticazione. La trasmissione stessa utilizza i protocolli HTTP o HTTPS impostati dall'amministratore per l'endpoint del webhook.
La coda viene interrotta quando si verifica un errore critico? Qual è il rischio che i messaggi vengano persi/non consegnati?
In generale, la coda non viene mai interrotta. Il rischio di “messaggio perso” o “non consegnato” è estremamente basso, tuttavia questi messaggi potrebbero essere causati da un problema dell'integrazione.