Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Microsoft Graph delta queries uitgelegd: delta link, verlopen token, fout 410 en hybride aanpak met notificaties (AI-nasynchronisatie)

Transcript

Microsoft Graph delta queries uitgelegd: delta link, verlopen token, fout 410 en hybride aanpak met notificaties (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Speaker 2: Klaar voor 10 dagen vol Microsoft 365, Copilot, AI, Azure
0:05
Speaker 2: en de mensen die de toekomst van werk vormgeven. In
0:08
Speaker 2: januari is M365 komt terug en we pakken het groter aan.
0:12
Speaker 2: Doe mee aan live sessies, praktijkdemonstraties en praktische kennis van
0:16
Speaker 2: MVP's en experts uit de hele wereld. Geen generieke sliedes,
0:20
Speaker 2: geen eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
0:25
Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu
0:30
Speaker 2: een IT-professional, ontwikkelaar of bedrijfsleider bent, er zijn sessies speciaal
0:34
Speaker 2: voor jou. Gedurende tien volle dagen kun je verschillende technologieën
0:38
Speaker 2: verkennen en in contact komen met een wereldwijde community. Kijk
0:41
Speaker 2: live mee en neem praktische inzichten mee terug naar je organisatie.
0:44
Speaker 2: Januari 2027, tien dagen, één Microsoft Community. Registratie is nu geopend.
0:51
Speaker 2: Ga vandaag nog naar... m365com.net Meld je nu aan op m365com.net
1:03
Speaker 2: en we zien je live in januari. Laat me het
1:05
Speaker 2: even schetsen. Je hebt een agenda-app op je telefoon die
1:08
Speaker 2: je afspraken voor vandaag laat zien, maar je hebt ook
1:10
Speaker 2: afspraken op je laptop en soms wijzigt iemand een afspraaktijd
1:13
Speaker 2: terwijl je niet achter je bureau zit. Wanneer je de
1:15
Speaker 2: app op je telefoon opent, verwacht je die wijziging direct
1:18
Speaker 2: te zien, niet morgen. Hoe gaan de meeste apps hiermee om?
1:20
Speaker 2: Ze downloaden elke paar minuten alle afspraken, ongeacht of er
1:23
Speaker 2: iets is gewijzigd. Denk daar eens even over na. Als
1:26
Speaker 2: je duizend agenda-afspraken hebt en er is er maar één gewijzigd,
1:28
Speaker 2: download de app alsnog alle duizend. Het is alsof je
1:30
Speaker 2: naar de supermarkt gaat en alles koopt wat er te
1:32
Speaker 2: koop is, alleen omdat je melk nodig hebt. Verspilling, toch?
1:35
Speaker 2: Dat is de ouderwetse manier van werken. En het wordt
1:37
Speaker 2: nog erger. Met een trage internetverbinding duurt die volledige download lang.
1:40
Speaker 2: Je zit daar naar een laat pictogram te staren. De
1:42
Speaker 2: app voelt traag aan. Je batterij loopt sneller leeg en
1:44
Speaker 2: de server moet al die verzoeken verwerken, zelfs als er
1:46
Speaker 2: niets is gewijzigd. Stel je nu voor dat je een
1:48
Speaker 2: app bouwt die gebruikers synchroniseert vanuit Microsoft Enterprise ID, e-mails
1:51
Speaker 2: vanuit Exchange of bestanden vanuit SharePoint. Het probleem wordt steeds groter.
1:55
Speaker 2: Je verplaatst gigabytes aan data zonder goede reden. Delta Queries
1:58
Speaker 2: lossen dit probleem precies op. In plaats van alles op
2:01
Speaker 2: te vragen, vraag je alleen wat er is veranderd sinds
2:03
Speaker 2: je laatste controle. Wat als ik alleen de nieuwe dingen
2:05
Speaker 2: kon krijgen? Dat is de vraag die Delta Querys beantwoordde.
2:11
Speaker 2: Als je ooit hebt gewacht tot een synchronisatie was voltooid
2:13
Speaker 2: op een trage verbinding, of een app hebt gebouwd die
2:15
Speaker 2: elke paar minuten een API aanroept en je hebt afgevraagd
2:17
Speaker 2: of er een betere manier is, dan is dit iets
2:18
Speaker 2: voor jou. Wat eraan komt, is een eenvoudig mechanisme voor
2:21
Speaker 2: het bijhouden van wijzigingen. Geen magie, gewoon slimme tokenberekeningen waarmee
2:25
Speaker 2: je Microsoft Graph kunt vragen, wat is er nieuw sinds
2:28
Speaker 2: mijn laatste vraag. Wat is een Delta Query? Dus, wat
2:31
Speaker 2: is een Delta Query precies? Hier is de eenvoudigste definitie.
2:34
Speaker 2: Een Delta Query vraagt Microsoft Graph alleen om de wijzigingen
2:37
Speaker 2: sinds je laatste controle, niet om alles, alleen om de nieuwe,
2:40
Speaker 2: bijgewerkte of verwijderde items. Denk aan je e-mail-inbox. Als je
2:43
Speaker 2: die ochtends opent, lees je niet elke e-mail opnieuw. Je
2:46
Speaker 2: kijkt alleen naar de nieuwe, de e-mails die zijn binnengekomen
2:48
Speaker 2: sinds je voor het laatst hebt gecontroleerd. Dat is precies
2:50
Speaker 2: wat een delta query doet, maar dan voor uw Microsoft
2:51
Speaker 2: 365 gegevens. Vergelijk dat eens met een volledige synchronisatie. Een
2:55
Speaker 2: volledige synchronisatie is alsof u elke keer dat u uw
2:57
Speaker 2: e-mail controleert een complete backup van uw hele inbox maakt.
2:59
Speaker 2: U zou duizenden kopieën van dezelfde berichten hebben. Dat is
3:02
Speaker 2: inefficiënt en traag. Een delta query is meer een wijzigingslogboek
3:05
Speaker 2: dat zegt Dit is er gebeurd sinds de laatste keer.
3:08
Speaker 2: Niets meer. Dit werkt voor veel Microsoft Graph resources, gebruikers, groepen, e-mail,
3:12
Speaker 2: agenda items, contactpersonen en bestanden. Als het in Microsoft 365 staat,
3:16
Speaker 2: is de kans groot dat er een delta-eindpunt voor is.
3:18
Speaker 2: De eerste keer dat u een delta-eindpunt aanroept, retorneert het alles.
3:20
Speaker 2: Dat is uw basislijn. U krijgt alle gegevens plus een
3:23
Speaker 2: speciale link, een zogenaamde delta-link. U slaat die link op.
3:26
Speaker 2: Bij volgende aanroepen gebruikt u die opgeslagen link en retorneert
3:28
Speaker 2: Microsoft Graph alleen de wijzigingen, toevoegingen, updates en verwijderingen. Meer niet.
3:32
Speaker 2: Waarom is dit belangrijk? Minder verplaatste gegevens betekent snellere synchronisaties.
3:35
Speaker 2: Snellere synchronisaties betekenen een betere gebruikerservaring. Je app voelt snel
3:39
Speaker 2: aan in plaats van traag. En omdat je minder data verplaatst...
3:41
Speaker 2: Gebruik je minder bandbreedte en minder processorkracht aan beide kanten.
3:44
Speaker 2: Lagere kosten, betere prestaties. Microsoft heeft Delta Queries ontworpen voor
3:48
Speaker 2: apps die actueel moeten blijven zonder de API te overbelasten.
3:51
Speaker 2: Als je ooit tegen een limiet bent aangelopen omdat je
3:53
Speaker 2: te vaak aan het pollen was, weet je waarom dit
3:54
Speaker 2: belangrijk is. Delta Queries zorgen ervoor dat je efficiënt kunt
3:57
Speaker 2: synchroniseren zonder dat je snelheid wordt beperkt. Hoe werkt het tokensysteem?
4:00
Speaker 2: Hoe onthoudt het systeem waar je bent gebleven? Daar komen
4:03
Speaker 2: tokens om de hoek kijken. Wanneer je je eerste Delta
4:05
Speaker 2: query uitvoert, stuurt Microsoft Graph je niet zomaar de data
4:08
Speaker 2: en vergeet je die. Het geeft je een zogenaamde Delta link.
4:11
Speaker 2: Zie het als een bladwijzer. Een bladwijzer die Graph precies
4:14
Speaker 2: vertelt waar je bent gestopt met lezen. Zo werkt het.
4:17
Speaker 2: Je doet je eerste verzoek en Graph stuurt alle data terug.
4:19
Speaker 2: Je volledige set gebruikers, gebeurtenissen of wat je ook bijhoudt.
4:23
Speaker 2: Onderaan dat antwoord staat een URL met een zogenaamde Delta token.
4:27
Speaker 2: Je bewaart die URL op een veilige plek. De volgende
4:29
Speaker 2: keer dat je wilt synchroniseren, hoef je geen nieuw verzoek
4:31
Speaker 2: in te dienen. In plaats daarvan hoek je de opgeslagen
4:33
Speaker 2: URL aan. Brave zegt, oh, ik herinner me je, je
4:35
Speaker 2: bent hier gestopt. Aanhalingsteken, vervolgens stuurt het alleen de wijzigingen
4:38
Speaker 2: terug die sindsdien zijn doorgevoerd. Een nieuwe gebruiker is toegevoegd,
4:41
Speaker 2: een gebeurtenis is verwijderd, het telefoonnummer van een contactpersoon is bijgewerkt.
4:44
Speaker 2: Dat is alles wat je krijgt, plus een nieuwe Delta-link
4:46
Speaker 2: voor de volgende keer. Maar wat als er veel wijzigingen zijn?
4:48
Speaker 2: Stel dat je al drie dagen niet hebt gesynchroniseerd en
4:50
Speaker 2: er honderden dingen zijn gewijzigd. Brave stuurt ze misschien niet
4:52
Speaker 2: allemaal in één reactie. Het stuurt een pagina met wijzigingen
4:55
Speaker 2: en onderaan die pagina zie je een link die volgende heet.
4:57
Speaker 2: Dat betekent dat je verder moet gaan, er is meer.
5:00
Speaker 2: Je hoopt die link aan, krijgt de volgende pagina te
5:02
Speaker 2: zien en herhaalt dit totdat je uiteindelijk een delta link ziet.
5:04
Speaker 2: Zo weet je dat je bent bijgewerkt. De link volgende
5:06
Speaker 2: betekent dat er meer gegevens aankomen. De delta link betekent
5:09
Speaker 2: dat je voorlopig klaar bent. Je kunt het zo zien,
5:11
Speaker 2: stel je voor dat je boodschappen doet. Je vult je
5:13
Speaker 2: winkelwagen met spullen en de kassier geeft je een bonnetje.
5:15
Speaker 2: Die bon is je bewijs van wat je hebt gekocht.
5:17
Speaker 2: De volgende keer dat je boodschappen doet, neem je niet
5:19
Speaker 2: de hele winkel mee. Je neemt alleen die bon mee.
5:21
Speaker 2: De kassier kijkt ernaar en zegt, oké, je hebt al
5:23
Speaker 2: melk en eieren. Je hebt alleen de dingen nodig die
5:25
Speaker 2: sindsdien zijn veranderd. Aanhalingsteken, die bon is je delta link.
5:28
Speaker 2: Je hoeft niet te onthouden wat je al hebt. De
5:30
Speaker 2: bon onthoudt het voor je en dat is het belangrijkste.
5:32
Speaker 2: Je hoeft zelf geen tijdstempels of versienummers op te slaan.
5:35
Speaker 2: Je hoeft niet uit te zoeken wat er wel en
5:37
Speaker 2: niet is veranderd. Microsoft regelt dat allemaal. Je slaat de
5:40
Speaker 2: link op, roept hem later op en laat Brevet zware
5:42
Speaker 2: werk doen. De beperkingen kun je niet negeren. Klinkt elegant, toch?
5:45
Speaker 2: Maar zoals elk slim systeem, zijn er valkuilen waar je
5:47
Speaker 2: rekening mee moet houden. Ten eerste, de vervaldatum van het token.
5:50
Speaker 2: Als je directory objecten, gebruikers, groepen of apparaten synchroniseert, is
5:53
Speaker 2: je delta token slechts 7 dagen geldig. Meer niet, als
5:56
Speaker 2: je app niet minstens 1 keer per 7 dagen synchroniseert,
5:58
Speaker 2: verloopt het token. En als het token verloopt, kun je
6:00
Speaker 2: niet zomaar verder gaan waar je gebleven was. Je moet
6:02
Speaker 2: helemaal opnieuw beginnen met een volledige synchronisatie. Dit is een
6:04
Speaker 2: groter probleem dan het lijkt. Stel je voor dat je
6:06
Speaker 2: een app bouwt die gebruikersprofielen synchroniseert. Die werkt maandenlang prima.
6:09
Speaker 2: Dan neemt iemand twee weken vakantie. Bij terugkomst is het
6:12
Speaker 2: token van de app niet meer geldig. De app moet
6:13
Speaker 2: alles opnieuw downloaden. Dat is een enorme hoeveelheid data en
6:16
Speaker 2: kost veel tijd. Ten tweede is er de gevreesde 410-GUN-fout.
6:19
Speaker 2: Zelfs als je token niet vanzelf is verlopen, kan Microsoft
6:22
Speaker 2: Graphit ongeldig maken. Dit gebeurt tijdens intern onderhoud, tenant migraties
6:25
Speaker 2: of andere wijzigingen achter de schermen waar je geen controle
6:27
Speaker 2: over hebt. Wanneer dit gebeurt, retuneert Graven HTTP 410 status.
6:31
Speaker 2: Dat is Microsofts manier om te zeggen, ik kan me
6:33
Speaker 2: dat token niet herinneren. Begin opnieuw, aanhaling steken, en ook
6:36
Speaker 2: hier geldt, je hebt een volledigere synchronisatie nodig. Ten derde
6:38
Speaker 2: zijn er verwerkingsvertragingen. Dit is iets wat veel mensen verrast.
6:41
Speaker 2: Wanneer iemand een gebruiker in Microsoft en Tra-ID bijwerkt, wordt
6:44
Speaker 2: die wijziging niet direct weergegeven in Delta-queries. Er is een vertraging.
6:47
Speaker 2: Soms seconden, soms minuten. De wijziging moet eerst door de
6:50
Speaker 2: interne systemen van Microsoft worden verwerkt voordat deze in de
6:52
Speaker 2: Delta-feed verschijnt. Dus als u een app bouwt die real-time
6:55
Speaker 2: updates vereist, is een Delta-query alleen niet voldoende. U denkt
6:57
Speaker 2: dat er niets is veranderd, terwijl er in feite gewoon
6:59
Speaker 2: nog niets is verschenen. Ten vierde, niet bijgehouden eigenschappen. Niet
7:02
Speaker 2: elke eigenschap van een resource wordt bijgehouden door een Delta-query.
7:05
Speaker 2: Neem bijvoorbeeld de eigenschap Vaardigheden van een gebruikersobject. Die gegevens
7:08
Speaker 2: staan in SharePoint, niet in de hoofddirectory. Dus als iemand
7:11
Speaker 2: de vaardigheden van een gebruiker bijwerkt, wordt er geen Delta-reactie geactiveerd.
7:14
Speaker 2: Uw app ziet de wijziging nooit. U zou die eigenschap
7:16
Speaker 2: volledig moeten uitlezen om de update te detecteren. Dit overvalt
7:19
Speaker 2: ontwikkelaars voortdurend. Ten vijfde, herhalingen. Microsoft Graph doet zijn best
7:23
Speaker 2: om duplicaten te voorkomen, maar kan dit niet garanderen. Dezelfde
7:26
Speaker 2: wijziging kan in twee op involgende Delta-reacties voorkomen. Dat betekent
7:30
Speaker 2: dat je app idempotent moet zijn. Hij moet dezelfde update
7:32
Speaker 2: twee keer kunnen verwerken zonder problemen. Als je records in
7:35
Speaker 2: een database invoegt, moet je controleren of het record al
7:37
Speaker 2: bestaat voordat je het toevoegt. Als je een veld bijwerkt,
7:39
Speaker 2: moet je ervoor zorgen dat het twee keer toepassen van
7:41
Speaker 2: dezelfde update je gegevens niet beschadigt. En ten zesde, beperkingen
7:44
Speaker 2: voor query-parameters. Op gebruikers- en groepsdelta-endpoints kun je geen expand
7:48
Speaker 2: of order bij gebruiken. Wil je de manager-eigenschap in je
7:50
Speaker 2: gebruikersynchronisatie opnemen? Dat kan, maar alleen als je Select op
7:53
Speaker 2: een specifieke manier gebruikt. Wil je gebruikers sorteren op naam?
7:56
Speaker 2: Niet mogelijk op het delta-point. Je moet deze beperkingen omzeilen
7:59
Speaker 2: met extra verzoeken. Dus, samengevat, delta-queries zijn krachtig, ze besparen bandbreedte,
8:04
Speaker 2: verminderen de latentie en zorgen ervoor dat je app snel aanvoelt.
8:06
Speaker 2: Maar het is geen perfect systeem. Tokens verlopen, wijzigingen worden vertraagd,
8:09
Speaker 2: Sommige eigenschappen zijn onzichtbaar, er komen duplicaten voor en je
8:12
Speaker 2: kunt niet alle query functies gebruiken die je gewend bent.
8:14
Speaker 2: Je moet rekening houden met deze uitzonderlijke gevallen, logica voor
8:16
Speaker 2: het opnieuw proberen inbouwen, de 410 fout afhandelen, rekening houden
8:19
Speaker 2: met herhalingen en, het allerbelangrijkste, er niet van uitgaan dat
8:22
Speaker 2: wat een delta query je laat zien het volledige plaatje is,
8:24
Speaker 2: want dat is soms niet het geval. Delta query versus wijzigingsmeldingen. Dus,
8:27
Speaker 2: als een delta query deze hiaten heeft, zoals het verlopen
8:29
Speaker 2: van tokens, verwerkingsvertragingen en niet bijgehouden eigenschappen, waarom zou je
8:32
Speaker 2: dan niet gewoon pushmeldingen gebruiken? Laten we eens kijken hoe
8:34
Speaker 2: ze werken. Wijzigingsmeldingen zijn push-gebaseerd. Microsoft roept je het point
8:38
Speaker 2: aan wanneer er iets verandert. We hebben het over seconden,
8:41
Speaker 2: niet minuten. Bijna real-time. Als iemand een gebruiker in Entra-ID bijwerkt,
8:45
Speaker 2: weet je app dat bijna direct. Geen polling nodig. Een
8:48
Speaker 2: delta-query daarentegen is pool-gebaseerd. Je vraagt om wijzigingen volgens je
8:52
Speaker 2: eigen schema. Misschien elk uur, misschien elke zes uur, misschien
8:54
Speaker 2: één keer per dag. De latentie wordt gemeten in minuten
8:57
Speaker 2: of uren, niet in seconden. Jij bepaalt wanneer je controleert
8:59
Speaker 2: en je krijgt alles te zien wat er sinds je
9:00
Speaker 2: laatste controle is veranderd. Dus, wat zijn de voordelen van push?
9:03
Speaker 2: Lage latentie is de belangrijkste. Als je een app bouwt
9:05
Speaker 2: die snel moet reageren, bijvoorbeeld om een urgente e-mailwaarschuwing te
9:08
Speaker 2: versturen wanneer een belangrijk document wordt gewijzigd, zijn wijzigingsmeldingen je
9:11
Speaker 2: beste vriend. Je wordt direct op de hoogte gesteld zodra
9:13
Speaker 2: het gebeurt. Maar pushmeldingen hebben ook nadelen. Ten eerste heb
9:16
Speaker 2: je een publiek toegankelijk HTTPS eindpunt nodig. Dat betekent dat
9:19
Speaker 2: je app vanaf internet bereikbaar moet zijn. Voor apps die
9:22
Speaker 2: binnen een bedrijfsnetwerk draaien, is dat een beveiligingsrisico. Je moet
9:25
Speaker 2: poorten openen, certificaten beheren en inkomend verkeer afhandelen. Ten tweede
9:29
Speaker 2: moet je validatie afhandelen. Wanneer je een abonnement aanmaakt, stuurt
9:32
Speaker 2: Microsoft Graph een validatietoken naar je eindpunt. Je eindpunt moet
9:35
Speaker 2: dat token binnen 10 seconden in platte tekst returneren. Zo niet,
9:38
Speaker 2: dan mislukt het abonnement. Ten derde verlopen abonnementen. Je moet
9:42
Speaker 2: ze verlengen voordat ze verlopen, anders ontvang je geen meldingen meer.
9:45
Speaker 2: En ten vierde zijn er herhaalpogingen. Als je eindpunt niet
9:47
Speaker 2: binnen drie seconden reageert, probeert Microsoft Graphit opnieuw met een
9:50
Speaker 2: exponentiële back-off tot maximaal vier uur. Als je eindpunt traag is,
9:54
Speaker 2: kunnen meldingen helemaal verloren gaan. Wat betreft de poolkant, de
9:56
Speaker 2: voordelen van Delta Queries zijn een eenvoudigere infrastructuur. Geen open
10:00
Speaker 2: eindpunt nodig, geen inkomend verkeer om te beheren. Je doet
10:02
Speaker 2: gewoon uitgaande verzoeken vanuit je app. Dat is alles. Je
10:05
Speaker 2: hebt ook meer controle over wanneer dingen gebeuren. Je kunt
10:08
Speaker 2: ze plannen voor daluren, je kunt ze in batches verwerken,
10:10
Speaker 2: je kunt wijzigingen in je eigen tempo verwerken. Maar poolqueries
10:13
Speaker 2: hebben ook nadelen. Hogere latentie, natuurlijk. Je weet pas van
10:16
Speaker 2: wijzigingen wanneer je erom vraagt. Als je elk uur een
10:18
Speaker 2: poolverzoek doet, kun je tot wel een uur achterlopen. Het
10:20
Speaker 2: verlopen van tokens is een ander risico. Als je niet
10:22
Speaker 2: vaak genoeg synchroniseert, verloopt je token en moet je opnieuw beginnen.
10:25
Speaker 2: En dan is er nog de verspeelde moeite van het pollen,
10:27
Speaker 2: zelfs als er niets is veranderd. Je doet het verzoek,
10:29
Speaker 2: krijgt een lege reactie terug en moet het de volgende
10:31
Speaker 2: cyclus opnieuw doen. Dus welke moet je kiezen? Dat hangt
10:34
Speaker 2: ervan af. Als je een lage latentie nodig hebt, bijvoorbeeld
10:36
Speaker 2: voor urgente e-mailmeldingen of real-time samenwerking, gebruik dan wijzigingsmeldingen. Als
10:40
Speaker 2: je bulk-synchronisatie uitvoert, een lokale database beheert of een app
10:44
Speaker 2: bouwt die offline werkt, gebruik dan delta-queries. Beide hebben hun nut.
10:47
Speaker 2: De hybride aanpak, het beste van twee werelden. Eigenlijk hoef
10:51
Speaker 2: je niet voor de een of de ander te kiezen.
10:52
Speaker 2: De slimste aanpak is om ze allebei te gebruiken. Zo
10:55
Speaker 2: werkt het. Je stelt wijzigingsmeldingen in om je te laten
10:57
Speaker 2: weten wanneer er iets is veranderd. Dat geeft je bijna
11:00
Speaker 2: real-time inzicht. Je weet dat er iets is gebeurd, maar
11:02
Speaker 2: je weet niet per se precies wat er is veranderd...
11:04
Speaker 2: of je wilt niet de volledige payload in elke melding verwerken.
11:07
Speaker 2: Dus gebruik je die melding als trigger. Wanneer je een
11:10
Speaker 2: pushmelding krijgt dat er iets is veranderd... roep je een
11:12
Speaker 2: delta query aan om precies op te halen wat er
11:14
Speaker 2: is veranderd. Bedenk eens wat dit je oplevert. Je haalt
11:16
Speaker 2: alleen gegevens op wanneer er daadwerkelijk een verandering is, geen
11:19
Speaker 2: onnodige polling. Je profiteert van de betrouwbaarheid van delta tokens.
11:22
Speaker 2: Je kunt wijzigingen in de loop van de tijd volgen,
11:24
Speaker 2: paginering afhandelen en herstellen van fouten. En je vermijdt de
11:26
Speaker 2: complexiteit van het verwerken van volledige wijzigingspayloads in elke melding...
11:30
Speaker 2: De melding zegt alleen, hé, kijk hier, de Delta Query
11:33
Speaker 2: doet het zware werk. Hier is een concreet scenario. Stel
11:36
Speaker 2: je een app voor die gebruikersprofielen synchroniseert vanuit Microsoft Entra ID.
11:39
Speaker 2: Je abonneert je op wijzigingsmeldingen voor de gebruikersresource. Wanneer iemand
11:43
Speaker 2: zijn of haar functietitel wijzigt, stuurt Microsoft Graph a Melding
11:46
Speaker 2: naar u het point. Uw app ontvangt die melding en zegt, oké,
11:49
Speaker 2: er is iets veranderd aan die gebruiker. Vervolgens roept de
11:51
Speaker 2: app het Delta Query het point aan met het opgeslagen token.
11:54
Speaker 2: De Delta Query retourneert de bijgewerkte gebruikersgegevens. Uw app verwerkt
11:57
Speaker 2: de wijziging en werkt de lokale database bij. Klaar. Dit
12:00
Speaker 2: patroon wordt standaard ondersteund door Microsoft Graph. U maakt een
12:03
Speaker 2: abonnement aan voorwijzigingsmeldingen en u onderhoudt een Delta-link voor dezelfde resource.
12:07
Speaker 2: Wanneer een melding binnenkomt, activeert u een Delta-query-cyclus. Dit is
12:11
Speaker 2: de aanbevolen aanpak voor productie-apps. Microsofts eigen documentatie noemt het
12:15
Speaker 2: de manier om frequent pollen vrijwel volledig te elimineren. U
12:17
Speaker 2: kunt het als volgt visualiseren. Er wordt op de deurbel gedrukt.
12:20
Speaker 2: U hoort dat er iemand voor de deur staat. U
12:21
Speaker 2: hoeft niet buiten te staan om bezoekers in de gaten
12:23
Speaker 2: te houden. Maar de deurbel vertelt u niet wie het is,
12:25
Speaker 2: dus controleert u de camera. Dat is Pool. U bekijkt
12:28
Speaker 2: de beelden om te zien wie er is. Deurbel plus camera,
12:30
Speaker 2: push plus spool, efficiënt en responsief, dat is het hybride patroon.
12:34
Speaker 2: Voor de meeste praktijktoepassingen is dit de gouden standaard. Je
12:37
Speaker 2: krijgt de directe respons van pushmeldingen met de grondigheid van
12:40
Speaker 2: Delta Queries en je vermijdt de zwakke punten van beide
12:42
Speaker 2: benaderingen wanneer ze afzonderlijk worden gebruikt. Praktische regels voor het
12:45
Speaker 2: bouwen met Delta Queries. Hallo allemaal en welkom bij een
12:47
Speaker 2: nieuwe aflevering van Microsoft Knowledge Nuggets op M365FM. Ik ben
12:51
Speaker 2: Mirko Peters, uw gastheer. Vandaag hebben we het over het
12:53
Speaker 2: bouwen met Delta Queries in een productieomgeving. Het komt neer
12:55
Speaker 2: op een paar harde regels. Regels die ervoor zorgen dat
12:58
Speaker 2: je synchronisatie niet stilletjes om twee uur s'nachts op een
12:59
Speaker 2: zondag uitvalt. Volg deze zes regels en je implementatie zal
13:02
Speaker 2: solide zijn. Mis er één en je vraagt om problemen.
13:05
Speaker 2: Regel 1. Bewaar je Delta-link op een veilige plek. Niet
13:07
Speaker 2: in een tekstbestand op je bureaublad. Niet hard gecodeerd in
13:10
Speaker 2: je code. Gebruik een geschikte database of een keystore. Beschouw
13:13
Speaker 2: deze link als de sleutel tot je gebouw. Verlies je hem,
13:15
Speaker 2: dan sta je buitengesloten. Je bent terug bij af met
13:17
Speaker 2: een volledige synchronisatie. Mogelijk gigabytes aan gegevens die je helemaal
13:20
Speaker 2: opnieuw moet downloaden. Regel 2. Voer je synchronisatieles minstens elke
13:23
Speaker 2: 6 dagen uit. Directory tokens verlopen na 7 dagen. Als
13:25
Speaker 2: je je synchronisatie precies 7 dagen van tevoren plant, heb
13:28
Speaker 2: je geen enkele march voor fouten. Een netwerkstoring, een feestweekend,
13:31
Speaker 2: een serverherstart en je token is ongeldig. Zes dagen geeft
13:34
Speaker 2: je een volledige dagbuffer. Regel 3. Verwacht de 410 fout.
13:37
Speaker 2: Die gaat voorkomen. Microsoft Graph maakt je token ongeldig tijdens
13:40
Speaker 2: onderhoud of een tenantmigratie. Wanneer dit gebeurt, moet je code
13:43
Speaker 2: dit opvangen, een volledigere synchronisatie starten en een nieuwe link verkrijgen.
13:46
Speaker 2: Beschouw dit niet als een bak, maar als een normaal
13:48
Speaker 2: onderdeel van de levenscyclus. Regel 4. Ontwerp je app zodat
13:51
Speaker 2: deze duplicaten kan verwerken. Replays zijn een reëel probleem. Dezelfde
13:54
Speaker 2: wijziging kan in twee opinvolgende reacties voorkomen. Als je records invoegt,
13:58
Speaker 2: controleer dan eerst of ze bestaan. Als je velden bijwerkt,
14:01
Speaker 2: Zorg er dan voor dat de update veilig herhaald kan worden.
14:04
Speaker 2: Regel 5. Begin klein. Richt je code niet meteen op
14:07
Speaker 2: een tenant met 10.000 gebruikers. Gebruik Graph Explorer, kies een
14:11
Speaker 2: kort datumbereik Controleer of je Delta Link werkt. Breng een
14:14
Speaker 2: wijziging aan. Kijk of deze verschijnt en raak vertrouwd met
14:16
Speaker 2: de workflow voordat je opschalt. Regel 6. Let op je snelheidslimieten.
14:20
Speaker 2: Microsoft Graph zal je beperken als je te snel aanroepen doet.
14:23
Speaker 2: Zie het als een snelweg. Als je te hard rijdt,
14:25
Speaker 2: word je geblokkeerd. Delta queries helpen je aanroepvolume te verminderen,
14:28
Speaker 2: maar je moet nog steeds de limieten respecteren. Spreik je verzoeken.
14:31
Speaker 2: Gebruik exponentiële backoff wanneer je een 429 foutmelding ziet. Je
14:35
Speaker 2: synchronisatiesnelheid doet er niet toe als je geblokkeerd wordt. Een
14:37
Speaker 2: concreet voorbeeld, het synchroniseren van agenda evenementen. Hoe werkt dit
14:41
Speaker 2: nu precies? Stel dat je een app bouwt die agenda-evenementen synchroniseert.
14:45
Speaker 2: Dit is de workflow van begin tot eind. Stap 1.
14:47
Speaker 2: Je doet je eerste verzoek aan het eindpunt voor de
14:49
Speaker 2: delta-weergave van de agenda. Bijvoorbeeld, geef me de delta-weergave van
14:53
Speaker 2: de agenda met een begin- en eindtijd. Dit is je basislijn.
14:56
Speaker 2: Microsoft Graph retourneert alle evenementen binnen dat bereik. Misschien zijn
14:59
Speaker 2: het 100 evenementen, misschien wel 1000. Onderaan dat antwoord krijg
15:02
Speaker 2: je een delta link. Je slaat het op. Stap 2.
15:04
Speaker 2: Tijdens de volgende synchronisatiecyclus, een uur later, een dag later,
15:07
Speaker 2: roep je die opgeslagen delta link op. Deze keer retourneert
15:10
Speaker 2: Graf niet alles, maar alleen de wijzigingen. Zie het als
15:12
Speaker 2: een bibliotheekkarus. Je vraagt naar de boeken die sinds je
15:14
Speaker 2: laatste bezoek zijn gewijzigd, veel sneller dan de hele bibliotheek
15:17
Speaker 2: opnieuw te doorbladeren. Een nieuwe afspraak, een bestaande afspraak die
15:20
Speaker 2: naar een ander tijdstip is verplaatst. En als iets is verwijderd,
15:22
Speaker 2: wordt het weergegeven met een add removed streepje eigenschap, zodat
15:24
Speaker 2: je weet dat je het uit je lokale opslag moet verwijderen.
15:26
Speaker 2: Stap 3. Als er veel wijzigingen zijn, krijg je mogelijk
15:29
Speaker 2: een volgende link in plaats van een delta link. Dat
15:31
Speaker 2: betekent dat er meer wijzigingen moeten worden verwerkt. Je roept
15:33
Speaker 2: die volgende link op, haalt de volgende badge op en
15:35
Speaker 2: gaat door totdat je uiteindelijk een delta link ziet. Zo
15:37
Speaker 2: weet je dat je bij bent. Bedenk hoeveel dit je
15:39
Speaker 2: op de lange termijn bespaart. Ik bedoel, denk er echt
15:41
Speaker 2: eens over na.