Latest / M365.FM – podcast o Microsoft 365, Copilot i AI po polsku / Webhooki Microsoft Graph w prostych słowach: powiadomienia w czasie rzeczywistym zamiast ciągłego pollingu (Dubbing AI)

Transcript

Webhooki Microsoft Graph w prostych słowach: powiadomienia w czasie rzeczywistym zamiast ciągłego pollingu (Dubbing AI) · M365.FM – podcast o Microsoft 365, Copilot i AI po polsku

• 0:00
  Gotowi na 10 dni Microsoft 365, Copilota, iAzure oraz ludzi kształtujących przyszłość pracy?
• 0:08
  W styczniu M365.com powraca i będzie jeszcze większy.
• 0:12
  Dołącz do nas, by wziąć udział w sesjach na żywo, praktycznych demonstracjach i zdobyć wiedzę od MVP oraz ekspertów z całego świata.
• 0:18
  Żadnych ogólnych slajdów, żadnych niekończących się modnych haseł.
• 0:22
  Stawiamy czoła prawdziwym wyzwaniom Copilot Studio, agenci, iFabrik, bezpieczeństwo, ład korporacyjny i automatyzacja.
• 0:29
  Niezależnie od tego, czy jesteś informatykiem, programistą czy liderem biznesowym, przygotowaliśmy sesję dla Ciebie.
• 0:35
  Przez 10 pełnych dni możesz zgłębiać różne technologie i łączyć się z globalną społecznością.
• 0:40
  Oglądaj na żywo i zabierz praktyczne wnioski do swojej organizacji.
• 0:44
  Styczeń 2027 roku, 10 dni, jedna społeczność Microsoft. Rejestracja jest już otwarta.
• 0:51
  Wejdź na m365.com.net i zapewnij sobie miejsce już dziś.
• 0:56
  To m365.com.net.
• 0:59
  Dołącz teraz na m365.com.net i widzimy się na żywo w styczniu.
• 1:04
  Witajcie wszyscy w kolejnym odcinku pigułek wiedzy o Microsoft tutaj na M365FM.
• 1:09
  Nazywam się Milko Peters i będę Waszym gospodarzem.
• 1:12
  Dzisiejszy temat to coś, o czym słyszał prawie każdy pracujący z Microsoft 365, ale niewielu potrafi jasno wyjaśnić.
• 1:17
  Czym dokładnie są webhoki grafa?
• 1:19
  Dlaczego warto się nimi zainteresować zamiast robić wszystko po staremu?
• 1:22
  Wyobraź sobie, że czekasz na ważny list.
• 1:23
  Podchodzisz do skrzynki pocztowej.
• 1:25
  Jest pusta.
• 1:25
  Wracasz.
• 1:26
  10 minut później sprawdzasz ponownie.
• 1:28
  Nadal nic.
• 1:28
  Robisz tak przez cały dzień, marnując czas i energię.
• 1:30
  To jest właśnie odpytywanie.
• 1:31
  Teraz wyobraź sobie inny świat.
• 1:33
  Listonosz dzwoni do Twoich drzwi w momencie, gdy list dociera.
• 1:35
  Nie musisz sprawdzać.
• 1:36
  Czekasz na dzwonek.
• 1:37
  To jest właśnie webhook.
• 1:39
  Pod koniec tego odcinka zrozumiesz, czym są webhoki grafa, dlaczego zastępują ciągłe sprawdzanie i jak to wszystko działa w praktyce.
• 1:45
  Problem odpytywania.
• 1:46
  Rozbijmy to na części.
• 1:47
  Aby zrozumieć znaczenie webhooków, musisz zrozumieć, dlaczego odpytywanie jest szkodliwe.
• 1:51
  Oto jak działa większość dzisiejszych aplikacji.
• 1:53
  Twoja aplikacja potrzebuje odpowiedzi.
• 1:55
  Pyta Microsoft Graf.
• 1:56
  Hej, są nowi użytkownicy?
• 1:57
  Graf odpowiada.
• 1:58
  Nie.
• 1:59
  Więc aplikacja czeka chwilę, a potem pyta ponownie.
• 2:01
  A teraz są nowi użytkownicy?
• 2:02
  Nadal nie.
• 2:03
  W kółko.
• 2:03
  Ten proces to właśnie odpytywanie.
• 2:05
  Pomyśl o tym, jak o ciągłym dzwonieniu do przyjaciela z pytaniem, czy ma jakieś nowiny.
• 2:08
  Dzwonisz, odbiera.
• 2:09
  Sprawdzasz.
• 2:10
  On mówi nie.
• 2:10
  Rozłączasz się.
• 2:11
  Potem dzwonisz ponownie 5 minut później i znowu.
• 2:13
  Marnujesz jego czas i swój własny.
• 2:15
  Prawdopodobnie zaczynasz go irytować.
• 2:17
  Teraz wyobraź sobie tysiące aplikacji robiących to samo z Microsoft Graf w tym samym czasie.
• 2:20
  Każda aplikacja odpytująca co kilka minut, zadająca te same pytania, otrzymująca te same odpowiedzi, to generuje spory hałas.
