WEBVTT 00:00:00.480 --> 00:00:06.800 Bereit für 10 Tage Microsoft 365, Co-Pilot, KI, Azure und die Menschen, die die Zukunft der Arbeit gestalten? 00:00:07.780 --> 00:00:11.100 Diesen Januar ist die M3 der 65-Konten zurück und wird noch größer. 00:00:11.500 --> 00:00:12.280 Und wird noch größer. 00:00:12.940 --> 00:00:17.920 Seien Sie dabei bei Live Sessions, Demos aus der Praxis und praktischem Wissen von MVPs und Branchenexperten aus aller Welt. 00:00:18.880 --> 00:00:21.200 Keine generischen Folien, keine endlosen Schlagworte. 00:00:22.040 --> 00:00:28.560 Wir stellen uns den echten Herausforderungen, Co-Pilot Studio, KI Agents, Fabric, Sicherheit, Governance und Automatisierung. 00:00:28.560 --> 00:00:34.280 Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt speziell auf Sie zugeschnittene Sessions. 00:00:35.480 --> 00:00:40.080 An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen. 00:00:40.880 --> 00:00:44.320 Sehen Sie sich die Live-Übertragung an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen. 00:00:45.160 --> 00:00:48.880 Januar 2027, 10 Tage, eine Microsoft Community. 00:00:49.420 --> 00:00:50.580 Die Registrierung ist ab sofort möglich. 00:00:52.280 --> 00:00:54.660 Gehen Sie noch heute zu Ihrem Standort. 00:00:54.660 --> 00:00:58.660 Das ist m360con.net 00:00:58.660 --> 00:01:04.620 Melden Sie sich jetzt unter m360con.net an und wir sehen uns im Januar live. 00:01:05.300 --> 00:01:06.120 Lassen Sie mich ein Bild mal. 00:01:06.440 --> 00:01:09.600 Sie haben eine Kalender-App auf Ihrem Smartphone, die Ihre Besprechungen für den Tag anzeigt. 00:01:09.680 --> 00:01:14.360 Aber Sie haben auch Besprechungen auf Ihrem Laptop und manchmal ändert jemand eine Besprechungszeit, während Sie nicht an Ihrem Schreibtisch sind. 00:01:14.580 --> 00:01:18.800 Wenn Sie die App auf Ihrem Smartphone öffnen, erwarten Sie, dass diese Änderung sofort angezeigt wird, nicht erst morgen. 00:01:19.140 --> 00:01:20.180 Wir gehen die meisten Apps damit um. 00:01:20.500 --> 00:01:24.140 Sie laden alle paar Minuten jedes einzelne Ereignis herunter, unabhängig davon, ob sich etwas geändert hat oder nicht. 00:01:24.140 --> 00:01:25.400 Denken Sie mal kurz darüber nach. 00:01:25.800 --> 00:01:30.520 Wenn Sie 1000 Kalenderereignisse haben und sich nur eines davon ändert, ruft die App trotzdem alle 1000 ab. 00:01:30.900 --> 00:01:34.040 Das ist, als würden Sie in den Supermarkt gehen und alles kaufen, was es dort gibt, nur weil Sie Milch brauchen. 00:01:34.540 --> 00:01:34.960 Beschwenderisch, oder? 00:01:35.260 --> 00:01:36.200 So wurde es früher gemacht. 00:01:36.580 --> 00:01:37.200 Und es wird noch schlimmer. 00:01:37.400 --> 00:01:39.740 Bei einer langsamen Verbindung dauert der vollständige Download lange. 00:01:40.080 --> 00:01:41.340 Sie sitzen da und starren auf ein Drehfeld. 00:01:41.720 --> 00:01:42.620 Die App fühlt sich träge an. 00:01:42.920 --> 00:01:43.880 Ihr Akku entlädt sich schneller. 00:01:44.300 --> 00:01:47.060 Und der Server muss all diese Anforderungen verarbeiten, selbst wenn sich nichts geändert hat. 00:01:47.400 --> 00:01:53.440 Stellen Sie sich nun vor, Sie erstellen eine App, die Benutzer von Microsoft Entra-ID oder E-Mails von Exchange oder Dateien von SharePoint synchronisiert. 00:01:54.180 --> 00:01:55.120 Das Problem vervielfacht sich. 00:01:55.520 --> 00:01:57.480 Sie verschieben Gigabytes an Daten ohne triftigen Grund. 00:01:57.900 --> 00:01:59.540 Delta-Abfragen lösen genau dieses Problem. 00:01:59.920 --> 00:02:03.320 Anstatt nach allem zu fragen, fragen Sie nur nach den Änderungen seit Ihrer letzten Überprüfung. 00:02:03.900 --> 00:02:05.060 Wissen wir nicht einfach nur die neuen Dinge abrufen. 00:02:05.060 --> 00:02:14.260 Wenn Sie jemals darauf gewartet haben, dass eine Synchronisierung aufgrund einer langsamen Verbindung abgeschlossen wird 00:02:14.260 --> 00:02:17.800 oder eine App erstellt haben, die alle paar Minuten eine API abruft und sich gefragt haben, ob es an welcher Möglichkeit gibt, ist diese Lösung möglich. 00:02:17.880 --> 00:02:19.580 Ich sage, wie sicherlich gibt es diese Lösung, genau das Richtige für Sie. 00:02:19.680 --> 00:02:21.600 Es wird einen einfachen Mechanismus zur Änderungsnachverfolgung geben. 00:02:21.980 --> 00:02:22.700 Keine Zauberei. 00:02:23.500 --> 00:02:26.580 Sondern nur clevere Token-Mathematik, mit der Sie Microsoft Graph fragen können, 00:02:27.040 --> 00:02:28.500 was ist seit meiner letzten Abfrage neu? 00:02:29.420 --> 00:02:30.240 Was ist eine Delta-Abfrage? 00:02:31.060 --> 00:02:32.180 Was genau ist eine Delta-Abfrage? 00:02:32.680 --> 00:02:33.680 Hier ist die einfachste Definition. 00:02:34.220 --> 00:02:37.880 Eine Delta-Abfrage fragt Microsoft Graph nur nach den Änderungen seit ihrer letzten Überprüfung ab. 00:02:38.300 --> 00:02:41.520 Nicht nach allem, sondern nur nach neuen, aktualisierten oder gelöschten Elementen. 00:02:41.520 --> 00:02:42.800 Denken Sie an E-Mail-Posteingang. 00:02:43.180 --> 00:02:45.800 Wenn Sie ihn morgens öffnen, lesen Sie nicht jede E-Mail erneut. 00:02:46.260 --> 00:02:49.120 Sie schauen sich nur die neuen an, die seit ihrer letzten Überprüfung eingegangen sind. 00:02:49.660 --> 00:02:52.820 Genau das macht eine Delta-Abfrage allerdings für Ihre Microsoft 365 Daten. 00:02:53.280 --> 00:02:54.860 Vergleichen Sie das nur mit einer vollständigen Synchronisierung. 00:02:55.060 --> 00:02:57.960 Eine vollständige Synchronisierung ist so, als würden Sie jedes Mal, wenn Sie Ihre E-Mails abrufen, 00:02:58.040 --> 00:02:59.720 eine vollständige Sicherung Ihres Gesamtposteingangs erstellen. 00:02:59.840 --> 00:03:01.740 Sie hätten tausende Kopien derselben Nachrichten. 00:03:02.160 --> 00:03:03.020 Das verschwendere schon langsam. 00:03:03.440 --> 00:03:07.300 Eine Delta-Abfrage ähnelt eher einem Änderungsprotokoll mit dem Hinweis, dass es seit dem letzten Mal passiert. 00:03:07.840 --> 00:03:08.160 Wenn nicht. 00:03:08.160 --> 00:03:13.820 Dies funktioniert für viele Microsoft Graph-Ressourcen, Benutzer, Gruppen, E-Mails, Kalenderereignisse, Kontakte und Dateien. 00:03:14.280 --> 00:03:17.660 Wenn sich etwas in Microsoft Dark 65 befindet, gibt es wahrscheinlich einen Delta-Endpunkt dafür. 00:03:18.100 --> 00:03:20.640 Wenn Sie einen Delta-Endpunkt zum ersten Mal aufrufen, werden alle Daten zurückgegeben. 00:03:20.920 --> 00:03:21.580 Das ist Ihre Basis. 00:03:21.780 --> 00:03:24.180 Sie erhalten alle Daten sowie einen speziellen Link, einen sogenannten Delta-Link. 00:03:24.680 --> 00:03:25.380 Sie speichern diesen Link. 00:03:25.780 --> 00:03:28.200 Bei nachfolgenden Aufrufen verwenden Sie dann diesen gespeicherten Link 00:03:28.200 --> 00:03:31.500 und Microsoft Graph gibt nur die Änderungen, Hinzufügungen, Aktualisierungen, Andlöschungen und so. 00:03:31.880 --> 00:03:32.200 Das ist alles. 00:03:32.560 --> 00:03:33.220 Warum ist das wichtig? 00:03:33.680 --> 00:03:35.400 Weniger verschobene Daten, schnellere Synchronisierung. 00:03:35.660 --> 00:03:37.160 Schnellere Synchronisierung bedeuten eine bessere Benutzerfahrung. 00:03:37.160 --> 00:03:39.360 Ihre App arbeitet flott statt träge. 00:03:40.060 --> 00:03:44.160 Und da Sie weniger Daten verschieben, verbrauchen Sie auf beiden Seiten weniger Bandbreite und weniger Rechenleistung. 00:03:44.540 --> 00:03:45.740 Geringere Kosten, bessere Leistung. 00:03:46.400 --> 00:03:50.240 Microsoft hat Delta-Abfragen für Apps entwickelt, die aktuell bleiben müssen, ohne die API zu belasten. 00:03:50.840 --> 00:03:53.960 Wenn Sie schon einmal eine Ratenbegrenzung erreicht haben, weil Sie zu aggressiv abgefragt haben, 00:03:54.200 --> 00:03:55.220 wissen Sie, warum das wichtig ist. 00:03:55.640 --> 00:03:58.400 Mit Delta-Abfragen können Sie effizient synchronisieren, ohne dass die Daten gedrosselt werden. 00:03:58.980 --> 00:04:00.020 So funktioniert das Token-System. 00:04:00.880 --> 00:04:02.660 Wie merkt sich das System, wo Sie aufgehört haben? 00:04:03.220 --> 00:04:03.980 Wir kommen Token ins Spiel. 00:04:03.980 --> 00:04:09.500 Wenn Sie die erste Delta-Abfrage durchführen, sendet Ihnen Microsoft Graph nicht einfach nur die Daten und vergisst sie dann. 00:04:09.760 --> 00:04:11.060 Es sendet Ihnen einen sogenannten Delta-Link. 00:04:11.460 --> 00:04:12.620 Stellen Sie sich das wie ein Lesezeichen vor. 00:04:12.880 --> 00:04:15.600 Ein Lesezeichen des Graph genau mitteilt, an welcher Stelle Sie aufgehört haben zu lesen. 00:04:15.820 --> 00:04:16.620 Und so funktioniert es. 00:04:16.740 --> 00:04:19.600 Sie führen Ihre erste Anforderung durch und Graph sendet alle Daten zurück. 00:04:20.200 --> 00:04:22.720 Ihre vollständigen Benutzer, Ereignisse oder was auch immer Sie nachverfolgen. 00:04:23.120 --> 00:04:26.620 Am Ende dieser Antwort befindet sich eine URL mit einem sogenannten Delta-Token. 00:04:27.280 --> 00:04:29.320 Sie speichern diese URL und bewahren sie an einem sicheren Ort auf. 00:04:29.320 --> 00:04:31.780 Beim nächsten Synchronisieren stellst du keine neue Anfrage. 00:04:32.160 --> 00:04:33.740 Seitdessen rufst du die gespeicherte URL auf. 00:04:34.080 --> 00:04:35.160 Graph sagt, ach, ich erinnere mich an dich. 00:04:35.480 --> 00:04:36.180 Du hast hier aufgehört. 00:04:37.420 --> 00:04:39.560 Dann sendet es nur die Änderungen seit diesem Zeitpunkt zurück. 00:04:40.100 --> 00:04:43.900 Ein neuer Benutzer wurde hinzugefügt, ein Ereignis wurde gelöscht, die Telefonnummer eines Kontakts wurde aktualisiert. 00:04:44.260 --> 00:04:44.920 Es ist alles, was du willst. 00:04:45.220 --> 00:04:46.540 Du hast einen neuen Delta-Link für das nächste Mal. 00:04:47.260 --> 00:04:48.400 Was aber, wenn es viele Änderungen gibt? 00:04:48.740 --> 00:04:51.600 Angenommen, du hast seit drei Tagen nicht synchronisiert und hunderte von Dingen haben sie gämt. 00:04:51.800 --> 00:04:53.300 Graph sendet sie möglicherweise nicht anderen an. 00:04:53.680 --> 00:04:57.200 Es sendet eine Seite mit Änderungen und unten auf dieser Seite siehst du einen sogenannten Next-Link. 00:04:57.200 --> 00:04:59.460 Das bedeutet, dass du weitermachst, es gibt noch mehr. 00:04:59.840 --> 00:05:04.120 Du rufst diesen Next-Link auf, rufst die nächste Seite auf und wiederholst den Vorgang, bis du schließlich einen Delta-Link siehst. 00:05:04.440 --> 00:05:05.620 So weißt du, dass du auf dem Laufenden bist. 00:05:05.960 --> 00:05:07.400 Der Next-Link bedeutet, dass du vorstätig bist. 00:05:07.720 --> 00:05:09.220 Der Delta-Link bedeutet, dass du vorstätig bist. 00:05:09.540 --> 00:05:10.660 Hier ist eine Möglichkeit, wie du das vorstellen kannst. 00:05:10.880 --> 00:05:15.200 Stellen Sie sich vor, Sie gehen einkaufen, kaufen einen Einkaufswagen voller Sachen und die Kassiererin gibt Ihnen eine Quittung. 00:05:15.580 --> 00:05:16.960 Diese Quittung ist der Nachweis für den Kauf. 00:05:17.420 --> 00:05:19.320 Wenn Sie das nächste Mal einkaufen, bringen Sie nicht den ganzen Laden mit. 00:05:19.680 --> 00:05:20.700 Sie bringen nur diese Quittung mit. 00:05:21.060 --> 00:05:24.120 Die Kassiererin zieht sie sich an und sagt, richtig, Sie haben bereits Milch und Eier. 00:05:27.200 --> 00:05:29.860 Das ist der Delta-Link. Sie müssen sich nicht merken, was Sie bereits haben. 00:05:30.120 --> 00:05:32.200 Die Quittung merkt sich das für Sie und das ist der springende Punkt. 00:05:32.640 --> 00:05:35.160 Sie müssen keine Zeitstempel oder Versionsnummern selbst speichern. 00:05:35.540 --> 00:05:37.360 Sie müssen nicht herausfinden, was sich geändert hat und was nicht. 00:05:37.860 --> 00:05:39.520 Microsoft kümmert sich um die gesamte Nachverfolgung. 00:05:39.820 --> 00:05:42.480 Sie speichern einfach den Link, rufen ihn später auf und überlassen Graph die Harte ab. 00:05:42.800 --> 00:05:44.180 Die Einschränkungen, die Sie nicht ignorieren können. 00:05:44.580 --> 00:05:48.240 Klingt elegant, oder? Aber wie bei jedem cleveren System gibt es auch hier Haken, die Sie kennen müssen. 00:05:48.640 --> 00:05:50.020 Zunächst einmal das Ablaufdatum des Token. 00:05:50.360 --> 00:05:55.080 Wenn Sie Verzeichnisobjekte, Benutzergruppen oder Geräte synchronisieren, ist der Delta-Token nur sieben Tage lang gültig. 00:05:55.580 --> 00:05:55.860 Ist alles. 00:05:55.860 --> 00:05:59.480 Wenn Ihre App nicht mindestens alle sieben Tage synchronisiert wird, läuft dieses Token ab. 00:05:59.780 --> 00:06:02.180 Und wenn es abläuft, können Sie nicht einfach dort weitermachen, wo Sie aufgehört haben. 00:06:02.380 --> 00:06:04.240 Sie müssen mit einer vollständigen Synchronisierung von vorne fahren. 00:06:04.520 --> 00:06:05.880 Das ist ein größeres Problem, was es sich anhört. 00:06:06.140 --> 00:06:08.120 Stellen Sie sich vor, Sie erstellen eine App, die Benutzerprofile synchronisiert. 00:06:08.340 --> 00:06:09.400 Sie läuft monatelang einwandfrei. 00:06:09.680 --> 00:06:10.920 Dann nimmt sich jemand ein zwei Wöchigen Urlaub. 00:06:11.280 --> 00:06:12.880 Wenn er zurückkommt, ist das Token der App tot. 00:06:13.200 --> 00:06:14.900 Die App muss alles von Grund auf neu herunterladen. 00:06:15.200 --> 00:06:16.540 Das sind viele Daten und viel Zeitaufwand. 00:06:17.000 --> 00:06:18.840 Zweitens gibt es den gefürchteten 410-Fehler. 00:06:19.220 --> 00:06:22.620 Selbst wenn Ihr Token nicht auf natürliche Weise abgelaufen ist, kann Microsoft Graph es ungültig machen. 00:06:22.620 --> 00:06:28.040 Dies geschieht während interner Wartungsarbeiten, Mandantenmigrationen oder anderen Änderungen im Hintergrund, die Sie nicht kontrollieren können. 00:06:28.640 --> 00:06:31.560 In diesem Fall gibt Graph den HTTP 410-Status zurück. 00:06:31.980 --> 00:06:34.240 Auf diese Weise sagt Microsoft, ich kann mich nicht an dieses Token erinnern. 00:06:34.580 --> 00:06:35.180 Fangen Sie noch mal an. 00:06:35.560 --> 00:06:37.160 Und wieder benötigen Sie eine vollständige Neuseigung. 00:06:37.560 --> 00:06:38.740 Drittens Verarbeitungsverzögerung. 00:06:39.460 --> 00:06:40.880 Hier ist etwas, das viele Leute überraschen. 00:06:41.600 --> 00:06:46.080 Wenn jemand einen Benutzer in der Microsoft Entra-ID aktualisiert, wird diese Änderung nicht sofort in Delta-Abfragen angezeigt. 00:06:46.480 --> 00:06:47.240 Es gibt eine Verzögerung. 00:06:47.660 --> 00:06:48.740 Manchmal Sekunden, manchmal Minuten. 00:06:48.740 --> 00:06:53.340 Die Änderung muss über die internen Systeme von Microsoft propagiert werden, bevor sie im Delta-Feed angezeigt wird. 00:06:53.640 --> 00:06:57.300 Wenn Sie also eine App entwickeln, die Echtzeitaktualisierung benötigt, reicht die Delta-Abfrage allein nicht aus. 00:06:57.640 --> 00:07:00.300 Sie werden denken, dass sich nichts geändert hat, während in Wirklichkeit etwas nicht angezeigt wird. 00:07:00.600 --> 00:07:02.100 Viertens nicht nachverfolgte Eigenschaften. 00:07:02.480 --> 00:07:05.000 Nicht jede Eigenschaft einer Ressource wird von Delta-Abfragen nachverfolgen. 00:07:05.500 --> 00:07:07.200 Nehmen Sie die Eigenschaftsskills eines Benutzerobjekts. 00:07:07.540 --> 00:07:09.860 Diese Daten befinden sich in SharePoint, nicht im Hauptverzeichensspeicher. 00:07:10.080 --> 00:07:14.020 Wenn also jemand die Fähigkeiten eines Benutzers aktualisiert, löst diese Änderung keine Delta-Antwort aus. 00:07:14.460 --> 00:07:15.080 Ihre App sieht sie nie. 00:07:15.600 --> 00:07:18.240 Sie müssen diese Eigenschaft vollständig lesen, um die Aktualisierung zu erfassen. 00:07:18.680 --> 00:07:20.000 Das überrascht Entwickler immer wieder. 00:07:20.840 --> 00:07:21.700 Fünftens Wiedergaben. 00:07:22.060 --> 00:07:25.440 Microsoft Graph versucht nach besten Kräften Duplikate zu vermeiden, garantiert dies jedoch nicht. 00:07:26.320 --> 00:07:28.980 Die selbe Änderung kann in zwei aufeinanderfolgenden Delta-Antworten auftreten. 00:07:29.340 --> 00:07:30.960 Das bedeutet, dass Ihre App idempotent sein muss. 00:07:31.240 --> 00:07:33.860 Sie muss dieselbe Aktualisierung zweimal verarbeiten können, ohne dass sie abstürzen. 00:07:34.120 --> 00:07:38.260 Wenn Sie Datensätze in eine Datenbank einfügen, müssen Sie vor dem Hinzufügen überprüfen, ob der Datensatz bereits war. 00:07:38.260 --> 00:07:43.260 Wenn Sie ein Feld aktualisieren, müssen Sie sicherstellen, dass Ihre Daten durch zweimaliges Anwenden derselben Aktualisierung nicht beschädigt werden. 00:07:43.480 --> 00:07:45.260 Und sechstens Einschränkungen bei Abfrageparametern. 00:07:45.260 --> 00:07:48.760 An Benutzerngruppen Delta-Endpunkten können Sie Expand oder Auto-By-Ride nicht verwenden. 00:07:49.220 --> 00:07:51.620 Sie möchten die Eigenschaft Manager in Ihre Benutzersynchronisierung einbeziehen. 00:07:52.240 --> 00:07:54.600 Sie können dies tun jedoch nur, wenn Sie Select auf eine bestimmte Weise verwenden. 00:07:55.000 --> 00:07:56.180 Sie möchten Benutzer nach Namen sortieren? 00:07:56.540 --> 00:07:57.740 Dies ist am Delta-Endpunkt nicht möglich. 00:07:58.260 --> 00:08:00.440 Sie müssen diese Einschränkungen mit zusätzlichen Anforderungen umgehen. 00:08:00.440 --> 00:08:01.500 Hier ist die Zusammenfassung. 00:08:01.760 --> 00:08:06.040 Die Delta-Abfrage ist leistungsstark, spart Bandbreite, reduziert die Latenz und sorgt dafür, dass sich Ihre App schnell anfühlt. 00:08:06.340 --> 00:08:07.420 Es ist jedoch kein perfektes System. 00:08:07.820 --> 00:08:11.820 Token laufen ab, Änderungen werden verzögert, einige Eigenschaften sind unsichtbar, Duplikate treten auf. 00:08:12.040 --> 00:08:14.000 Sie können nicht alle Abfragefunktionen verwenden, die Sie gewohnt sind. 00:08:14.360 --> 00:08:20.120 Sie müssen diese Sonderfälle einplanen, eine Wiederholungslogik integrieren, den Fehler 410 verarbeiten, mit Wiederholungen rechnen 00:08:20.120 --> 00:08:24.400 und vor allem nicht davon ausgehen, dass die Delta-Query Ihnen das vollständige Bild anzeigt, denn manchmal ist dies nicht der Fall. 00:08:25.300 --> 00:08:27.120 Delta-Query im Vergleich zur Änderungsbenachrichtigung. 00:08:27.840 --> 00:08:31.880 Wenn Delta-Query diese Lücken aufweist, Tokenablauf, Verarbeitungsverzögerung, nicht nachverfolgte Eigenschaften, 00:08:31.960 --> 00:08:33.640 warum verwenden Sie dann nicht einfach Push-Benachrichtigungen? 00:08:34.060 --> 00:08:34.980 Vergleichen wir, wie sie funktionieren. 00:08:35.940 --> 00:08:36.960 Änderungsbenachrichtigungen sind Push-basiert. 00:08:37.700 --> 00:08:39.740 Microsoft ruft Ihren Endpunkt an, wenn sich etwas ändert. 00:08:40.140 --> 00:08:41.400 Wir sprechen hier von Sekunden, nicht von Minuten. 00:08:41.820 --> 00:08:42.500 Nahezu Echtzeit. 00:08:43.020 --> 00:08:46.800 Wenn jemand einen Benutzer in EntraID aktualisiert, weiß Ihre App dies fast sofort. 00:08:47.640 --> 00:08:48.580 Keine Abfrage vorderlich. 00:08:48.580 --> 00:08:50.760 Delta-Query hingegen ist pull-basiert. 00:08:51.160 --> 00:08:52.500 Sie fragen nach Ihrem Zeitplan nach Änderung. 00:08:52.860 --> 00:08:55.300 Vielleicht jede Stunde, vielleicht alle sechs Stunden, vielleicht einmal am Tag. 00:08:55.740 --> 00:08:57.840 Die Latenz wird in Minuten oder Stunden gemessen, nicht in Sekunden. 00:08:58.320 --> 00:09:01.100 Sie entscheiden, wann Sie die Überprüfung durchführen möchten und Sie erhalten eine letzte Überprüfung. 00:09:01.440 --> 00:09:02.620 Was sind also die Vorteile von Push? 00:09:02.860 --> 00:09:04.100 Die geringe Latenz hat größte Vorteil. 00:09:04.380 --> 00:09:06.480 Wenn Sie eine App entwickeln, die schnell reagieren muss, zum 00:09:06.480 --> 00:09:10.360 B, um eine dringende E-Mail-Benachrichtigung zu senden, wenn ein wichtiges Dokument geändert wird, sind 00:09:10.360 --> 00:09:12.260 Änderungsbenachrichtigungen genau das Richtige für Sie. 00:09:12.720 --> 00:09:14.200 Sie werden sofort benachrichtigt, wenn es geändert wird. 00:09:14.620 --> 00:09:15.500 Push hat jedoch auch Nachteile. 00:09:15.500 --> 00:09:18.300 Erstens benötigen Sie einen öffentlich zugänglichen HTTPS-Endpunkt. 00:09:18.720 --> 00:09:20.840 Das bedeutet, dass Ihre App über das Internet erreichbar sein muss. 00:09:21.460 --> 00:09:24.640 Für Apps, die in einem Unternehmensnetzwerk ausgeführt werden, stellt dies ein Sicherheitsrisiko dar. 00:09:25.060 --> 00:09:28.360 Sie müssen Ports öffnen, Zertifikate verwalten und eingehenden Datenverkehr verarbeiten. 00:09:28.740 --> 00:09:30.200 Zweitens müssen Sie die Validierung durchführen. 00:09:30.660 --> 00:09:34.500 Wenn Sie ein Abonnement erstellen, sendet Microsoft Graph ein Validierungstoken an Ihren Endpunkt. 00:09:35.020 --> 00:09:37.860 Ihr Endpunkt muss dieses Token innerhalb von zehn Sekunden im Klartext zurückgeben. 00:09:38.340 --> 00:09:39.540 Andernfalls schlägt das Abonnement für. 00:09:39.540 --> 00:09:41.500 Drittens laufen Abonnements ab. 00:09:41.880 --> 00:09:44.960 Sie müssen sie erneuern, bevor sie ablaufen, da Sie sonst keine Benachrichtigungen mehr erhalten. 00:09:45.460 --> 00:09:46.620 Und viertens gibt es Wiederholungsversuche. 00:09:47.040 --> 00:09:52.100 Wenn Ihr Endpunkt nicht innerhalb von drei Sekunden antwortet, versucht es Microsoft Graph mit exponentieller Verzögerung von bis zu vier Stunden. 00:09:52.820 --> 00:09:55.480 Wenn Ihr Endpunkt langsam ist, können Benachrichtigungen vollständig verloren gehen. 00:09:55.860 --> 00:09:59.140 Auf der Poolseite liegen die Vorteile von Delta-Abfragen in der einfacheren Infrastruktur. 00:09:59.400 --> 00:10:02.120 Es wird kein öffentlicher Endpunkt benötigt und es muss kein eingehender Datenverkehr verweilen. 00:10:02.340 --> 00:10:04.500 Sie stellen einfach ausgehende Anforderungen von Ihrer App aus. 00:10:04.500 --> 00:10:05.340 Das ist alles. 00:10:05.740 --> 00:10:07.560 Sie haben auch mehr Kontrolle darüber, wann etwas passiert. 00:10:07.940 --> 00:10:12.660 Sie können die Abfragen für Zeiten mit geringer Auslastung planen, Sie in Stapeln verarbeiten und Änderungen in Ihrem eigenen Tempo verarbeiten. 00:10:13.080 --> 00:10:13.840 Pull hat aber auch Nachteile. 00:10:14.400 --> 00:10:15.340 Natürlich ist die Latenz höher. 00:10:15.660 --> 00:10:17.460 Sie erfahren erst von Änderungen, wenn Sie die Abfrage durchführen. 00:10:17.680 --> 00:10:20.200 Wenn Sie stündlich einen Pull durchführen, können Sie bis zu einer Stunde im Rückstand sein. 00:10:20.520 --> 00:10:21.800 Ein weiteres Risiko ist der Ablaufstoke. 00:10:22.140 --> 00:10:25.280 Wenn Sie nicht oft genug synchronisieren, ist Ihr Token ungültig und Sie müssen von vorne beginnen. 00:10:25.500 --> 00:10:28.220 Außerdem entsteht der vergottete Aufwand für Abfragen, selbst wenn sich nichts geändert hat. 00:10:28.220 --> 00:10:32.380 Sie stellen die Anforderungen, erhalten eine leere Antwort und müssen den Vorgang im nächsten Zyklus wiederholen. 00:10:32.380 --> 00:10:34.260 Für welche Methode zu entscheiden? Das hängt davon ab. 00:10:34.480 --> 00:10:35.840 Wenn Sie eine niedrige Latenz benötigen. 00:10:36.040 --> 00:10:40.320 B für dringende E-Mail-Benachrichtigungen oder die Zusammenarbeit in Echtzeit, verwenden Sie Änderungsbenachrichtigungen. 00:10:40.560 --> 00:10:46.060 Wenn Sie eine Massensynchronisierung durchführen, eine lokale Datenbank verwalten oder eine App erstellen, die offline funktioniert, verwenden Sie Delta Query. 00:10:46.620 --> 00:10:47.300 Beides hat seinen Platz. 00:10:47.980 --> 00:10:50.140 Der hybride Ansatz. Das Beste aus beiden Welten. 00:10:50.600 --> 00:10:52.360 Eigentlich müssen Sie sich nicht für das eine oder das andere entscheiden. 00:10:52.800 --> 00:10:54.240 Am besten ist es, beides zusammen zu verwenden. 00:10:54.700 --> 00:10:58.680 Hier ist das Muster. Sie richten Änderungsbenachrichtigungen ein, um sie zu benachrichtigen, wenn sich etwas gähnt. 00:10:58.960 --> 00:11:00.620 Dadurch erhalten Sie Informationen nahezu in Echtzeit. 00:11:00.620 --> 00:11:04.160 Sie wissen, dass etwas passiert ist, wissen aber nicht unbedingt genau, was sich geändert hat. 00:11:04.400 --> 00:11:07.020 Oder Sie möchten nicht die gesamte Nutzlast in jeder Benachrichtigung verarbeiten. 00:11:07.500 --> 00:11:09.620 Stattdessen verwenden Sie diese Benachrichtigung als Trigger. 00:11:10.000 --> 00:11:14.740 Wenn Sie eine Push-Benachrichtigung erhalten, die besagt, dass sich etwas geändert hat, rufen Sie Delta Query auf, um genau die Änderung abzurufen. 00:11:15.160 --> 00:11:16.080 Überlegen Sie, was Ihnen das bringt. 00:11:16.600 --> 00:11:19.340 Sie rufen nur dann Daten ab, wenn es tatsächlich eine Änderung gibt. Keine unnötigen Abfragen. 00:11:19.840 --> 00:11:21.480 Sie profitieren von der Zuverlässigkeit von Delta-Ton. 00:11:21.860 --> 00:11:25.480 Sie können Änderungen im Zeitverlauf nachverfolgen, die Paginierung verarbeiten und Fehler beheben. 00:11:25.480 --> 00:11:30.040 Und Sie vermeiden die Komplexität, die mit der Verarbeitung vollständiger Änderungsnutzlasten in jeder Benachrichtigung verbunden ist. 00:11:30.540 --> 00:11:32.640 Die Benachrichtigung sagt einfach, hey, schau mal hier rüber. 00:11:33.200 --> 00:11:34.640 Die Delta-Abfrage übernimmt die schwere Arbeit. 00:11:35.100 --> 00:11:35.880 Hier ist ein reales Szenario. 00:11:36.420 --> 00:11:39.300 Stellen Sie sich eine App vor, die Benutzerprofile von Microsoft Entra ID synchronisiert. 00:11:39.700 --> 00:11:42.040 Sie abonnieren Änderungsbenachrichtigungen für die Benutzerressourcen. 00:11:42.640 --> 00:11:46.860 Wenn jemand seine Berufsbezeichnung aktualisiert, sendet Microsoft Graph eine Benachrichtigung an Ihren Endpunkt. 00:11:47.340 --> 00:11:50.480 Ihre App empfängt diese Benachrichtigung und sagt, okay, bei diesem Nutzer hat sich etwas geändert. 00:11:51.160 --> 00:11:54.180 Anschließend ruft Sie den Endpunkt der Delta-Abfrage mit Ihrem gespeicherten Token auf. 00:11:54.460 --> 00:11:56.600 Die Delta-Abfrage gibt die aktualisierten Nutzer Details zurück. 00:11:57.040 --> 00:11:59.420 Ihre App verarbeitet die Änderungen und aktualisiert Ihre lokale Daten. 00:12:00.400 --> 00:12:02.800 Dieses Muster wird von Microsoft Graph nativ unterstützt. 00:12:03.180 --> 00:12:07.260 Sie erstellen ein Abonnement für Änderungsbenachrichtigungen und pflegen einen Delta-Link für dieselbe Ressource. 00:12:07.860 --> 00:12:10.580 Wenn eine Benachrichtigung eintrifft, lösen Sie einen Delta-Abfragezyklus aus. 00:12:11.120 --> 00:12:12.880 Dies ist der empfohlene Ansatz für Produktions-Apps. 00:12:13.460 --> 00:12:17.480 In der Dokumentation von Microsoft selbst wird dies als Möglichkeit bezeichnet, häufige Abfragen nahezu zu eliminieren. 00:12:17.480 --> 00:12:20.100 Hier ist eine einfache Möglichkeit, sich das vorzustellen, es wird geklingelt. 00:12:20.380 --> 00:12:21.600 Das sagt Ihnen, dass jemand vor der Tür steht. 00:12:21.900 --> 00:12:23.560 Sie müssen nicht draußen stehen und auf Besucher achten. 00:12:23.960 --> 00:12:25.380 Die Türklingel sagt Ihnen doch nicht, wer es ist. 00:12:25.740 --> 00:12:26.660 Sie überprüfen also die Kamera. 00:12:27.000 --> 00:12:27.360 Das ist ein Pull. 00:12:27.700 --> 00:12:29.220 Sie schauen sich den Feed an, um zu sehen, wer da ist. 00:12:29.600 --> 00:12:30.400 Türklingel plus Kamera. 00:12:30.780 --> 00:12:31.360 Push plus Pull. 00:12:31.780 --> 00:12:32.800 Effizient und Reaktionsschneidung. 00:12:33.000 --> 00:12:33.800 Das ist das hybride Must. 00:12:34.160 --> 00:12:36.500 Für die meisten realen Anwendungen ist dies der Goldstandard. 00:12:37.000 --> 00:12:40.560 Sie erhalten die Unmittelbarkeit von Push-Benachrichtigungen mit der Gründlichkeit von Delta-Query 00:12:40.560 --> 00:12:43.820 und vermeiden die Schwächen jedes Ansatzes, wenn er einzeln verwendet wird. 00:12:44.620 --> 00:12:46.280 Praktische Regeln für die Entwicklung mit Delta-Query. 00:12:46.280 --> 00:12:49.900 Hallo zusammen und herzlich willkommen zu einer weiteren Folge von Microsoft Knowledge Nuggets 00:12:49.900 --> 00:12:50.980 auf M35-HCFM. 00:12:51.220 --> 00:12:52.260 Ich bin der Moderator Mekopetas. 00:12:52.540 --> 00:12:54.920 Heute sprechen wir über die Entwicklung mit Delta-Query in der Produktion. 00:12:55.340 --> 00:12:56.660 Es läuft auf ein paar strenge Regeln hinaus. 00:12:57.020 --> 00:12:59.980 Solche, die verhindern, dass Ihre Synchronisierung sonntags um zwei morgens still und leise abrühren. 00:13:00.260 --> 00:13:02.900 Verfolgen Sie diese sechs Regeln und Ihre Implementierung wird solide sein. 00:13:03.160 --> 00:13:04.660 Vergessen Sie eine und Sie bekommen Probleme. 00:13:05.040 --> 00:13:06.880 Regel Nummer eins speichern Sie Ihren Delta-Link in einem Sichereren. 00:13:07.220 --> 00:13:08.620 Nicht in einer Textdatei auf Ihrem Desktop. 00:13:09.200 --> 00:13:10.180 Nicht fest in Ihrem Code kodiert. 00:13:10.580 --> 00:13:12.620 Verwenden Sie eine geeignete Datenbank oder einen Schlüsselspot. 00:13:12.620 --> 00:13:14.520 Stellen Sie sich diesen Link als einen Schlüssel zu Ihrem Gebäude. 00:13:14.520 --> 00:13:15.980 Wenn Sie ihn verlieren, sind Sie ausgesperrt. 00:13:16.280 --> 00:13:18.280 Sie müssen bei einer vollständigen Synchronisierung wieder bei Null anfangen. 00:13:18.640 --> 00:13:20.840 Möglicherweise müssen Sie Gigabytes an Daten erneut abrufen. 00:13:21.200 --> 00:13:23.640 Regel zwei führen Sie die Synchronisierungsschleife mindestens alle sechs Tage. 00:13:23.960 --> 00:13:25.200 Verzeichnis-Token laufen nach sieben Tagen. 00:13:25.580 --> 00:13:27.980 Wenn Sie die Synchronisierung auf die Minute genau nach sieben Tagen planen, 00:13:28.040 --> 00:13:29.060 haben Sie keinen Spielraum für Fehler. 00:13:29.640 --> 00:13:33.180 Ein Netzwerkausfall, ein Feiertagswochenende, ein Server-Neustart und schon ist Ihr Token tot. 00:13:33.700 --> 00:13:35.360 Sechs Tage geben Ihnen den ganzen Tag Puffer. 00:13:35.720 --> 00:13:37.660 Regel drei rechnen Sie mit dem Fehler, wenn Sie mit auftreten. 00:13:38.180 --> 00:13:41.660 Microsoft Graph erklärt Ihr Token während der Wartung oder einer Mandantenmigration für ungültig. 00:13:41.660 --> 00:13:43.620 Wenn dies geschieht, muss Ihr Code dies abfangen. 00:13:43.780 --> 00:13:46.480 Eine vollständige erneute Synchronisierung auslösen und einen neuen Link abrufen. 00:13:46.720 --> 00:13:49.620 Behandeln Sie dies nicht als Fehler, sondern als normalen Teil des Lebenszyklus. 00:13:49.960 --> 00:13:52.240 Regel vier. Entwerfen Sie Ihre Absurd, dass Sie Duplikate verarbeiten. 00:13:52.600 --> 00:13:53.320 Wiedergaben sind real. 00:13:53.840 --> 00:13:56.060 Dieselbe Änderung kann in zwei aufeinanderfolgenden Antworten auftreten. 00:13:56.760 --> 00:13:59.380 Wenn Sie Datensätze einfügen, überprüfen Sie zuerst, ob sie vorhanden sind. 00:13:59.700 --> 00:14:02.800 Wenn Sie Felder aktualisieren, stellen Sie sicher, dass die Aktualisierung gefahrlos wiederholt wird. 00:14:03.940 --> 00:14:04.780 Regel fünf. 00:14:05.520 --> 00:14:06.200 Fangen Sie klein an. 00:14:06.560 --> 00:14:09.740 Beweisen Sie Ihren Code nicht gleich beim ersten Versuch auf einen Mandanten mit 10.000 Nutzern. 00:14:09.740 --> 00:14:12.080 Verwenden Sie Graph Explorer. Wählen Sie einen kurzen Zeitraum aus. 00:14:12.200 --> 00:14:13.800 Überprüfen Sie, ob Ihre Delta-Verknüpfung funktioniert. 00:14:13.940 --> 00:14:16.500 Nehmen Sie eine Änderung vor. Prüfen Sie, ob sie angezeigt wird. 00:14:16.560 --> 00:14:18.140 Machen Sie sich mit dem Ablauf vertraut, bevor Sie hochskalieren. 00:14:18.240 --> 00:14:19.800 Regel sechs. Achten Sie auf Ihre Datendemits. 00:14:20.300 --> 00:14:22.460 Microsoft Graph trosselt Sie, wenn Sie zu schnell aufrufen. 00:14:22.980 --> 00:14:24.080 Stellen Sie sich das wie eine Autobahn vor. 00:14:24.320 --> 00:14:25.880 Zu viel Geschwindigkeit und Sie werden blockiert. 00:14:26.920 --> 00:14:30.320 Delta-Abfragen helfen, Ihr Aufrufvolumen zu reduzieren, aber Sie müssen die Demits trotzdem einhalten. 00:14:30.780 --> 00:14:31.740 Verteilen Sie Anfallungen am Stück. 00:14:32.080 --> 00:14:34.640 Verwenden Sie exponentielles Backoff, wenn Sie einen 429-Fehler sehen. 00:14:34.860 --> 00:14:36.860 Ihre Synchronisierungsgeschwindigkeit spielt keine Rolle beim Blöken. 00:14:36.860 --> 00:14:40.460 Ein konkretes Beispiel, die Synchronisierung von Kalenderereignissen. 00:14:41.000 --> 00:14:41.940 Wie funktioniert das nun konkret? 00:14:42.480 --> 00:14:44.580 Nehmen wir an, Sie erstellen eine App, die Kalenderereignisse synchronisiert. 00:14:45.020 --> 00:14:46.240 Hier ist der Ablauf von Anfang bis Ende. 00:14:47.000 --> 00:14:50.980 Schritt 1, Sie senden Ihre erste Anforderung an den Delta-Endpunkt der Kalenderansicht, 00:14:51.040 --> 00:14:53.720 etwa Bereitstellung einer Kalenderansicht mit einer Start- und Endzeit. 00:14:55.160 --> 00:14:56.040 Dies ist Ihre Basislinie. 00:14:56.360 --> 00:14:58.360 Microsoft Graph gibt alle Ereignisse in diesem Bereich zu holen. 00:14:58.880 --> 00:15:00.580 Es können hunderte Ereignisse sein, vielleicht auch tausend. 00:15:01.000 --> 00:15:02.960 Am Ende dieser Antwort erhalten Sie einen Delta-Link. 00:15:03.380 --> 00:15:03.880 Sie speichern ihn. 00:15:03.880 --> 00:15:07.220 Schritt 2, beim nächsten Synchronisierungszyklus, eine Stunde oder einen Tag später, 00:15:07.340 --> 00:15:08.820 rufen Sie diesen gespeicherten Delta-Link auf. 00:15:09.180 --> 00:15:11.500 Diesmal gibt Graph nicht alles zurück, sondern nur die Änderungen. 00:15:11.900 --> 00:15:13.020 Stellen Sie sich das für den Bibliothek auf. 00:15:13.420 --> 00:15:15.620 Sie fragen nach den Büchern, die sich seit Ihrem letzten Besuch geändert haben. 00:15:15.900 --> 00:15:17.860 Das ist viel schneller, als die gesamte Bibliothek erneut zu lesen. 00:15:18.320 --> 00:15:20.820 Ein neues Meeting, ein bestehendes, das auf einen anderen Zeitpunkt verschoben wurde. 00:15:21.400 --> 00:15:24.300 Und wenn etwas gelöscht wurde, wird es mit der Eigenschaft Add Removed angezeigt, 00:15:24.440 --> 00:15:26.440 sodass Sie wissen, dass Sie es aus Ihrem lokalen Store entfernen müssen. 00:15:26.600 --> 00:15:30.960 Schritt 3, wenn es viele Änderungen gibt, erhalten Sie möglicherweise einen Next-Link anstelle eines Delta-Links. 00:15:31.260 --> 00:15:32.860 Das bedeutet, dass mehr Änderungen verarbeitet werden müssen. 00:15:33.880 --> 00:15:37.020 Schauen Sie den Next-Link auf, rufen den nächsten Badge ab und fahren fort, bis Sie schließlich einen Delta-Link sehen. 00:15:37.160 --> 00:15:38.340 So wissen Sie, dass Sie auf dem Laufenden sind. 00:15:38.620 --> 00:15:40.240 Überlegen Sie, was Sie dadurch im Laufe der Zeit sparen. 00:15:40.480 --> 00:15:41.260 Mein Denkmal darüber nach?