Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Webhook di Microsoft Graph spiegati: notifiche in tempo reale invece del polling continuo (Doppiaggio IA)

Transcript

Webhook di Microsoft Graph spiegati: notifiche in tempo reale invece del polling continuo (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Siete pronti per 10 giorni di Microsoft 365 e Copilot EA, azzurre per le persone che stanno plasmando il futuro del lavoro?
0:07
Questo gennaio, M365 con ritorno e faremo le cose in grande.
0:12
Unitevi a noi per sessioni dal vivo, demo reali e conoscenze pratiche da MVP ed esperti del settore di tutto il mondo.
0:18
Niente slide generiche, niente gergo infinito.
0:22
Affronteremo le sfide reali.
0:23
Copilot Studio, agenti, IA, Fabric, sicurezza, governance e automazione.
0:28
Che siate professionisti IK, sviluppatori o leader aziendali, ci sono sessioni pensate per voi.
0:35
Con 10 giorni interi potrete esplorare diverse tecnologie e connettervi con una community globale.
0:40
Seguite le dirette e portate intuizioni pratiche nella vostra organizzazione.
0:45
Gennaio 2027, 10 giorni, un'unica Microsoft Community.
0:49
Le iscrizioni sono aperte.
0:51
Andate su m365con.net e assicuratevi il vostro posto oggi stesso.
0:55
m365con.net
0:58
Iscrivetevi ora su m365con.net e ci vediamo dal vivo a gennaio.
1:04
Ciao a tutti e benvenuti a un altro episodio di Microsoft Knowledge Nuggets qui su m365fm.
1:10
Sono il vostro conduttore, mi copi.
1:11
L'argomento di oggi è qualcosa di cui quasi tutti coloro che lavorano con Microsoft 365 hanno sentito parlare,
1:16
ma che in pochi sanno spiegare chiaramente.
1:17
Cosa sono esattamente i webbook di gra?
1:19
Perché dovreste interessarvi a loro invece di continuare con i vecchi o me?
1:22
Immaginate di aspettare una lettera importante.
1:24
Andate alla cassetta delle lettere, vuota.
1:25
Tornate indietro.
1:26
10 minuti dopo, controllate di nuovo.
1:28
Ancora niente.
1:28
Lo fate tutto il giorno, sprecando tempo ed energie.
1:30
Questo è Polli.
1:31
Ora immaginate un mondo diverso.
1:33
Il postino suona il campanello nel momento in cui arriva una lettera.
1:35
Non dovete controllare.
1:36
Aspettate il suono.
1:37
Questo è un webbook.
1:38
Alla fine di questo episodio capirete cosa sono i webbook di graph
1:41
perché sostituiscono il controllo costante e come si incastrano i pezzi.
1:45
Problema del Polli.
1:46
Analizziamolo nei dettagli.
1:48
Per capire perché i webbook sono importanti dovete capire perché il polling è dannoso.
1:51
Ecco come funzionano oggi la maggior parte delle applicazioni.
1:53
La vostra app ha bisogno di risposta.
1:54
Chiede a Microsoft Graph,
1:55
Ehi, ci sono nuovi utenti?
1:57
Risponde, no.
1:59
Quindi la vostra app aspetta un po' e poi richiede
2:00
ora ci sono nuovi utenti?
2:02
Ancora no.
2:03
Ripetutamente questo processo è il polling.
2:05
Pensatelo come chiamare continuamente un amico per sapere se ha notizie.
2:08
Componete il numero, risponde, chiedete, dice di no, riagganciate.
2:11
Poi richiamate dopo cinque minuti e ancora.
2:14
State sprecando il suo tempo e il vostro.
2:15
Probabilmente lo state fastidere.
2:16
Però immaginate migliaia di app che fanno questo Microsoft Graph allo stesso tempo.
2:20
Ogni app interroga ogni pochi minuti ponendo le stesse domande,
2:22
ricevendo le stesse risposte e un sacco di rumore.
2:25
Microsoft ha un nome per quando interroghi in modo troppo aggressivo.
2:28
Throttling o come alcuni sviluppatori lo chiamano.
2:30
La prigione di Graph.
2:32
Quando in vitro per richieste Microsoft dice
2:33
ok, hai finito per un po',
2:35
limita nel numero di chiamate che la tua app puoi finire.
2:37
Una volta è limitato tutto il rallente.
2:39
Richieste legittime si accumulano.
2:40
La tua app smette di funzionare correttamente.
2:42
Non hai idea di quando verrai liberato.
2:44
Di quante richieste stiamo parlando?
2:45
Diciamo che la tua app interroga ogni cinque minuti per modifica gli utenti.
2:48
Si tratta di dodici richieste all'ora.
2:50
In un giorno intero sono 208 richieste
2:52
e questo solo per una risorsa.
2:54
Se interroghi anche per gruppi, file, messaggi ed eventi del calendario
2:57
accumuli migliaia di richieste inutili al giorno,
3:00
la maggior parte non restituisce nulla,
3:01
zero modifiche, ma hai comunque effettuato la chiamata.
3:03
E il punto è questo.
3:04
Anche se interroghi ogni cinque minuti
3:06
non ottieni comunque aggiornamenti in tempo reale.
3:08
Un cambiamento potrebbe verificarsi un minuto dopo l'ultima interrogazione.
3:11
Non ne saprai nulla per altri quattro minuti.
3:13
Stai sprecando risorse e perdendo comunque la finestra temporale.
3:16
Ora contrapponi questo a un approccio basato sugli eventi.
3:18
Invece di chiamare Microsoft Graph ogni pochi minuti
3:20
aspetti che Microsoft Graph chiami te.
3:22
Imposti un listener.
3:22
Quando qualcosa cambia, Graph ti invia una notifica.
3:25
Tonno un componente.
3:26
Rispondi quando il telefono squib.
3:28
Cosa sono i webbook?
3:29
Quindi cos'è esattamente un webbook?
3:31
Ecco le definizioni più semplici.
3:32
Un webbook è una richiesta HTTP
3:34
inviata automaticamente quando accade qualcosa.
3:36
Non la chiedi tu il server.
3:38
Te la invia direttamente.
3:39
Pensalo come un campanello.
3:41
Non stai fuori a controllare nei pochi minuti.
3:43
Instali un campanello.
3:44
Quando qualcuno arriva suona.
3:46
Senti il suono e rispondi.
3:46
Il campanello fa la guardia per te.
3:49
I webbook sono talvolta chiamati a inverse.
3:52
Con un'app normale, la tua app fa una richiesta e il server risponde.
3:55
La tua app ha il controllo.
3:56
Con un webbook, il server invia la richiesta alla tua app.
3:59
Il server ha il controllo, ma invece di aspettare che tu li richieda.
4:02
Ora, anche Microsoft Graph usa i webbook.
4:04
Ma Microsoft li chiama notifiche di modifica.
4:07
È la stessa cosa, solo con un nome diverso.
4:09
Quando qualcosa cambia in Microsoft 365,
4:11
Graph invia un HTTP post a un URL che fornisci.
4:14
Quel post contiene informazioni su cosa è cambiato.
4:17
Ci sono molte cose su cui puoi ricevere notifiche.
4:20
Un nuovo utente viene creato nel tuo tenant.
4:22
Un file aggiornato in SharePoint,
4:23
un messaggio inviato in Teams,
4:25
un evento del calendario che cambia
4:26
o un gruppo che riceve un nuovo membro.
4:29
Tutto ciò può attivare una notifica.
4:30
Ecco un esempio reale.
4:32
Supponiamo che tu gestisca un'azienda con un sistema di donna tema.
4:34
Quando arriva un nuovo dipendente,
4:35
puoi creare automaticamente un account.
4:37
Senza il webbook, interrogi il endpoint degli utenti
4:39
ogni pochi minuti alla ricerca di nuove persone.
4:41
Con il webbook ti iscrivi agli eventi di creazione degli utenti,
4:44
quando qualcuno si unisce,
4:45
Graff invia alla tua app una notifica.
4:47
La tua app la riceve, la convalida
4:49
e crea l'account tutto nel giro di pochi secondi.
4:51
Nessun polli, nessuna richiesta sprecata.
4:54
Un altro esempio.
4:55
Hai una raccolta documenti di SharePoint
4:56
dove vengono caricate le ricevute.
4:57
Senza il webbook, interrogi costantemente la raccolta.
5:00
Con il webbook, Graff ti avvisa nel momento in cui viene aggiunto un file.
5:03
La tua app lo prende e controlla se non ha ricevuta
5:04
e lo elabora automaticamente.
5:07
Questo è il potere del webbook.
5:08
Invece che la tua app chieda costantemente,
5:10
c'è qualcosa di nuovo?
5:10
Lascia che sia stema ad avvisarti quando succede qualcosa.
5:13
È più efficiente, più affidabile, molto più veloce.
5:16
Come funziona nel webbook il Microsoft Graph?
5:18
Ora sai cosa sono i webbook e perché il polli in problema?
5:21
Vediamo come funzionano realmente i webbook di Microsoft Graph
5:23
perché il flusso è più semplice di quanto pensi.
5:26
Si riduce a tre cose.
5:27
Un'iscrizione, una notifica e il tuo endpoint.
5:31
La prima cosa è che un'iscrizione.
5:32
Dici a Microsoft Graph,
5:33
Ehi, voglio sapere quando cambia questa cosa specifica.
5:35
Fornisci a Graph i dettagli su cosa monitorare
5:38
e dove inviare le novità.
5:39
Immaginalo come l'iscrizione avviso.
5:41
Dici al sistema cosa ti interessa
5:42
e fornisci le tue informazioni di contatto.
5:44
Secondo Microsoft Graph,
5:45
osserva quella risolta.
5:46
Monitori eventuali modifiche.
5:48
Quando succede qualcosa,
5:48
come un utente creato un file aggiornato
5:50
all'arrivo di un messaggio,
5:51
Graph se ne accorge.
5:52
Terzo, Graph invia una notifica.
5:54
Invia un HTTP post all'URL che hai fornito.
5:57
Quel post contiene informazioni su ciò che è cambiato.
6:00
Il tuo endpoint lo riceve,
6:01
la tua applicazione lo elabora.
6:02
Quindi flusso generale è semplice.
6:04
Ti iscrivi, Graph osserva,
6:05
Graph invia un post quando qualcosa cambia.
6:08
Analizziamo un po' meglio questi tre blocchi costitutivi.
6:10
L'iscrizione è la tua richiesta di essere avvisato.
6:13
È come dire,
6:13
voglio sapere quando un nuovo utente
6:15
viene aggiunto al mio tenant.
6:17
Invii quella richiesta a Microsoft Graph
6:18
e Graph la memorizza.
6:19
Da quel momento in poi,
6:20
Graph osserva per tuo conto.
6:22
La notifica è l'avviso stesso.
6:24
Un HTTP post che Graph invia al tuo endpoint.
6:26
Il corpo del post contiene dettagli sulla modifica,
6:29
come quale risorsa è cambiata,
6:30
che tipo di modifica è avvenuta e quando.
6:32
Il tuo endpoint è la porta che lascia aperto.
6:34
È un URL sul tuo server configurato
6:35
per ricevere queste richieste post.
6:37
Deve solo mettersi in ascolto
6:38
e rispondere velocemente.
6:39
Tutto qui.
6:40
Non è richiesta alcuna logica complessa alla ricezione.
6:42
Basta ricevere la notifica,
6:43
confermarla ed elaborarla.
6:45
Ora confrontiamolo con il polling.
6:46
Con il polling inviai
6:47
centinaia di richieste e gettono
6:48
in una delle quali chiede
6:49
c'è qualcosa di nuovo?
6:51
Nella maggior parte dei casi la risposta è.
6:52
Con il webbook c'è solo un post,
6:54
la notifica.
6:55
Tutto qui.
6:56
Un unico messaggio invece di centinaia.
6:57
La differenza di efficienza è enorme
6:58
e il tuo endpoint non deve essere complicato.
7:01
Deve solo essere accessibile pubblicamente,
7:03
usare HTTPS e rispondere rapidamente.
7:05
Parleremo tra poco di cosa significhi rapidamente.
7:07
Ma il concetto di base è semplice.
7:09
Tu endpoint ascolta,
7:10
graph chiama,
7:11
tu risponde.
7:12
E il gioco è fatto.
7:14
Creazione di una sottoscrizione.
7:15
Quindi come si configura concretamente una di queste?
7:17
Vediamo passo dopo passo
7:18
come creare una sottoscrizione.
7:20
Si inizia inviando una richiesta HTTP POST
7:22
a un URL specifico su Microsoft Graph.
7:24
Quell'URL è
7:25
HTTPS
7:25
slash graph.microsoft.com
7:27
slash woman.zero subscriptions.
7:29
Invii direttamente all'endpoint delle sottoscrizioni.
7:32
All'interno del corpo della richiesta
7:33
includi i dettagli di ciò a cui vuoi iscriverti.
7:35
Ci sono quattro campi chiave che devi fornire.
7:37
Primo è l'URL di notifica.
7:39
Questo è l'URL del tuo endpoint,
7:41
il luogo in cui Microsoft Graph invierà le notifiche.
7:43
Deve essere HTTPS
7:44
e accessibile pubblicamente
7:45
perché Graph deve raggiungerlo da internet.
7:48
Secondo è la risorsa.
7:49
Questo dice a Graph
7:49
cosa vuoi monitorare.
7:51
Specifichi il percorso delle risorse di Microsoft Graph.
7:53
Ad esempio users
7:54
se vuoi monitorare le modifiche agli utenti
7:55
o me
7:56
slash email folder
7:56
slash
7:57
inbox slash messages
7:58
se vuoi controllare nuove email
7:59
e la posti in arrivo.
8:00
La risorsa dice a Graph esattamente cosa ti interessa.
8:03
Terzo è il tipo di modifica.
8:04
Questo indica a Graph
8:05
per quali tipi di modifiche inviarti notifiche.
8:07
Puoi specificare
8:08
created, deleted, deleted
8:09
o una loro combinazione.
8:11
Quindi se ti interessano solo i nuovi utenti creati
8:12
imposti il tipo di modifica su created.
8:14
Se ti interessano anche gli aggiornamenti
8:15
lo imposti su created, updated.
8:17
Quarto è la data
8:18
e ora di scadenza.
8:19
È il momento in cui la sottoscrizione scade
8:21
perché le sottoscrizioni non durano per sempre.
8:23
Imposti una data e un'ora
8:24
e Graph smetterà di inviare notifiche
8:25
dopo tale momento.
8:27
La durata massima dipende
8:28
dalla risorsa che stai monitorando.
8:29
Per utenti e gruppi
8:30
il massimo è di circa 3 giorni.
8:32
Per elementi di unità in SharePoint
8:33
o OneDrive
8:34
può arrivare fino a 30 giorni.
8:36
È necessario controllare la documentazione
8:37
per ogni tipo di risorsa.
8:38
C'è anche un campo facoltativo degno di nota
8:40
lo stato del client state.
8:42
Si tratta di una stringa segreta da te.
8:43
Può essere qualsiasi cosa tu vogli.
8:45
Una stringa casuale, un guide,
8:46
qualunque cosa tu scegli.
8:49
La notifica è inviata al tuo endpoint
8:50
e tu lo usi
8:51
per verificare che la notifica
8:52
provenga effettivamente dal tuo abbonamento.
8:55
Se qualcuno prova a inviare notifiche false
8:57
al tuo endpoint
8:57
lo stato del client non corrisponderà
8:59
e potrai rifiutarlo immediatamente.
9:01
È una misura di sicurezza semplice
9:02
ma importante.
9:03
Creare un abbonamento
9:04
è come iscriversi alla consegna di un giornale.
9:07
Fornisce a giornale il tuo indirizzo.
9:08
Quello è il tuo R di notifica.
9:10
Indichi quali sezioni desideri
9:12
ovvero la risorsa e il tipo di modifica
9:13
e comunichi per quanto tempo vuoi
9:15
che la consegna continua.
9:16
Quella è la tua data e ora di scadetta.
9:17
Il giornale gestisce tutto il resto.
9:19
Ma ecco il punto
9:20
gli abbonamenti scadono.
9:21
Non puoi crearne uno
9:22
e dimenticartene.
9:24
Dopo che la data e l'ora di scadenza
9:25
sono passate
9:25
Graf smette di inviare notifiche
9:27
e il tuo abbonamento viene eliminato.
9:29
Se vuoi continuare a ricevere notifiche
9:30
devi rinnovare l'abbonamento
9:32
prima che scada
9:32
inviando una richiesta patch
9:33
all'endpoint di sottoscrizione
9:34
con una nuova data e ora di scadenza.
9:37
Quindi creare un abbonamento
9:38
è il primo passo
9:38
ma non è l'ultimo
9:39
devi gestirne il ciclo di vita
9:41
e parleremo più approfonditamente insieme.
9:43
Line check di Convalida
9:43
Prima che il tuo abbonamento diventi attivo
9:45
c'è un passaggio che non puoi saltare.
9:47
Microsoft Graph
9:48
non accetta semplicemente
9:49
la tua richiesta di abbonamento
9:50
per iniziare a inviare notifiche.
9:52
Deve prima confermare
9:52
che il tuo endpoint sia reale
9:53
e pronto a riceverle.
9:55
Ecco come funziona.
9:56
Quando invii la tua richiesta post
9:57
per creare un abbonamento
9:58
Microsoft Graph
9:59
invia immediatamente
10:00
un post di prova
10:01
al tuo URL di notifica.
10:03
Quel post di prova
10:03
include un parametro
10:04
di cui hai richiamato token di Convalida.
10:06
È solo una stringa casuale.
10:07
Il tuo endpoint
10:08
deve acquisire quel token
10:09
e rimandarlo indietro
10:10
come risposta in testo semplice
10:11
entro 10 secondi.
10:12
Immaginalo come un corriere
10:14
che consegna un pacco
10:15
si presenta alla tua porta
10:16
e chiede
10:16
è questo l'indirizzo corretto
10:17
o confermare.
10:18
Devi firmare per riceverlo.
10:20
Se non lo fai se ne va.
10:21
Il corriere non lascia il pacco.
10:23
Se ne va e basta.
10:24
Esattamente quello che sta succedendo.
10:25
Microsoft Graph
10:26
sta dicendo
10:27
sto per inviarti notifiche importanti.
10:29
Dimostrami che sei la persona giusta
10:30
e l'indirizzo giusto.
10:32
Il tuo endpoint risponde
10:34
rimandando indietro
10:34
il tuo token di Convalida
10:35
che dice a Graph
10:36
Sì, sono qui.
10:38
Sto ascoltando.
10:39
Inviami le notifiche.
10:41
Ora ecco dove
10:41
molti sviluppatori in chat.
10:43
Il token di Convalida
10:44
deve essere restituito
10:44
come testo semplice
10:45
non JSON
10:46
non HTML
10:46
testo semplice
10:47
e la risposta deve avere
10:48
un'intestazione content type
10:49
impostata su text flash play.
10:51
Se lo rispedisci
10:52
racchiuso in JSON
10:52
o codificato in qualsiasi modo
10:54
la Convalida fallisce.
10:55
La tua sottoscrizione
10:56
non vera crea.
10:57
Microsoft Graph
10:57
restituisce un errore
10:58
e tu rimani a chiederti
10:59
cosa sia andato sto.
11:00
C'è un altro dettaglio tecnico
11:01
che vale la pena conoscire.
11:02
Il servizio di Convalida
11:03
di Microsoft Graph
11:04
non supporta in modo affidabile
11:05
TLS 1.3.
11:06
negozi a TLS 1.2.
11:08
Quindi se il tuo endpoint
11:08
accetta solo connessioni
11:09
TLS 1.3
11:10
la handshake di Convalida
11:12
fallisce prima ancora
11:12
che il tuo codice
11:13
venga eseguito.
11:14
Devi assicurarti
11:15
che il tuo endpoint
11:15
supporti TLS 1.2
11:17
almeno per la fase di Convalida.
11:19
Dopodiché puoi imporre
11:20
qualsiasi versione di TLS
11:21
desideri per le notifiche effettive.
11:23
La buona notizia
11:24
è che questo handshake
11:25
di Convalida
11:25
viene solo una volta
11:26
per sottoscrizione.
11:27
Non è qualcosa
11:27
che il tuo endpoint
11:28
deve gestire
11:28
ogni volta che arriva
11:29
una notifica
11:30
solo la prima volta.
11:31
Una volta che Graph
11:32
conferma che il tuo endpoint
11:33
è reale
11:33
si fida di esso
11:34
per tutta la durata
11:35
della sottoscrizione.
11:36
Quindi devi farlo bene
11:37
solo una volta.
11:39
Gestione delle notifiche
11:39
e sicurezza.
11:40
Una volta che
11:41
la handshake di Convalida
11:42
è avvenuto
11:42
e la tua sottoscrizione
11:43
è attiva
11:43
Microsoft Graph
11:44
inizia a inviare le notifiche.
11:46
Quindi come appaiono
11:47
nella pratica?
11:49
Quando qualcosa cambia
11:50
Graph invia
11:50
un HTTP Postal
11:51
to Endpoint
11:52
con un oggetto
11:53
JSON nel corpo.
11:54
Quell'oggetto contiene
11:55
la risorsa modificata
11:56
il tipo di modifica
11:57
creata, aggiornata
11:58
o eliminata
11:58
e un timestamp.
11:59
E un timestamp.
12:00
Include anche il valore
12:01
dello stato del client
12:02
che hai impostato
12:02
quando hai creato
12:03
la sottoscrizione.
12:04
È la tua stringa segreta
12:05
e il tuo modo di sapere
12:06
che il messaggio è reale.
12:07
Quindi ecco la prima cosa
12:08
da fare
12:08
quando arriva una notifica.
12:10
Convalida
12:10
con lo stato del client.
12:11
Confronta il valore
12:12
nella notifica
12:12
con il segreto
12:13
che hai salvato
12:13
quando hai creato
12:14
la sottoscrizione.
12:15
Se non corrispondono
12:16
a scartare immediatamente
12:17
perché potrebbe essere
12:17
un falso
12:18
o qualcuno che cerca
12:18
di ingannare il tuo sistema
12:20
facendogli elaborare
12:20
dati errati.
12:21
Questo è importante
12:22
perché il tuo endpoint
12:23
si trova su Internet.
12:24
Chiunque conosca il tuo URL
12:25
potrebbe inviarvi un post.
12:27
Senza la convalida
12:28
dello stato del client
12:28
non avresti modo
12:29
di distinguere
12:30
tra una notifica reale
12:31
di Microsoft Graph
12:31
e una falsa.
12:33
È un controllo semplice
12:34
ma è la tua prima linea di difesa.
12:35
Una volta confermato
12:36
che la notifica è legittima
12:37
devi rispondere rapidamente.
12:39
Microsoft Graph
12:40
si aspetta una risposta
12:41
HTTP di livello 200
12:42
a 3 secondi.
12:43
Se impieghi più tempo
12:44
Graph se ne accorga.
12:45
E se succede troppo spesso
12:46
Graph inizia a trattarti diversamente.
12:48
Ecco come funziona la limitazione.
12:50
Se più del 10%
12:50
delle tue risposte
12:51
supera la finestra di 3 secondi
12:52
in un periodo di 10 minuti
12:53
Microsoft Graph
12:54
contrassegna il tuo endpoint
12:55
come lento.
12:57
Quando ciò accade
12:57
le nuove notifiche
12:58
vengono ritardate di 10 minuti.
13:00
Arrivano comunque
13:00
ma perti la consegna
13:01
in tempo reale.
13:03
E se le cose peggiorano
13:04
con oltre il 15%
13:05
delle tue risposte
13:05
che supera i 10 secondi
13:06
Graph contrassegna
13:07
il tuo endpoint
13:08
come interrotto.
13:09
In quello stato
13:10
le notifiche vengono eliminate
13:11
del tutto per 10 minuti.
13:12
Ecco la parte preoccupante.
13:13
Le notifiche eliminate
13:14
non possono essere operate.
13:15
Sono perse
13:16
e non le riavrai mai indietro.
13:17
Immagina la comunalina
13:18
telefonica.
13:19
Se non rispondi velocemente
13:20
chi chiama riprova più tardi.
13:22
Ma se non rispondi mai
13:22
alla fine chi chiama rinuncia.
13:24
Microsoft Graph
13:25
è chi chiama
13:26
e il tuo endpoint
13:26
è il telefono.
13:28
Rispondi in fretta
13:28
o rischi di perdere il messaggio.
13:30
Quindi quella è la best practice
13:31
in questo.
13:31
Rispondi immediatamente
13:32
ed elabora in modo asincrono.
13:34
Il tuo endpoint
13:34
dovrebbe convalidare
13:35
lo stato del client
13:36
accettare la notifica
13:37
e restituire una risposta
13:38
a 200 o 202
13:39
il più velocemente possibile.
13:41
Quindi inserisci la notifica
13:42
in una coda
13:42
per elaborazione in background.
13:44
Una coda azzurro
13:45
un service bus
13:45
persino una semplice tabella
13:46
di database.
13:47
Il punto è uscire rapidamente
13:48
dal ciclo di risposte
13:49
e lasciare che i tuoi
13:50
worker in background
13:50
gestiscano il lavoro pesante.
13:52
E un alto per memoria di sicurezza
13:53
il tuo endpoint
13:54
deve essere HTTPS
13:55
senza eccezioni.
13:56
Microsoft Graph
13:57
non invierà notifiche
13:58
a un endpoint HTTP.
14:00
Inoltre il tuo endpoint
14:00
deve essere accessibile al pubblico.
14:02
Sei dietro un firewall
14:02
o una VPN
14:03
e Graph non può raggiungerlo.
14:04
Per lo sviluppo
14:05
puoi usare strumenti
14:06
come engrock
14:06
per creare un tunnel pubblico
14:07
verso la tua macchina locale.
14:09
Ma in produzione
14:10
il tuo endpoint
14:10
deve trovarsi in un luogo
14:11
in cui Graph possa trovarlo.
14:14
Mantenere attivo
14:14
il ciclo di vita delle notifiche.
14:16
Quindi hai configurato
14:17
la tua sottoscrizione
14:17
e le notifiche fluiscono
14:18
e tutto sembra a posto.
14:20
Ma ecco qualcosa
14:20
che coglie molti di sorpresa.
14:22
La tua sottoscrizione
14:23
ha una data di scadenza.
14:24
Non dura per sempre.
14:25
A seconda della risorsa
14:26
che stai monitorando
14:26
la durata massima
14:27
della sottoscrizione
14:28
è solitamente tra 3 e 7 giorni.
14:30
Per alcune risorse
14:31
come gli elementi di unità
14:31
in SharePoint
14:32
puoi arrivare fino a 30 giorni.
14:34
Ma il punto è che
14:34
non è permanente.
14:35
Non puoi creare
14:36
una sottoscrizione
14:37
e dimenticartene.
14:38
Immaginala come un abbonamento
14:39
a una rivista.
14:44
dell'abbonamento
14:45
e i numeri smettono di arrivare.
14:46
La stessa cosa vale qui.
14:47
Se la tua sottoscrizione scade
14:48
Microsoft Graph
14:49
smette di inviare notifiche
14:50
e potresti non accorgertene
14:51
finché non ti chiedi
14:52
perché non stia succedendo nulla.
14:53
Quindi ti serve una strategia di nuova.
14:55
In modo in cui rinnovi sempre
14:56
invia una richiesta patch
14:57
all'endpoint della sottoscrizione
14:58
usando l'ID sottoscrizione
15:00
e aggiorna la data
15:00
e l'ora di scadenza
15:01
a una nuova data a futuro.
15:02
Questo estende
15:03
la durata della sottoscrizione.
15:04
Puoi farlo tutte le volte che vuoi
15:06
a patto di farlo
15:06
prima che trascorra
15:07
la scadenza corrente.
15:09
Ora,
15:09
Microsoft Graph
15:09
ti aiuta effettivamente qui
15:10
con qualcosa chiamato
15:11
notifiche del ciclo di vita.
15:13
Quando crei una sottoscrizione
15:14
puoi fornire un URL separato
15:15
chiamato URL di notifica
15:16
del ciclo di vita.
15:18
Microsoft Graph
15:18
invia avvisi a tale URL
15:19
quando accadono determinate cose
15:21
come quando la tua sottoscrizione
15:23
sta per scadere,
15:24
quando il tuo token di accesso
15:25
sta per terminare
15:25
o quando cambiano
15:26
le autorizzazioni della tua.
15:27
Queste notifiche del ciclo di vita
15:29
ti danno un preavviso.
15:30
Non devi indovinare
15:31
quando la tua sottoscrizione scadrà.
15:32
Graph ti dice
15:33
ehi, la tua sottoscrizione
15:34
scade tra poche ore.
15:35
Potresti voler rinnovare.
15:37
È come ricevere un promemoria
15:38
dall'editore della tua rivista
15:39
che l'abbonamento sta per finire.
15:41
Molto utile se presti attenzione.
15:43
Ma cosa succede
15:43
se le cose vanno comunque male?
15:45
Forse il tuo endpoint va giù per un po'
15:46
o le notifiche vengono perse
15:47
perché sei stato troppo lento.
15:50
È qui che entra in gioco
15:51
la Delta Query,
15:51
una funzionalità separata
15:52
di Microsoft Graph
15:53
che ti permette di chiedere
15:54
cosa è cambiato
15:55
dall'ultima volta che ho controllato
15:56
e restituisce solo le modifiche
15:58
e nient'altro.
15:59
Ecco come funziona.
16:00
La prima volta che esegue una Delta Query
16:01
su una risorsa ad esempio di utenti
16:02
Graph restituisce tutti gli utenti
16:03
nel tuo tenant.
16:05
Ma restituisce anche qualcosa in più
16:06
un link speciale
16:06
chiamato Delta Link.
16:08
Salvi quel link.
16:09
Una volta successiva
16:10
che esegui la stessa query
16:10
usi quel Delta Link.
16:12
E invece di ottenere di nuovo
16:13
tutti gli utenti
16:13
ottieni solo quelli
16:14
che sono cambiati
16:15
dalla tua ultima richiesta.
16:16
Nuovi utenti,
16:17
utenti aggiornati,
16:18
utenti eliminati.
16:19
Tutto qui.
16:20
Pensa come se leggessi
16:21
una lista delle novità
16:22
invece di leggere
16:23
l'intera in ciclopedia ogni volta.
16:24
Molto più veloce
16:25
e molti meno dati.
16:26
Ecco il pattern intelligente.
16:27
Combina i webbook
16:28
con la Delta Query.
16:29
Usa i webbook
16:30
per sapere quando
16:31
qualcosa è cambiato.
16:31
Quindi usa la Delta Query
16:32
per scoprire esattamente
16:33
cosa è cambiato.
16:34
Lascia che ti spieghi
16:35
perché è importante.
16:35
I webbook sono veloci
16:36
ma non sono perfetti.
16:37
Le notifiche possono andare perse
16:38
e le sottoscrizioni
16:39
possono scadere
16:40
e tu non puoi andare giù.
16:41
La Delta Query è affidabile.
16:42
Puoi eseguirlo in qualsiasi momento
16:43
e ti fornirà un elenco completo
16:44
delle modifiche dall'ultimo controllo.
16:46
Quindi anche se perdi una notifica
16:47
puoi recuperare...
16:49
Ecco il flusso tipico.
16:51
Imposta una sottoscrizione webbook
16:52
per le modifiche agli utenti.
16:53
Esegui una query Delta iniziale
16:54
per ottenere lo stato di base
16:55
e salva il link Delta.
16:57
Quando arriva un webbook
16:57
che segnala la modifica di un utente
16:59
esegui una query Delta
17:00
usando il tuo link Delta salvato.
17:01
Questo ti fornisce la modifica esatta.
17:03
Elaborala
17:03
quindi salva il nuovo link Delta
17:05
da quella risposta.
17:06
La prossima volta che arriva un webbook
17:07
ripeti il processo
17:08
e se dovessi perdere una notifica
17:10
o se la tua sottoscrizione scade
17:11
esegui di nuovo la query Delta.
17:14
Riceverai tutto ciò che ti serve.
17:15
Una rete di sicuro.
17:16
I webbook offrono velocità
17:17
e la query Delta offre affidabilità.
17:19
Insieme sono una combinazione potente.
17:22
Esempio reale e passi successivi.
17:24
Immagina che un nuovo dipendente
17:25
si unisca alla tua azienda domanda.
17:26
Qualcuno nelle risorse umane
17:28
crea il suo account in Microsoft Entry ID
17:29
e quella singola azione
17:30
avvia una reazione a catena.
17:33
Se hai impostato una sottoscrizione webbook
17:34
per le modifiche agli utenti
17:35
Microsoft Graph se ne accorge istantaneamente
17:37
e invia una richiesta posta al tuo endpoint.
17:39
Ecco cosa succede dopo.
17:40
Il tuo endpoint riceve la notifica
17:41
convalida lo stato del client
17:43
e se corrisponde al tuo segreto
17:44
sai che è legittima.
17:46
Restituisci una risposta
17:47
202 Accepted entro 3 secondi
17:49
confermando la notifica
17:50
e poi il tuo worker in background
17:52
la prende in carico.
17:53
Il worker vede che è stato creato un utente
17:55
ma la notifica non include tutti i dettagli
17:56
quindi esegue una query Delta salvato.
17:59
Questa restituisce le informazioni complete
18:01
del nuovo utente.
18:02
Nome, email, dipartimento, ruolo, responsabile
18:04
e tutto ciò che ti serve.
18:05
Ora il tuo worker prende quelle informazioni
18:06
e crea un account per il nuovo dipendente
18:08
nel tuo sistema di rilevazione
18:09
e presenza di terze parti.
18:10
Invia un'email di benvenuto.
18:12
Lo aggiunge alle liste di distribuzione appropriate.
18:14
Tutto questo avviene in pochi secondi
18:15
dopo che le source umane hanno creato l'account
18:17
e l'entrae di nessun polling,
18:19
nessun passaggio manuale,
18:20
nessuno.
18:21
Pensa all'alternativa.
18:23
Senza webbook dovresti interrogare
18:24
l'endpoint utente ogni pochi minuti
18:26
centinaia di richieste al giorno
18:27
e anche allora potresti non vedere
18:28
un nuovo utente per diversi minuti.
18:30
Con il webbook è istantaneo.
18:32
Una notifica, una query Delta fatto.
18:34
Questo è il vero valore.
18:35
Il tuo sistema diventa più veloce,
18:36
più efficiente e meno soggetto
18:37
ai limiti di throttling.
18:39
Invece di chiedere costantemente
18:40
aggiornamenti a graph,
18:41
lasci che sia graph ad avvisarti
18:42
quando succede qualcosa.
18:43
È un cambiamento fondamentale
18:44
nel modo in cui costruisci l'integrazione.
18:45
Quindi ecco cosa voglio che tu provi.
18:47
Pensa a un processo
18:48
per cui stai attualmente effettuando il web.
18:49
Forse stai controllando
18:50
se arrivano nuove mail
18:51
in una casella condivisa.
18:52
Forse stai monitorando
18:53
le modifiche ai file
18:53
in una raccolta SharePoint.
18:55
Forse stai controllando
18:55
gli aggiornamenti utenti
18:56
nel tuo sistema kernel.
18:57
Potrebbe un webbook
18:58
sostituire quel pochi.
18:59
Nella maggior parte dei casi
19:00
la risposta è sì.
19:01
Non serve costruire tutto.