• 2:26
  Microsoft ma określenie na zbyt agresywne odpytywanie, throttling, albo jak nazywają to niektórzy programiści, więzienie Graf.
• 2:31
  Kiedy wysyłasz za dużo żądań, Microsoft mówi, dobrze, na razie kończysz.
• 2:35
  Ograniczają liczbę wywołań, które może wykonać Twoja aplikacja.
• 2:37
  Gdy zostaniesz ograniczony, wszystko zwalnia.
• 2:39
  Prawidłowe żądania zaczynają się piętrzyć.
• 2:40
  Twoja aplikacja przestaje działać poprawnie.
• 2:42
  Nie masz pojęcia, kiedy zostaniesz wypuszczony.
• 2:44
  O jakiej liczbie żądań mówimy?
• 2:45
  Załóżmy, że Twoja aplikacja sprawdza zmiany użytkowników co 5 minut.
• 2:48
  To daje 12 żądań na godzinę.
• 2:50
  W ciągu całego dnia to 288 żądań, a to tylko dla jednego zasobu.
• 2:54
  Jeśli sprawdzasz też grupy, pliki, wiadomości i wydarzenia w kalendarzu, uzbierasz tysiące niepotrzebnych żądań dziennie.
• 3:00
  Większość z nich nie zwraca nic, zero zmian, ale mimo to wykonałeś wywołanie.
• 3:03
  I w tym rzecz, nawet jeśli sprawdzasz co 5 minut, nadal nie otrzymujesz aktualizacji w czasie rzeczywistym.
• 3:08
  Zmiana może nastąpić minutę po Twoim ostatnim odpytaniu.
• 3:11
  Nie dowiesz się o niej przez kolejne 4 minuty.
• 3:13
  Marnujesz zasoby i wciąż przegapiasz odpowiedni moment.
• 3:16
  Teraz zestaw to z podejściem sterowanym zdarzeniami.
• 3:18
  Zamiast wywoływać Microsoft Graph co kilka minut, czekasz, aż to Microsoft Graph zadzwoni do Ciebie.
• 3:21
  Konfigurujesz odbiornik.
• 3:23
  Gdy coś się zmieni, Graph wysyła Ci powiadomienie.
• 3:25
  Nie wybierasz numeru.
• 3:26
  Odbierasz, gdy telefon zadzwoni.
• 3:28
  Czym są WebHooki?
• 3:29
  Czym więc dokładnie jest WebHook?
• 3:31
  Oto najprostsza definicja.
• 3:32
  WebHook to żądanie HTTP wysyłane automatycznie, gdy coś się wydarzy.
• 3:36
  Nie prosisz o nie, serwer po prostu wypycha je do Ciebie.
• 3:39
  Pomyśl o tym, jak o dzwonku do drzwi.
• 3:41
  Nie stoisz przed drzwiami, sprawdzając co kilka minut.
• 3:43
  Instalujesz dzwonek.
• 3:44
  Gdy ktoś przyjdzie, dzwoni.
• 3:46
  Słyszysz dzwonek i otwierasz.
• 3:47
  Dzwonek czuwa za Ciebie.
• 3:49
  WebHooki nazywa się czasem odwróconymi API.
• 3:51
  W przypadku zwykłego API Twoja aplikacja wysyła żądanie, a serwer odpowiada.
• 3:55
  Twoja aplikacja ma kontrolę.
• 3:56
  W przypadku WebHooka to serwer wysyła żądanie do Twojej aplikacji.
• 3:59
  Serwer ma kontrolę, ale wypycha dane zamiast czekać, aż o nie poprosisz.
• 4:02
  Microsoft Graph również korzysta z WebHooków, ale Microsoft nazywa je powiadomieniami o zmianach.
• 4:07
  To to samo, tylko inna nazwa.
• 4:09
  Gdy coś zmienia się w Microsoft 365, Graph wysyła żądanie HTTP POST na podany przez Ciebie adres URL.
• 4:15
  To żądanie POST zawiera informacje o tym, co się zmieniło.
• 4:17
  Jest wiele rzeczy, o których możesz otrzymywać powiadomienia.
• 4:20
  W Twoim dzierżawcy tworzony jest nowy użytkownik, aktualizowany plik w SharePoint, wysyłana wiadomość w Teams, zmienia się wydarzenie w kalendarzu lub grupa zyskuje nowego członka.
• 4:28
  Każde z tych zdarzeń może wywołać powiadomienie.
• 4:30
  Oto rzeczywisty przykład.
• 4:32
  Załóżmy, że prowadzisz firmę z systemem rejestracji czasu pracy.
• 4:34
  Gdy zatrudniasz nowego pracownika, chcesz automatycznie utworzyć mu konto.
• 4:37
  Bez WebHooków musiałbyś odpytywać punkt końcowy użytkowników co kilka minut w poszukiwaniu nowych osób.
• 4:41
  Dzięki WebHookom subskrybujesz zdarzenia tworzenia użytkownika.
• 4:44
  Gdy ktoś dołącza, Graf wysyła Twojej aplikacji powiadomienie.
• 4:47
  Twoja aplikacja je odbiera, weryfikuje i tworzy konto w ciągu kilku sekund.
• 4:51
  Bez odpytywania, bez marnowania zapytań.
