Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Delta query di Microsoft Graph: delta link, scadenza del token, errore 410 e approccio ibrido con le notifiche (Doppiaggio IA)

Transcript

Delta query di Microsoft Graph: delta link, scadenza del token, errore 410 e approccio ibrido con le notifiche (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Siete pronti per 10 giorni di Microsoft 365, Copilot AI,
0:04
Speaker 2: Azure e per le persone che stanno plasmando il futuro
0:06
Speaker 2: del lavoro? Questo gennaio, M365 corritorna e puntiamo ancora più,
0:11
Speaker 2: in alto. Unitevi a noi per sessioni dal vivo, demo
0:14
Speaker 2: concrete e conoscenze pratiche da MVP ed esperti del settore
0:17
Speaker 2: di tutto il mondo. Niente slide generiche, niente gergo infinito.
0:21
Speaker 2: Affronteremo le sfide reali. Copilot Studio, agenti, AI, Fabric, sicurezza,
0:26
Speaker 2: governance e automazione e automazione. Che siate professionisti IT, sviluppatori
0:31
Speaker 2: o leader aziendali, ci sono sessioni pensate apposta per voi.
0:35
Speaker 2: Con dieci giorni completi potrete esplorare diverse tecnologie e connettervi
0:39
Speaker 2: con una community globale. Seguite le sessioni live e portate
0:42
Speaker 2: nella vostra organizzazione approfondimenti pratici. Gennaio 2027, dieci giorni, un'unica
0:48
Speaker 2: Microsoft Community. Le iscrizioni sono aperte. Prenotate il vostro posto
0:53
Speaker 2: oggi stesso a Angie stesso. Andate su m365con. net Iscrivetevi ora
1:01
Speaker 2: su m365con. net e ci vediamo live a gennaio. Lasciate che
1:05
Speaker 2: vi faccio un esempio. Avete un'app calendario sul telefono che
1:08
Speaker 2: mostra le riunioni del giorno, ma avete anche riunioni sul
1:10
Speaker 2: laptop e a volte qualcuno cambia l'orario quando siete lontani
1:13
Speaker 2: dalla scrivania. Quando aprite l'app sul telefono vi aspettate di
1:16
Speaker 2: vedere quel cambiamento subito, non domani. Quindi come gestisce la
1:19
Speaker 2: cosa la maggior parte? Scaricano ogni singolo evento ogni pochi minuti,
1:22
Speaker 2: sia che qualcosa sia cambiato o meno. Rifletteteci un secondo.
1:25
Speaker 2: Se avete mille eventi in calendario e solo uno è cambiato,
1:28
Speaker 2: l'app scarica comunque tutti i mille. È come andare al
1:31
Speaker 2: supermercato e comprare tutti i miei guazzi solo perché vi
1:33
Speaker 2: serviva il latte. Un spreco, vero? È il vecchio modo
1:35
Speaker 2: di fare le cose. E va peggio. Con una connessione lenta,
1:38
Speaker 2: quel download completo richiede tempo. State lì a fissare il
1:40
Speaker 2: comune di caricamento. L'app sembra lenta. La batteria si scarica
1:43
Speaker 2: più velocemente e il server deve gestire tutte quelle richieste
1:46
Speaker 2: anche quando non è cambiato nulla. Ora immaginate di creare
1:48
Speaker 2: un'app che sincronizza utenti da Microsoft Entry ID, email da
1:51
Speaker 2: Exchange o file da SharePoint. Il problema si moltiplica. state
1:55
Speaker 2: spostando gigabyte di dati senza alcun motivo valido le delta
1:58
Speaker 2: query risolvono esattamente questo problema invece di chiedere tutto chiedete
2:01
Speaker 2: solo ciò che è cambiato dall'ultimo controllo e se potesse
2:04
Speaker 2: ottenere solo le novità questa è la domanda a cui
2:10
Speaker 2: rispondono le delta query se avete mai aspettato che una
2:12
Speaker 2: sincronizzazione finisse con una connessione lenta o avete creato un'app
2:15
Speaker 2: che interroga un'app ogni pochi minuti chiedendovi se ci sia
2:17
Speaker 2: un modo migliore questo fa per voi quello che arriva
2:20
Speaker 2: è un semplice meccanismo di tracciamento delle modifiche niente magia
2:23
Speaker 2: Solo un intelligente calcolo di token che vi permette di
2:25
Speaker 2: chiedere a Microsoft Graph cosa c'è di nuovo dall'ultima volta.
2:29
Speaker 2: Cos'è una Delta Query? Quindi, cos'è esattamente una Delta Query?
2:32
Speaker 2: Ecco la definizione più semplice. Una Delta Query chiede a
2:35
Speaker 2: Microsoft Graph solo le modifiche dall'ultimo controllo, non tutto, solo
2:38
Speaker 2: gli elementi nuovi, aggiornati o eliminati. Pensa alla tua casella
2:42
Speaker 2: di posta elettronica. Quando l'apri al mattino, non rileggi ogni
2:45
Speaker 2: singola email, guardi solo quelle nuove, quelle arrivate dall'ultimo controllo.
2:49
Speaker 2: È esattamente ciò che fa una Delta Query, ma per
2:51
Speaker 2: i tuoi dati Microsoft 365... Ora confrontala con una sincronizzazione completa.
2:55
Speaker 2: Una sincronizzazione completa è come fare un backup totale della
2:57
Speaker 2: tua casera di posta ogni volta che controlli me. Avresti
3:00
Speaker 2: migliaia di copie degli stessi messaggi. È uno spreco ed elento.
3:03
Speaker 2: Una Delta Query è più simile a un registro delle
3:05
Speaker 2: modifiche che dice ecco cosa è successo dall'ultima volta. Nient'altro.
3:08
Speaker 2: Funziona con molte risorse di Microsoft Graph, utenti, gruppi, post,
3:12
Speaker 2: eventi del calendario, contatti, file. Se risiedi in Microsoft 365
3:15
Speaker 2: probabilmente esiste un endpoint Delta per accederli. La prima volta
3:18
Speaker 2: che richiami un endpoint Delta restituisce tutto. Quello è la
3:20
Speaker 2: tua base di riferimento. Ottieni tutti i dati più un
3:22
Speaker 2: link speciale, chiamato link delta. Salvi quel link. Poi, nelle
3:26
Speaker 2: chiamate successive, usi quel link salvato e Microsoft Graph restituisce
3:29
Speaker 2: solo le modifiche, aggiunte, aggiornamenti, eliminazioni. Tutto qui. Perché è importante?
3:33
Speaker 2: Meno dati spostati significano sincronizzazione più rapida e significano una
3:37
Speaker 2: migliore esperienza utente. La tua app risulta scattante invece che lenta.
3:40
Speaker 2: E poiché sposti meno dati, utilizzi meno larghezza di banda
3:42
Speaker 2: e meno potenza di elaborazione su entrambi i fronti. Costi inferiori,
3:45
Speaker 2: prestazioni migliori. Microsoft ha progettato le Delta Query per le
3:48
Speaker 2: app che devono rimanere aggiornate senza sovraccaricare la piatta. Se
3:51
Speaker 2: hai mai raggiunto un limite di frequenza perché facevi polling
3:53
Speaker 2: troppo aggressivo, sai perché è importante. Le Delta Query ti
3:56
Speaker 2: consentono di sincronizzare in modo efficiente senza subire limitazioni. Come
3:59
Speaker 2: funziona il sistema dei token? Quindi come fa il sistema
4:01
Speaker 2: a ricordare dove hai interrotto? È qui che entrano in
4:03
Speaker 2: gioco i token. Quando fai quella prima Delta Query, Microsoft
4:06
Speaker 2: Graph non si limita a inviarti i dati e dimenticarsene.
4:09
Speaker 2: Ti fornisce qualcosa chiamato Link Delta. Pensa a esso come
4:12
Speaker 2: un segnalibro. Un segnalibro che dice a Graph esattamente dove
4:14
Speaker 2: hai smesso di leggere. Ecco come funziona. Fai la tua
4:17
Speaker 2: prima richiesta e Graph rimanda indietro tutti i dati Il
4:20
Speaker 2: tuo set completo di utenti, eventi o qualsiasi cosa tu
4:22
Speaker 2: stia monitorando. In fondo a quella risposta c'è un'URL che
4:25
Speaker 2: contiene qualcosa chiamato token delta. Salvi quell'URL e lo archivi
4:28
Speaker 2: in un posto sicuro. La prossima volta che vuoi sincronizzare
4:31
Speaker 2: non fai nuova richiesta. Invece richiami quell'URL salvato. Graf dice,
4:34
Speaker 2: oh mi ricordo di te, ti sei fermato qui. Quindi
4:37
Speaker 2: ti invia solo le modifiche avvenute da quel punto. È
4:40
Speaker 2: stato aggiunto un nuovo utente, eliminato un evento, aggiornato il
4:42
Speaker 2: numero di un contatto. Questo è tutto ciò che ti è.
4:45
Speaker 2: Più nuovo delta link per la volta successiva. Ora, cosa
4:46
Speaker 2: succede se ci sono molte modifiche? Diciamo che non hai
4:49
Speaker 2: sincronizzato per tre giorni centinaia di cose soltanto. Il grafo
4:52
Speaker 2: potrebbe non inviarle tutte in un'unica risposta. Invia una pagina
4:54
Speaker 2: in modifiche e in fondo vedi qualcosa chiamato Next Link.
4:58
Speaker 2: Significa di continuare, cioè dell'altro. Richiami quel Next Link, ottieni
5:01
Speaker 2: la pagina successiva e ripeti finché non vedi finalmente un
5:03
Speaker 2: Delta Link. È così che sai di essere in pari.
5:06
Speaker 2: Il Next significa che arriveranno altri dati. Il Delta Link
5:08
Speaker 2: significa che per ora è finito. Ecco un modo per pensarci.
5:10
Speaker 2: Immagina di fare la spesa, compri un carrello pieno di
5:12
Speaker 2: cose e il cassiere ti dà uno scontrino. Quello scontrino
5:15
Speaker 2: è la prova di ciò che hai comprato. La prossima
5:18
Speaker 2: volta che fai la spesa non porti l'internet. Porti solo
5:20
Speaker 2: quello scontrino. Il cassiere lo guarda e dice, bene, hai
5:23
Speaker 2: già latte e uova. Ti servono solo le cose cambiate
5:25
Speaker 2: da allora. Quello scontrino è il tuo delta link. Non
5:28
Speaker 2: devi ricordare cosa hai già. Lo scontrino ricorda per te
5:31
Speaker 2: e questo è il punto chiave. Non devi archiviare tu
5:33
Speaker 2: stesso timestamp o numeri di versione. Non devi capire cosa
5:36
Speaker 2: è cambiato e cosa no. Microsoft gestisce tu quel tracciamento.
5:39
Speaker 2: Tu salvi solo il link, lo richiami in seguito e
5:41
Speaker 2: lasci che il grafo faccia il lavoro. Le limitazioni che
5:43
Speaker 2: non puoi ignorare. Sembra elegante, vero? Ma come ogni sistema
5:46
Speaker 2: intelligente ci sono insidie che devi conoscere. Per prima cosa
5:49
Speaker 2: la scadenza del token. Se sincronizzi oggetti di directory, utenti, gruppi, dispositivi,
5:53
Speaker 2: il tuo Delta Token è valido solo per 7 giorni.
5:55
Speaker 2: Tutto qui. Se la tua app non sincronizza almeno una
5:57
Speaker 2: volta ogni 7 giorni quel token SCADE, quando scade non
6:00
Speaker 2: puoi semplicemente riprendere da dove avevi lasciato. Devi ricominciare con
6:03
Speaker 2: una sincronizzazione completa. È un problema più grande di quanto sembra.
6:06
Speaker 2: Immagina di creare un'app che sincronizza i profili utenti. Funziona
6:08
Speaker 2: bene per mesi. Poi qualcuno va in vacanza per due settimane.
6:11
Speaker 2: Quando torna il token dell'app è morto. Deve scaricare tutto
6:13
Speaker 2: da zero. Si tratta di molti dati, di molto tempo.
6:17
Speaker 2: Secondo c'è il temuto errore 410 GONE. Anche se il
6:19
Speaker 2: token non è scaduto, naturalmente, Microsoft Graph può invalidarlo. Ciò
6:23
Speaker 2: accade durante manutenzioni interne, migrazioni di tenant o altri cambiamenti
6:26
Speaker 2: dietro le quinte che non puoi controllare. Quando succede, Graph
6:29
Speaker 2: restituisce uno stato HTTP 4GCI. E il modo di Microsoft
6:33
Speaker 2: è di dire, non ricordo quel token. Ricomincia da capo.
6:35
Speaker 2: Di nuovo serve una risincronizzazione completa. Terzo, i ritardi di elaborazione.
6:39
Speaker 2: Ecco qualcosa che sorprende molte persone. Quando qualcuno aggiorna un
6:42
Speaker 2: utente in Microsoft Entry D, quella modifica non appare istantaneamente
6:45
Speaker 2: nelle query delta. C'è un ritardo. A volte secondi, a
6:48
Speaker 2: volte minuti. La modifica deve propagarsi attraverso i sistemi interni
6:51
Speaker 2: di Microsoft prima di apparire nel feed delta. Quindi se
6:54
Speaker 2: stai creando un'app che necessita di aggiornamento in tempo reale,
6:56
Speaker 2: la sola query delta non basterà. Penserei che nulla sia
6:58
Speaker 2: cambiato quando in realtà qualcosa non è ancora apparso. Quarto,
7:01
Speaker 2: proprietà non tracciate. Non ogni proprietà di una risorsa viene
7:03
Speaker 2: tracciata dalla query delta. Prendi la proprietà delle competenze skills.
7:07
Speaker 2: Quei dati risiedono in SharePoint, non nell'archivio principale della diretta.
7:10
Speaker 2: Quindi se qualcuno aggiorna le competenze di un utente, tale
7:12
Speaker 2: modifica non attiva una risposta Delta. La tua app non
7:14
Speaker 2: la vedrà mai. Dovresti eseguire una lettura completa di quella
7:17
Speaker 2: proprietà per cogliere l'aggiornamento. Questo coglie spesso gli sviluppatori alla sprovvista. Quinto,
7:21
Speaker 2: le repliche. Microsoft Graph fa il possibile per evitare duplicati,
7:24
Speaker 2: ma non lo garantisce. Stessa modifica potrebbe apparire in due
7:27
Speaker 2: risposte Delta consecutive. Ciò significa che la tua app deve
7:30
Speaker 2: essere idempotente. Deve gestire lo stesso aggiornamento due volte senza bloccarsi.
7:34
Speaker 2: Se stai inserendo record in un database, devi verificare se
7:36
Speaker 2: il record esiste già prima di aggiungerlo. Se stai aggiornando
7:39
Speaker 2: un campo, devi assicurarti che applicare lo stesso aggiornamento due
7:41
Speaker 2: volte non corrompa i tuoi dati. E sesto, restrizioni sui
7:44
Speaker 2: parametri di query. Sugli endpoint delta di utenti e gruppi
7:47
Speaker 2: non puoi usare expand o order by. Puoi includere la
7:49
Speaker 2: proprietà manager nella sincronizzazione utente. Puoi farlo, ma solo se
7:53
Speaker 2: usi select in un modo specifico. Vuoi ordinare gli utenti
7:55
Speaker 2: per nome? Non è possibile sull'endpoint delta. Devi aggirare queste
7:58
Speaker 2: limitazioni con richieste aggiuntive. Qui ecco il ripilo. La query
8:02
Speaker 2: delta è potente, risparmia larghezza di banda, riduce la latenza
8:04
Speaker 2: e rende la tua app veloce. Ma non è un
8:06
Speaker 2: sistema perfetto. I tokens scadono, le modifiche subiscono ritardi, alcune
8:09
Speaker 2: proprietà sono invisibili e accadono duplicati. E non puoi usare
8:12
Speaker 2: tutte le funzionalità di query a cui sei abituato. È
8:14
Speaker 2: necessario pianificare questi casi limite, integrare una logica di riprova,
8:17
Speaker 2: gestire l'errore 410, prevedere repliche e, cosa più importante, non
8:21
Speaker 2: dare per scontato che la Delta Query mostri il quadro completo,
8:23
Speaker 2: perché a volte non è così. Delta Query ha confronto
8:26
Speaker 2: con le notifiche di modifica. Quindi, se la Delta Query
8:28
Speaker 2: presenta queste lacune, scadenza dei token, ritardi di elaborazione, proprietà
8:31
Speaker 2: non tracciate, perché non tracciate? Perché non usare semplicemente notifiche push?
8:34
Speaker 2: Confrontiamo i loro funzionamenti. Le notifiche di modifica si basano
8:36
Speaker 2: sul sistema operativo. Microsoft chiama il tuo endpoint quando qualcosa cambia.
8:40
Speaker 2: Parliamo di secondi, non di minuti. Quasi in tempo reale.
8:43
Speaker 2: Se qualcuno aggiorna un utente in Entry ID, la tua
8:45
Speaker 2: app lo sa quasi istantaneamente. Nessun polling richiesto. La Delta Query,
8:49
Speaker 2: d'altra parte, si basa sul sistema Pool. Richiedi le modifiche
8:51
Speaker 2: secondo la tua pianificazione. Magari ogni ora, ogni sei ore
8:54
Speaker 2: o una volta al giorno. La latenza si misura in
8:56
Speaker 2: minuti o ore, non in secondi. Decidi tu quando controllare
8:59
Speaker 2: e ottieni tutto ciò che è cambiato dall'ultimo controllo. Quindi
9:01
Speaker 2: quali sono i vantaggi del Push? La bassa latenza è
9:03
Speaker 2: il principale. Se stai creando un'app che deve reagire rapidamente,
9:06
Speaker 2: ad esempio inviando un avviso email urgente quando un documento
9:09
Speaker 2: critico viene modificato, le notifiche di modifica sono la soluzione.
9:12
Speaker 2: Ricevi la notifica nel momento in cui accadde. Ma il
9:14
Speaker 2: push anche devi svantare. Innanzitutto serve un endpoint HTTPS accessibile pubblicamente.
9:18
Speaker 2: Ciò significa che la tua app deve essere raggiungibile da internet.
9:21
Speaker 2: Per le app che girano all'interno di una rete aziendale
9:23
Speaker 2: questo è un problema di sicurezza. Devi aprire porte, gestire
9:26
Speaker 2: certificati e gestire il traffico in entrata. Secondo, devi gestire
9:29
Speaker 2: la convalida. Quando crei una sottoscrizione, Microsoft Graph invia un
9:33
Speaker 2: token di convalida al tuo endpoint. Il tuo endpoint deve
9:35
Speaker 2: restituire quel token in testo semplice entro 10 secondi. Se
9:38
Speaker 2: non lo fa, la sottoscrizione fallisce. Terzo, le sottoscrizioni scadono.
9:41
Speaker 2: Devi rinnovarle prima che scadano, altrimenti smetterai di ricevere notifiche.
9:45
Speaker 2: E quarto, i tentativi di riprova. Se il tuo endpoint
9:48
Speaker 2: non risponde entro 3 secondi, Microsoft Graph riprova con un
9:50
Speaker 2: back- off esponenziale fino a 4 ore. Se il tuo endpoint
9:53
Speaker 2: è lento, le notifiche possono andare persi completamente. Passando al
9:56
Speaker 2: lato pull, il vantaggio della Delta Query è un'infrastruttura più semplice.
9:59
Speaker 2: Nessun endpoint pubblico necessario e nessun traffico in entrata a gestione.
10:02
Speaker 2: Devi solo effettuare richieste in uscita dalla tua app. Tutto qui.
10:05
Speaker 2: Hai anche un maggiore controllo su quando accadono le cose.
10:08
Speaker 2: Puoi pianificarle negli orari di minor traffico, raggrupparle e processare
10:11
Speaker 2: le modifiche al tuo ritmo. Anche il pull ha dei conti.
10:13
Speaker 2: È una tendenza più elevata. Vieni a conoscenza delle modifiche
10:16
Speaker 2: solo quando le richiesti. Se esegui il pull ogni ora,
10:18
Speaker 2: potresti essere in ritardo fino a un'ora. La scadenza di
10:21
Speaker 2: token è un altro rischio. Se non effettui la sincronizzazione
10:23
Speaker 2: abbastanza spesso, il tuo token scade e devi ricominciare da capo.
10:25
Speaker 2: E poi c'è lo sforzo inutile del polling, anche quando
10:27
Speaker 2: non è cambiato nulla. Fai la richiesta, ricevi una risposta
10:30
Speaker 2: vuota e devi rifarlo al ciclo successivo. Quale dovresti scegliere?
10:34
Speaker 2: Se ti serve una bassa latenza, ad esempio per avvisi
10:36
Speaker 2: mail urgenti o collaborazione in tempo reale, usa le notifiche
10:39
Speaker 2: di modifica. Se stai eseguendo una sincronizzazione di massa, mantenendo
10:42
Speaker 2: un database locale o creando un'app che funziona offline, usa
10:45
Speaker 2: la delta query. Ognuno ha il suo scopo. L'approccio ibrido,
10:49
Speaker 2: il meglio dei due mondi. In realtà non devi scegliere
10:51
Speaker 2: l'uno o l'altro. L'approccio più intelligente è usarli entrambi insieme.
10:55
Speaker 2: Ecco il modello. Imposti le notifiche di modifica per sapere
10:57
Speaker 2: quando qualcosa è cambiato. Questo ti offre una consapevolezza quasi
11:00
Speaker 2: in tempo reale. Sai che è successo qualcosa, ma non
11:02
Speaker 2: sai necessariamente cosa sia cambiato o non vuoi elaborare l'intero
11:05
Speaker 2: payload in ogni notifica. Quindi usi quella notifica come trigger.
11:10
Speaker 2: Quando ricevi una notifica push che indica una modifica, richiami
11:12
Speaker 2: la Delta Query per recuperare esattamente cosa è cambiato. Tensa
11:15
Speaker 2: cosa ti offre tutto questo. Recuperi i dati solo quando
11:17
Speaker 2: c'è un cambiamento reale, senza polling sprecato. Ottieni l'affidabilità dei
11:21
Speaker 2: Delta Token. Puoi tracciare le modifiche nel tempo, gestire la
11:23
Speaker 2: paginazione e recuperare dei fallimenti. Ed eviti la complessità di
11:27
Speaker 2: gestire payload di modifica completi in ogni notifica. La notifica
11:31
Speaker 2: dice semplicemente, ehi, guarda qui. La Delta Query fa il
11:34
Speaker 2: lavoro pesante. Ecco uno scenario reale. Immagina un'app che sincronizza
11:37
Speaker 2: i profili utente da Microsoft Entry D. Ti scrive le
11:40
Speaker 2: notifiche di modifica per il resource utente. Quando qualcuno aggiorna
11:43
Speaker 2: la propria qualifica... Microsoft Graph invia una notifica al tuo endpoint.
11:47
Speaker 2: La tua app riceve la notifica e dice ok qualcosa
11:49
Speaker 2: è cambiato per quell'utente. Quindi chiama l'endpoint della Delta Query
11:52
Speaker 2: con il suo token salvato. La Delta Query restituisce i
11:55
Speaker 2: dettagli utenti aggiornati. La tua app elaborerà la modifica e
11:58
Speaker 2: aggiorna il suo database locale. Fatto. Questo modello è supportato
12:01
Speaker 2: nativamente da Microsoft Graph. Crea una sottoscrizione per le notifiche
12:04
Speaker 2: di modifica e mantiene un Delta Link per la stessa risorsa.
12:07
Speaker 2: Quando arriva la notifica avvia un ciclo di Delta Query.
12:11
Speaker 2: È l'approccio consigliato per le app in produzione. La documentazione
12:14
Speaker 2: stessa di Microsoft lo indica come il modo per eliminare
12:16
Speaker 2: quasi del tutto il polling frequente. È un modo semplice
12:18
Speaker 2: per visualizzarlo. Qualcuno suona il campanello. Ti avvisa che c'è
12:21
Speaker 2: qualcuno alla porta. Non devi stare fuori ad aspettare i visitatori.
12:24
Speaker 2: Ma il campanello non ti dice chi è. Quindi controlli
12:26
Speaker 2: la telecam. Questo è il pool. Guardi il feed per
12:28
Speaker 2: vedere chi c'è. Campanello più telecam. Push più pool. Efficiente
12:32
Speaker 2: e reattivo. Questo modello è ibrido. Per gran parte delle
12:34
Speaker 2: applicazioni reali è lo standard di riferimento. Ottieni l'immediatezza delle
12:38
Speaker 2: notifiche push con la completezza della Delta Query. evitando i
12:41
Speaker 2: punti deboli di ogni approccio usato singolarmente. Regole pratiche per
12:45
Speaker 2: sviluppare con la Delta Query Salve a tutti e benvenuti
12:47
Speaker 2: a un altro episodio di Microsoft Knowledge Nuggets su M365FM.
12:51
Speaker 2: Sono il vostro ospite Mirko Piti. Oggi parliamo di come
12:53
Speaker 2: implementare la Delta Query in produzione. Tutto si riduce a
12:55
Speaker 2: poche regole fair. Tipo di regole che impediscono alla tua
12:58
Speaker 2: sincronizzazione di bloccarsi silenziosamente le domeniche. Segui queste sei regole
13:01
Speaker 2: e la tua implementazione sarà solida. Saltane una e ti
13:04
Speaker 2: cercherai guai. Regola 1. Salva il tuo Delta Link in
13:06
Speaker 2: un posto sicuro. Non in un file di testo sul desktop.
13:08
Speaker 2: Non codificato direttamente. Usa un database appropriato a un keystore.
13:12
Speaker 2: Pensa a questo link come alla chiave del tuo edificio.
13:14
Speaker 2: Se la perdi, rimani chiuso fuori. Torni al punto di
13:16
Speaker 2: partenza con una sincronizzazione completa. Potenzialmente gigabyte di dati che
13:19
Speaker 2: devi scaricare di nuovo da capo. Regola 2. Esegui il
13:22
Speaker 2: ciclo di sincronizzazione almeno ogni 6 giorni. I token di
13:24
Speaker 2: directory scadono per 7 giorni. Se pianifichi la sincronizzazione esattamente
13:27
Speaker 2: a 7 giorni, non hai alcun margine di errori. Un
13:29
Speaker 2: problema di rete, un weekend festivo, un review del server
13:31
Speaker 2: e il tuo token è inutilizzabile. 6 giorni ti offrono
13:34
Speaker 2: un giorno intero di margine. Regola 3. Aspettati l'errore a 4-5.
13:37
Speaker 2: Succederà di sicuro. Microsoft Graph invaliderà il tuo token durante
13:40
Speaker 2: la manutenzione o una migrazione di tema. Quando succede, il
13:43
Speaker 2: tuo codice deve rilevarlo, avviare una resincronizzazione completa e ottenere
13:45
Speaker 2: un nuovo link. Non considerarlo un bug, trattalo come una
13:48
Speaker 2: parte normale del ciclo di vita. Regola 4. Progetta l'app
13:51
Speaker 2: per gestire i duplicati. Le ripetizioni sono reali. La stessa
13:54
Speaker 2: modifica può apparire in due risposte consecutive. Se stai inserendo record,
13:57
Speaker 2: verifica prima se esistono già. Se stai aggiornando dei campi,
14:00
Speaker 2: assicurati che l'aggiornamento possa essere ripetuto in sicurezza. Regola 5.
14:04
Speaker 2: Inizia in piccolo. Non puntare il tuo codice su un
14:07
Speaker 2: tenant con 10.000 utenti al primo tentativo. Usa Graph Explorer.
14:10
Speaker 2: Scegli un intervallo breve. Verifica che il Delta Link funzioni.
14:14
Speaker 2: Fai una modifica. Controlla se appare. Prendi confidenza con il
14:16
Speaker 2: flusso prima di scalare. Regola 6. Tieni d'occhio i limiti
14:19
Speaker 2: di velocità. Microsoft Graph ti limiterà se effettui chiamate troppo velocemente.
14:23
Speaker 2: Pensa a un'autostrada. Se vai troppo veloce, verrai bloccato. Le
14:27
Speaker 2: query Delta aiutano a ridurre il volume di chiamate, ma
14:29
Speaker 2: devi comunque rispettare i limiti. Scansione le tue richieste nel tempo.
14:32
Speaker 2: Usa il back- off esponenziale quando ricevi un errore 4 in
14:34
Speaker 2: giro e 9. La velocità di sincronizzazione non conta se
14:36
Speaker 2: vieni bloccato. Un esempio reale è la sincronizzazione di eventi
14:39
Speaker 2: del calendario. Quindi come funziona esattamente? Immagina di creare un
14:43
Speaker 2: app che sincronizza gli eventi del calendario. Ecco il flusso
14:45
Speaker 2: dall'inizio alla fine. Primo passaggio, effettui la tua prima richiesta
14:49
Speaker 2: all'endpoint delta della vista calendario. Qualcosa come dammi la vista
14:52
Speaker 2: calendario delta con un orario di inizio e uno di fine.
14:55
Speaker 2: Questa è la tua base di firma. Microsoft Graph restituisce
14:57
Speaker 2: tutti gli eventi in quell'intervallo. Magari sono 100 eventi, magari 1000.
15:01
Speaker 2: Infonda quella risposta, ottieni un link delta. Lo salvi. Secondo passaggio,
15:05
Speaker 2: ciclo di sincronizzazione successivo, un'ora o un giorno dopo, chiami
15:07
Speaker 2: quel link delta salvato. Questa volta Graph non restituisce tutto,
15:10
Speaker 2: solo le modifiche. Pensalo come un bibliotecario. Chiedi libri che
15:14
Speaker 2: sono cambiati dall'ultima visita, molto più veloce che rileggere l'intera biblioteca.
15:18
Speaker 2: Una nuova riunione, un'esistente spostata in un orario diverso. Se
15:21
Speaker 2: qualcosa è stato eliminato, appari con una proprietà Iqorah Remove,
15:24
Speaker 2: così sai di doverlo rimuovere dal tuo archivio locale. Terzo passaggio,
15:27
Speaker 2: se ci sono molte modifiche, potresti ottenere un link next
15:30
Speaker 2: invece di un link delta. Significa che ci sono altre
15:32
Speaker 2: modifiche da vorare. Chiami quel link next, ottieni il batch
15:34
Speaker 2: successivo e continui finché non vedi finalmente un link delta.
15:37
Speaker 2: È così che sai di essere al passo. Pensa quanto
15:39
Speaker 2: ti fa risparmiare nel tempo. Voglio dire, pensaci davvero.