• 4:53
  Inny przykład.
• 4:54
  Masz bibliotekę dokumentów SharePoint, do której przesyłane są rachunki.
• 4:57
  Bez WebHooków musiałbyś stale odpytywać bibliotekę.
• 5:00
  Z WebHookami Graf informuje Cię w momencie dodania pliku.
• 5:03
  Twoja aplikacja pobiera go, sprawdza czy to rachunek i przetwarza automatycznie.
• 5:06
  Na tym polega potęga WebHooków.
• 5:08
  Zamiast ciągłego pytania aplikacji, czy jest coś nowego, pozwalasz systemowi poinformować Cię, gdy coś się wydarzy.
• 5:13
  Jest to bardziej wydajne, niezawodne i znacznie szybsze.
• 5:16
  Jak działają WebHooki w Microsoft Graph?
• 5:18
  Teraz już wiesz, czym są WebHooki i dlaczego odpytywanie jest problematyczne.
• 5:21
  Przyjrzyjmy się, jak faktycznie działają WebHooki w Microsoft Graph, bo proces jest prostszy niż myślisz.
• 5:26
  Sprowadza się do trzech rzeczy.
• 5:27
  Subskrypcji, powiadomienia i Twojego punktu końcowego.
• 5:30
  Najpierw tworzysz subskrypcję.
• 5:32
  Mówisz Microsoft Graph, hej, chcę wiedzieć, kiedy ten konkretny element się zmieni.
• 5:36
  Podajesz Graphowi szczegóły dotyczące tego, co obserwować i gdzie wysyłać powiadomienia.
• 5:39
  Pomyśl o tym, jak o zapisaniu się na alerty.
• 5:41
  Mówisz systemowi, co Cię interesuje i podajesz swoje dane kontaktowe.
• 5:44
  Po drugie, Microsoft Graph obserwuje ten zasób.
• 5:46
  Monitoruje wszelkie zmiany.
• 5:48
  Gdy coś się dzieje, jak utworzenie użytkownika, aktualizacja pliku, czy nadejście wiadomości, Graph to zauważa.
• 5:52
  Po trzecie, Graph wysyła powiadomienie.
• 5:54
  Wysyła żądanie HTTP POST na podany przez Ciebie adres URL.
• 5:57
  To żądanie POST zawiera informacje o tym, co uległo zmianie.
• 5:59
  Twój punkt końcowy je odbiera, a Twoja aplikacja je przetwarza.
• 6:03
  Zatem ogólny schemat jest prosty.
• 6:04
  Subskrybujesz, Graph obserwuje, Graph wysyła POST, gdy coś się zmieni.
• 6:08
  Przyjrzyjmy się nieco dokładniej tym trzem elementom składowym.
• 6:10
  Subskrypcja to Twoja prośba o otrzymywanie alertów.
• 6:13
  To tak, jakbyś powiedział, chcę wiedzieć, kiedy nowy użytkownik zostanie dodany do mojego dzierżawcy.
• 6:17
  Wysyłasz to żądanie do Microsoft Graph, a Graph je zapisuje.
• 6:19
  Od tego momentu Graph obserwuje zasób w Twoim imieniu.
• 6:22
  Powiadomienie to sam alert, czyli żądanie HTTP POST, które Graph wysyła do Twojego punktu końcowego.
• 6:27
  Treść żądania POST zawiera szczegóły zmiany, takie jak zmieniony zasób, typ zmiany oraz czas jej wystąpienia.
• 6:32
  Twój punkt końcowy to drzwi, które pozostawiasz otwarte.
• 6:34
  To adres URL na Twoim serwerze, skonfigurowany do odbierania tych żądań POST.
• 6:37
  Musi on po prostu nasłuchiwać i szybko odpowiadać.
• 6:39
  To wszystko.
• 6:40
  Po stronie odbiorczej nie jest wymagana złożona logika.
• 6:42
  Wystarczy przechwycić powiadomienie, potwierdzić je i przetworzyć.
• 6:45
  Porównajmy to teraz z odpytywaniem polingiem.
• 6:47
  Przy odpytywaniu wysyłasz setki żądań GET, z których każdy pyta, czy jest coś nowego?
• 6:50
  Przez większość czasu odpowiedź brzmi nie.
• 6:52
  W przypadku webhuków wystarczy jeden POST, czyli powiadomienie.
• 6:55
  To wszystko.
• 6:56
  Jedna wiadomość zamiast setek.
• 6:57
  Różnica w wydajności jest ogromna, a Twój punkt końcowy nie musi być skomplikowany.
• 7:01
  Musi być po prostu publicznie dostępny, obsługiwać HTTPS i szybko odpowiadać.
• 7:05
  Za chwilę powiemy, co oznacza szybko.
• 7:08
  Ale główna idea jest prosta.
• 7:09
  Twój punkt końcowy nasłuchuje, gra w dzwoni, Ty odpowiadasz i gotowe.
• 7:13
  Tworzenie subskrypcji.
• 7:15
  Jak więc faktycznie to skonfigurować?
• 7:17
  Przejdźmy krok po kroku przez proces tworzenia subskrypcji.
• 7:20
  Zaczynasz od wysłania żądania HTTP POST na określony adres URL w Microsoft Graph.
• 7:24
  Tym adresem URL jest httpsgraf.microsoft.com ukośnik v1.0 ukośnik subscriptions.
• 7:29
  Wysyłasz żądanie bezpośrednio do punktu końcowego subskrypcji.
• 7:32
  Wewnątrz treści żądania umieszczasz szczegóły tego, co chcesz subskrybować.
• 7:35
  Musisz podać cztery kluczowe pola.
• 7:37
  Pierwszym jest adres URL powiadomienia Notification URL.
• 7:39
  To adres URL twojego punktu końcowego, czyli miejsce, do którego Microsoft Graph będzie wysyłać powiadomienia.
• 7:43
  Musi on obsługiwać HTTPS i być publicznie dostępny, ponieważ graph musi mieć możliwość połączenia z nim przez internet.
• 7:47
  Drugim jest zasób Resource.
• 7:49
  Mówi on usłudze graph, co chcesz obserwować.
• 7:51
  Określasz ścieżkę zasobu Microsoft Graph.
• 7:53
  Na przykład Users, jeśli chcesz obserwować zmiany użytkowników lub Mail Folders, Inbox, Messages, jeśli chcesz monitorować nowe e-maile w skrzynce odbiorczej.
• 8:00
  Zasób informuje graph dokładnie o tym, co cię interesuje.
• 8:02
  Trzecim jest typ zmiany Change Type.
• 8:04
  Informuje on graph, o jakich rodzajach zmian chcesz otrzymywać powiadomienia.
• 8:07
  Możesz określić utworzenie Created, aktualizację Updated, usunięcie Deleted lub dowolną ich kombinację.
• 8:11
  Jeśli interesuje Cię tylko tworzenie nowych użytkowników, ustawiasz typ zmiany na Created.
• 8:14
  Jeśli interesują Cię również aktualizacje, ustawiasz Created Updated.
• 8:17
  Czwartym jest data i godzina wygaśnięcia Expiration Date Time.
• 8:20
  Jest to moment wygaśnięcia subskrypcji, ponieważ subskrypcje nie trwają wiecznie.
• 8:23
  Ustawiasz datę i godzinę, po której graph przestanie wysyłać powiadomienia.
• 8:27
  Maksymalny czas trwania zależy od zasobu, który obserwujesz.
• 8:29
  Dla użytkowników i grup limit wynosi około 3 dni.
• 8:32
  Dla elementów dysków SharePoint lub OnDrive może to być nawet 30 dni.
• 8:36
  Musisz sprawdzić dokumentację dla każdego typu zasobu.
• 8:38
  Warto też wspomnieć o opcjonalnym polu Stan Klienta.
• 8:41
  To tajny ciąg znaków, który sam tworzysz.
• 8:43
  Może to być cokolwiek zechcesz.
• 8:45
  Losowy ciąg znaków, guj, cokolwiek wybierzesz.
• 8:47
  Microsoft Graph dołącza tę wartość do każdego powiadomienia wysyłanego do Twojego punktu końcowego,
• 8:51
  a Ty używasz jej, by zweryfikować, czy powiadomienie faktycznie pochodzi z Twojej subskrypcji.
• 8:55
  Jeśli ktoś spróbuje wysłać fałszywe powiadomienia do Twojego punktu końcowego,
• 8:58
  stan klienta się nie zgodzi i możesz je natychmiast odrzucić.
• 9:01
  To prosty środek bezpieczeństwa, ale bardzo ważny.
• 9:03
  Tworzenie subskrypcji przypomina zapisanie się na dostawę gazety.
• 9:06
  Podajesz gazecie swój adres.
• 9:08
  To jest Twój adres URL powiadomień.
• 9:10
  Mówisz im, jakie sekcje Cię interesują, to Twój zasób i typ zmiany oraz jak długo ma trwać dostawa.
• 9:16
  To jest Twój czas wygaśnięcia.
• 9:17
  Gazeta zajmuje się resztą, ale jest pewien szczegół – subskrypcje wygasają.
• 9:21
  Nie możesz jej stworzyć i o niej zapomnieć.
• 9:23
  Gdy minie czas wygaśnięcia, Graph przestaje wysyłać powiadomienia, a Twoja subskrypcja przestaje istnieć.
• 9:29
  Jeśli chcesz nadal otrzymywać powiadomienia, musisz odnowić subskrypcję przed jej wygaśnięciem,
• 9:33
  wysyłając żądanie patch do punktu końcowego subskrypcji z nowym czasem wygaśnięcia.
• 9:36
  Zatem stworzenie subskrypcji to pierwszy krok, ale nie ostatni.
• 9:39
  Musisz zarządzać jej cyklem życia.
• 9:41
  Porozmawiamy o tym później.
• 9:43
  Uścisk dłoni walidacji.
• 9:44
  Zanim Twoja subskrypcja zacznie działać, jest krok, którego nie możesz pominąć.
• 9:47
  Microsoft Graph nie przyjmuje po prostu Twojej prośby o subskrypcję i nie zaczyna od razu wysyłać powiadomień.
• 9:52
  Najpierw musi potwierdzić, że Twój punkt końcowy jest prawdziwy i gotowy na ich odbiór.
• 9:55
  Oto jak to działa.
• 9:56
  Gdy wysyłasz żądanie post w celu utworzenia subskrypcji,
• 9:59
  Microsoft Graph natychmiast wysyła testowy post na Twój adres URL powiadomień.
• 10:02
  Ten testowy post zawiera parametr zapytania o nazwie token walidacji.
• 10:06
  To po prostu losowy ciąg znaków.
• 10:07
  Twój punkt końcowy musi pobrać ten token i odesłać go jako odpowiedź w formacie zwykłego tekstu,
• 10:11
  a musisz to zrobić w ciągu 10 sekund.
• 10:12
  Pomyśl o tym jak o kurierze dostarczającym przesyłkę.
• 10:15
  Puka do Twoich drzwi i pyta, czy to właściwy adres?
• 10:17
  Może Pan, Pani potwierdzić?
• 10:18
  Musisz potwierdzić odbiór podpisem.
• 10:20
  Jeśli tego nie zrobisz, kurier odejdzie.
• 10:21
  Kurier nie zostawi przesyłki, po prostu odchodzi.
• 10:24
  Dokładnie tak to wygląda w tym przypadku.
• 10:26
  Microsoft Graph mówi, mam zamiar wysłać Ci ważne powiadomienia.
• 10:29
  Udowodnij, że jesteś właściwą osobą pod właściwym adresem.
• 10:32
  Twój punkt końcowy odpowiada odsyłając token walidacji,
• 10:36
  który mówi Graph, tak jestem tutaj.
• 10:38
  Słucham, wyślij mi powiadomienia.
• 10:40
  W tym miejscu wielu programistów popełnia błąd.
• 10:43
  Token walidacji musi zostać zwrócony jako zwykły tekst.
• 10:45
  Nie JSON, nie HTML, lecz zwykły tekst.
• 10:48
  A odpowiedź musi mieć nagłówek typu zawartości ustawiony na text plain.
• 10:51
  Jeśli odeślesz go w formacie JSON lub w jakikolwiek sposób zakodowany,
• 10:54
  walidacja się nie powiedzie.
• 10:55
  Twoja subskrypcja nie zostanie utworzona.
• 10:57
  Microsoft Graph zwróci błąd, a Ty będziesz się zastanawiać, co poszło nie tak.
• 11:00
  Jest jeszcze jeden szczegół techniczny, który warto znać.
• 11:02
  Usługa walidacji Microsoft Graph nie obsługuje niezawodnie TLS 1.3.
• 11:06
  Negocjuje ona protokół TLS 1.2.
• 11:08
  Jeśli więc Twój punkt końcowy akceptuje tylko połączenia TLS 1.3,
• 11:11
  uścisk dłoni walidacji nie uda się, zanim kod aplikacji w ogóle zadziała.
• 11:14
  Musisz upewnić się, że Twój punkt końcowy obsługuje TLS 1.2,
• 11:18
  przynajmniej na potrzeby walidacji.
• 11:19
  Potem możesz wymusić dowolną wersję TLS dla właściwych powiadomień.
• 11:23
  Dobra wiadomość jest taka, że ten uścisk dłoni walidacji ma miejsce tylko raz na subskrypcję.
• 11:27
  Nie jest to coś, co punkt końcowy musi obsługiwać przy każdym powiadomieniu,
• 11:30
  tylko za pierwszym razem.
• 11:31
  Gdy Graph potwierdzi, że Twój punkt końcowy jest prawdziwy,
• 11:34
  ufa mu przez cały okres subskrypcji.
• 11:36
  Wystarczy więc, że zrobisz to dobrze tylko raz.
• 11:38
  Obsługa powiadomień i bezpieczeństwo.
• 11:40
  Gdy uścisk dłoni walidacji przebiegnie pomyślnie,
• 11:43
  a subskrypcja stanie się aktywna,
• 11:44
  Microsoft Graph zacznie wysyłać powiadomienia.
• 11:46
  Jak one właściwie wyglądają w praktyce?
• 11:48
  Gdy coś się zmieni,
• 11:49
  Graph wysyła żądanie HTTP POST do Twojego punktu końcowego z obiektem JSON w treści.
• 11:54
  Obiekt ten zawiera zasób, który uległ zmianie,
• 11:56
  typ zmiany, czyli utworzenie, aktualizację lub usunięcie oraz znacznik czasu.
• 12:00
  Zawiera również wartość stanu klienta,
• 12:02
  którą ustawiłeś podczas tworzenia subskrypcji.
• 12:04
  To Twój tajny ciąg znaków,
• 12:05
  sposób na upewnienie się, że wiadomość jest prawdziwa.
• 12:07
  Oto pierwsza rzecz, którą należy zrobić po otrzymaniu powiadomienia.
• 12:10
  Zweryfikuj ten stan klienta.
• 12:11
  Porównaj wartość w powiadomieniu z sekretem,
• 12:13
  który zapisałeś podczas tworzenia subskrypcji.
• 12:15
  Jeśli się nie zgadzają, odrzuć ją natychmiast,
• 12:17
  bo może to być fałszywka, próba oszukania systemu
• 12:20
  i przetworzenia błędnych danych.
• 12:21
  Ma to znaczenie, ponieważ Twój punkt końcowy znajduje się w publicznym internecie.
• 12:24
  Każdy, kto zna Twój adres URL,
• 12:26
  może wysłać do niego żądanie post.
• 12:27
  Bez walidacji stanu klienta nie byłbyś w stanie
• 12:29
  odróżnić prawdziwego powiadomienia Microsoft Graph
• 12:32
  od fałszywego.
• 12:33
  To prosta kontrola, ale jest pierwszą linią obrony.
• 12:35
  Gdy potwierdzisz, że powiadomienie jest autentyczne,
• 12:38
  musisz zareagować szybko.
• 12:39
  Microsoft Graph oczekuje odpowiedzi HTTP
• 12:41
  z poziomu 200 w ciągu 3 sekund.
• 12:43
  Jeśli zajmie Ci to więcej czasu, Graph to zauważy.
• 12:45
  A jeśli zdarza się to zbyt często, Graph zacznie traktować Cię inaczej.
• 12:48
  Oto jak działa ograniczanie przepustowości.
• 12:50
  Jeśli ponad 10% Twoich odpowiedzi
• 12:52
  przekracza 3-sekundowe okno w dowolnym 10-minutowym odstępie,
• 12:54
  Microsoft Graph oznaczy Twój punkt końcowy jako wolny.
• 12:57
  Gdy tak się stanie, nowe powiadomienia
• 12:58
  będą opóźnione o 10 minut.
• 13:00
  Nadal będą docierać, ale stracisz dostarczanie
• 13:02
  w czasie rzeczywistym.
• 13:03
  A jeśli sytuacja się pogorszy i ponad 15% Twoich odpowiedzi
• 13:06
  przekroczy 10 sekund, Graph oznaczy Twój punkt końcowy
• 13:08
  jako porzucony.
• 13:09
  W tym stanie powiadomienia są całkowicie odrzucane przez 10 minut.
• 13:12
  Oto ta przerażająca część.
• 13:13
  Odrzuconych powiadomień nie da się odzyskać.
• 13:15
  Przepadają bezpowrotnie i nigdy ich nie odzyskasz.
• 13:17
  Pomyśl o tym jak o zajętej linii telefonicznej.
• 13:19
  Jeśli nie odbierzesz szybko, dzwoniący spróbuje ponownie później.
• 13:22
  Ale jeśli nigdy nie odbierzesz, w końcu dzwoniący się podda.
• 13:24
  Microsoft Graph jest dzwoniącym,
• 13:26
  a Twój punkt końcowy to telefon.
• 13:27
  Odbieraj szybko, inaczej ryzykujesz utratę wiadomości.
• 13:30
  Jakie są więc najlepsze praktyki w tej kwestii?
• 13:32
  Potwierdzaj natychmiast i przetwarzaj asynchronicznie.
• 13:34
  Twój punkt końcowy powinien zweryfikować stan klienta,
• 13:37
  zaakceptować powiadomienie i zwrócić odpowiedź 200 lub 202
• 13:40
  tak szybko jak to możliwe.
• 13:41
  Następnie umieść powiadomienie w kolejce do przetwarzania w tle.
• 13:44
  Może to być kolejka Azure, Service Bus,
• 13:46
  a nawet prosta tabela w bazie danych.
• 13:48
  Chodzi o to, aby szybko wyjść z cyklu odpowiedzi
• 13:50
  i pozwolić pracownikom w tle zająć się ciężką pracą.
• 13:52
  I jeszcze jedno przypomnienie o bezpieczeństwie.
• 13:54
  Twój punkt końcowy musi być HTTPS bez wyjątków.
• 13:56
  Microsoft Graph nie wyśle powiadomień do punktu końcowego HTTP.
• 13:59
  Twój punkt końcowy musi być również publicznie dostępny.
• 14:02
  Jeśli znajduje się za Firewallem lub VPN,
• 14:03
  Graph nie będzie mógł się z nim połączyć.
• 14:05
  Do celów deweloperskich możesz użyć narzędzi takich jak Grog,
• 14:07
  aby stworzyć publiczny tunel do lokalnej maszyny.
• 14:09
  Jednak na produkcji Twój punkt końcowy
• 14:11
  musi znajdować się tam, gdzie Graph go znajdzie.
• 14:14
  Utrzymywanie cyklu życia powiadomień.
• 14:15
  Masz więc skonfigurowaną subskrypcję,
• 14:17
  powiadomienia płyną i wszystko wygląda dobrze.
• 14:20
  Ale oto coś, co zaskakuje wiele osób.
• 14:22
  Twoja subskrypcja ma datę wygaśnięcia.
• 14:24
  Nie trwa ona wiecznie.
• 14:25
  W zależności od monitorowanego zasobu
• 14:27
  maksymalny czas subskrypcji wynosi zazwyczaj od 3 do 7 dni.
• 14:30
  Dla niektórych zasobów, takich jak elementy dysków SharePoint,
• 14:32
  można uzyskać do 30 dni.
• 14:33
  Chodzi jednak o to, że nie jest to stan permanentny.
• 14:35
  Nie możesz utworzyć subskrypcji i o niej zapomnieć.
• 14:38
  Pomyśl o tym, jak o subskrypcji czasopisma.
• 14:40
  Zapisujesz się, zaczynasz otrzymywać numery
• 14:41
  i wszystko jest wspaniale.
• 14:43
  Ale jeśli nie odnowisz subskrypcji,
• 14:44
  przed jej wygaśnięciem czasopisma przestaną przychodzić.
• 14:46
  Tutaj jest dokładnie tak samo.
• 14:47
  Jeśli Twoja subskrypcja wygaśnie,
• 14:48
  Microsoft Graph przestanie wysyłać powiadomienia.
• 14:50
  Możesz nawet nie zdać sobie z tego sprawy,
• 14:51
  dopóki nie zaczniesz się zastanawiać,
• 14:52
  dlaczego nic się nie dzieje.
• 14:53
  Dlatego potrzebujesz strategii odnawiania.
• 14:55
  Sposób odnawiania jest prosty.
• 14:56
  Wyślij żądanie typu patch do punktu końcowego subskrypcji,
• 14:59
  używając jej identyfikatora
• 15:00
  i zaktualizuj datę wygaśnięcia na nową, przyszłą datę.
• 15:02
  To przedłuża ważność subskrypcji.
• 15:04
  Możesz to robić dowolną liczbę razy,
• 15:06
  pod warunkiem, że zrobisz to przed upływem
• 15:07
  bieżącego terminu ważności.
• 15:09
  Microsoft Graph pomaga w tym za pomocą tak zwanej
• 15:11
  powiadomień o cyklu życia.
• 15:13
  Podczas tworzenia subskrypcji
• 15:14
  możesz podać osobny adres URL,
• 15:16
  zwany adresem URL powiadomień o cyklu życia.
• 15:18
  Microsoft Graph wysyła pod ten adres alerty,
• 15:20
  gdy wystąpią określone zdarzenia.
• 15:22
  Na przykład, gdy subskrypcja wkrótce wygaśnie,
• 15:24
  token dostępu kończy ważność
• 15:25
  lub zmieniają się uprawnienia Twojej aplikacji.
• 15:27
  Te powiadomienia o cyklu życia to sygnał ostrzegawczy.
• 15:30
  Nie musisz zgadywać, kiedy Twoja subskrypcja wygaśnie.
• 15:32
  Graph informuje Cię,
• 15:33
  hej, Twoja subskrypcja wygasa za kilka godzin.
• 15:36
  Warto ją odnowić.
• 15:37
  To jak otrzymanie przypomnienia od wydawcy czasopisma,
• 15:39
  że subskrypcja dobiega końca.
• 15:41
  Bardzo przydatne, jeśli zwracasz na to uwagę.
• 15:43
  Ale co się stanie, jeśli mimo wszystko coś pójdzie nie tak?
• 15:45
  Może Twój punkt końcowy przez chwilę nie działa
• 15:47
  lub powiadomienia zostały utracone,
• 15:48
  bo reagowałeś zbyt wolno.
• 15:49
  Co wtedy?
• 15:50
  Tutaj z pomocą przychodzi Delta Query
• 15:52
  osobna funkcja Microsoft Graph,
• 15:53
  która pozwala zapytać,
• 15:54
  co zmieniło się od ostatniego sprawdzenia.
• 15:56
  Zwraca ona tylko zmiany, nic poza tym.
• 15:59
  Oto jak to działa.
• 16:00
  Gdy uruchamiasz Delta Query dla zasobu po raz pierwszy,
• 16:02
  powiedzmy dla użytkowników,
• 16:03
  Graph zwraca wszystkich użytkowników w Twoim dzierżawcy.
• 16:05
  Ale zwraca też coś dodatkowego,
• 16:06
  specjalny link zwany Delta Link.
• 16:08
  Zapisujesz ten link.
• 16:09
  Przy następnym uruchomieniu tego samego zapytania
• 16:10
  używasz właśnie tego Delta Linku.
• 16:12
  I zamiast ponownie pobierać wszystkich użytkowników,
• 16:14
  otrzymujesz tylko tych,
• 16:14
  którzy zmienili się od czasu ostatniego żądania.
• 16:16
  Nowi użytkownicy,
• 16:17
  zaktualizowani użytkownicy,
• 16:18
  usunięci użytkownicy.
• 16:19
  To wszystko.
• 16:20
  Potraktuj to jak czytanie listy nowości
• 16:22
  zamiast czytania całej encyklopedii za każdym razem.
• 16:24
  Znacznie szybciej, znacznie mniej danych.
• 16:26
  Oto inteligentny wzorzec postępowania.
• 16:28
  Połącz webhoki z Delta Query.
• 16:29
  Używaj webhoków do otrzymywania informacji o zmianach,
• 16:31
  a następnie Delta Query,
• 16:32
  aby sprawdzić, co dokładnie się zmieniło.
• 16:34
  Wyjaśnię, dlaczego to ważne.
• 16:35
  Webhoki są szybkie, ale nie są idealne.
• 16:37
  Powiadomienia mogą zaginąć,
• 16:38
  subskrypcje mogą wygasnąć,
• 16:39
  a twój punkt końcowy może przestać działać.
• 16:41
  Ale Delta Query jest niezawodne.
• 16:42
  Możesz go uruchomić w dowolnym momencie,
• 16:44
  a otrzymasz pełną listę zmian od ostatniego sprawdzenia.
• 16:46
  Więc nawet jeśli przegapisz powiadomienie,
• 16:48
  możesz wszystko nadrobić.
• 16:49
  Oto typowy przebieg procesu.
• 16:51
  Skonfiguruj subskrypcję webhoka dla zmian użytkowników.
• 16:53
  Uruchom początkowe zapytanie Delta,
• 16:55
  aby uzyskać stan bazowy i zapisać link Delta.
• 16:57
  Gdy nadejdzie webhuk informujący o zmianie użytkownika,
• 16:59
  uruchom zapytanie Delta za pomocą zapisanego linku.
• 17:01
  To pozwoli Ci uzyskać dokładną informację o zmianie.
• 17:03
  Przetwórz ją, a następnie zapisz nowy link Delta z tej odpowiedzi.
• 17:06
  Przy następnym webhoku powtórz cały proces.
• 17:08
  A jeśli kiedykolwiek przegapisz powiadomienie lub subskrypcja wygaśnie,
• 17:11
  po prostu uruchom zapytanie Delta ponownie.
• 17:13
  Otrzymasz wszystko, co Cię ominęło.
• 17:15
  To Twoja siatka bezpieczeństwa.
• 17:16
  Webhoki zapewniają szybkość, a zapytania Delta niezawodność.
• 17:20
  Razem tworzą potężne połączenie.
• 17:21
  Przykład z życia wzięty i kolejne kroki.
• 17:24
  Wyobraź sobie, że jutro do firmy dołącza nowy pracownik.
• 17:26
  Ktoś z HR tworzy jego konto w Microsoft Entra ID
• 17:29
  i ta jedna czynność wywołuje reakcję łańcuchową.
• 17:32
  Jeśli masz skonfigurowaną subskrypcję webhoka dla zmian użytkowników Microsoft Graph,
• 17:36
  zauważy to natychmiast i wyślę żądanie post do Twojego punktu końcowego.
• 17:39
  Oto co dzieje się dalej.
• 17:40
  Twój punkt końcowy otrzymuje powiadomienie,
• 17:42
  sprawdza stan klienta i jeśli zgadza się z Twoim kluczem,
• 17:44
  wiesz, że jest ono autentyczne.
• 17:46
  Zwracasz odpowiedź 202 Accepted w ciągu 3 sekund,
• 17:49
  potwierdzając otrzymanie powiadomienia,
• 17:51
  a następnie przejmuje je proces w tle.
• 17:52
  Proces widzi, że użytkownik został utworzony,
• 17:54
  ale powiadomienie nie zawiera wszystkich szczegółów,
• 17:56
  więc uruchamia zapytanie Delta przy użyciu zapisanego linku.
• 17:59
  Zwraca to pełne dane nowego użytkownika,
• 18:01
  imię i nazwisko, e-mail, dział, stanowisko,
• 18:03
  przełożonego, wszystko, czego potrzebujesz.
• 18:05
  Teraz proces pobiera te informacje
• 18:06
  i tworzy konto dla nowego pracownika
• 18:08
  w Twoim zewnętrznym systemie rejestracji czasu pracy.
• 18:10
  Wysyła e-mail powitalny,
• 18:12
  dodaje go do odpowiednich list dystrybucyjnych.
• 18:14
  Wszystko to dzieje się w ciągu sekund
• 18:16
  od utworzenia konta przez HR w Entra ID.
• 18:18
  Bez odpytywania, bez ręcznych kroków,
• 18:20
  bez opóźnień.
• 18:21
  Pomyśl o alternatywie.
• 18:23
  Bez webhooków musiałbyś odpytywać punkt końcowy użytkowników
• 18:25
  co kilka minut, wykonując setki zapytań dziennie,
• 18:27
  a nawet wtedy nowy użytkownik mógłby pojawić się z opóźnieniem.
• 18:30
  Dzięki webhookom dzieje się to natychmiast.
• 18:32
  Jedno powiadomienie, jedno zapytanie Delta, gotowe.
• 18:34
  To jest prawdziwa wartość.
• 18:35
  Twój system staje się szybszy, wydajniejszy
• 18:37
  i mniej narażony na limity przepustowości.
• 18:39
  Zamiast ciągle pytać graf o aktualizację,
• 18:41
  pozwalasz, aby graf informował Cię, gdy coś się wydarzy.
• 18:43
  To fundamentalna zmiana w sposobie budowania integracji.
• 18:45
  Oto co chcę, żebyś wypróbował.
• 18:47
  Pomyśl o jednym procesie, który obecnie odpytujesz.
• 18:49
  Może sprawdzasz nowe wiadomości w skrzynce współdzielonej.
• 18:52
  Może śledzisz zmiany plików w bibliotece SharePoint.
• 18:55
  Może monitorujesz aktualizację użytkowników w systemie Hrabia.
• 18:57
  Czy webhook mógłby zastąpić to odpytywanie?
• 18:59
  W większości przypadków odpowiedź brzmi tak
• 19:01
  i nie musisz wszystkiego budować.