Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Вебхуки Microsoft Graph простими словами: сповіщення в реальному часі замість постійного опитування (ШІ-дубляж)

Transcript

Вебхуки Microsoft Graph простими словами: сповіщення в реальному часі замість постійного опитування (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, що формують майбутні роботи.
• 0:07
  Цього січня M365Con повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас на живі сесії, демонстрації реальних кейсів та практичні знання від MVP та експертів галузі з усього світу.
• 0:18
  Жодних шаблонних слайдів чи нескінченних модних слів.
• 0:21
  Ми розбираємо реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви IT-спеціаліст, розробник або бізнес-лідер, у нас є сесії саме для вас.
• 0:35
  За 10 повних днів ви зможете дослідити різні технології та налагодити зв'язки з глобальною спільнотою.
• 0:40
  Дивіться наживо та приносте практичні ідеї у свою організацію.
• 0:45
  Січень 2027 – 10 днів, одна спільнота Microsoft.
• 0:49
  Реєстрація вже відкрита.
• 0:51
  Переходьте на M365Con.net і забезпечте собі місце вже сьогодні.
• 0:56
  Це M365Con.net
• 0:59
  Долучайтеся на M365Con.net і побачимося наживо в січні.
• 1:04
  Всім привіт і ласкаво просимо до чергового епізоду Microsoft Knowledge Nuggets тут на M365FM.
• 1:10
  Я ваш ведучий Мілко Пітерс.
• 1:12
  Сьогоднішня тема – це те, про що чув майже кожен, хто працює з Microsoft 365, але мало хто може чітко пояснити.
• 1:17
  Що ж таке насправді Webhook і Graph?
• 1:19
  Чому вам варто звернути на них увагу замість того, щоб робити все по-старому?
• 1:21
  Проблема опитування.
• 1:46
  Давайте розберемося в цьому.
• 1:47
  Щоб зрозуміти, чому вебхоки важливі, потрібно зрозуміти, чому опитування шкодить.
• 1:51
  Ось як працює більшість застосунків сьогодні.
• 1:53
  Вашому застосунку потрібна відповідь.
• 1:55
  Він запитує Microsoft Graph «Гей, є нові користувачі?»
• 1:57
  Граф відповідає «Ні».
• 1:59
  Отже, ваш застосунок трохи чекає, а потім знову запитує «Є нові користувачі зараз?»
• 2:02
  Знову «Ні».
• 2:03
  Знову і знову цей процес і є опитуванням.
• 2:05
  Подумайте про це, як про постійні дзвінки другу, щоб дізнатися, чи є якісь новини.
• 2:08
  Ви набираєте, вони беруть слухавку, ви запитуєте, вони кажуть «Ні», викладайте слухавку.
• 2:11
  Потім ви дзвоните знову через п'ять хвилин і знову.
• 2:13
  Ви спалюєте їхній час і свій власний.
• 2:15
  Ви, мабуть, їх дратуєте.
• 2:17
  А тепер уявіть тисячі застосунків, які роблять це до Microsoft Graph одночасно.
• 2:20
  Кожен додаток опитує кожні кілька хвилин, ставлячи одні й ті самі питання, отримуючи ті самі відповіді.
• 2:24
  Це створює багато зайвого шуму.
• 2:26
  Microsoft має назву для надто агресивного опитування «Тротлінг» або, як кажуть деякі розробники, «В'язниця Граф».
• 2:31
  Коли ви надсилаєте за багато запитів, Microsoft каже «Гаразд, ви на деякий час відпочинете».
• 2:35
  Вони обмежують кількість викликів вашого додатка.
• 2:37
  Як тільки вас обмежили, все сповільнюється.
• 2:39
  Легітимні запити накопичуються.
• 2:40
  Ваш додаток перестає працювати належним чином.
• 2:42
  Ви гадки не маєте, коли вас випустять.
• 2:44
  Про яку кількість запитів йдеться?
• 2:45
  Припустімо, ваш додаток опитує сервери кожні 5 хвилин щодо змін користувачів.
• 2:48
  Це виходить 12 запитів на годину.
• 2:50
  За повну добу це 288 запитів, і це лише для одного ресурсу.
• 2:54
  Якщо ви також опитуєте групи, файли, повідомлення та події календаря,
• 2:57
  ви накопичуєте тисячі непотрібних запитів на день.
• 3:00
  Більшість з них нічого не повертають, жодних змін, але ви все одно зробили виклик.
• 3:03
  І ось у чому річ, навіть якщо ви опитуєте кожні 5 хвилин,
• 3:06
  ви все одно не отримуєте оновлень у реальному часі.
• 3:08
  Зміна може статися через одну хвилину після вашого останнього опитування.
• 3:11
  Ви не дізнаєтеся про це ще 4 хвилини.
• 3:13
  Ви марнуєте ресурси і все одно втрачаєте час.
• 3:15
  Тепер порівняйте це з подійно орієнтованим підходом.
• 3:18
  Замість того, щоб викликати Microsoft Graph кожні кілька хвилин,
• 3:20
  ви чекаєте, поки Microsoft Graph викличе вас.
• 3:21
  Ви налаштовуєте слухач.
• 3:22
  Коли щось змінюється, Graph надсилає вам сповіщення.
• 3:25
  Ви не телефонуєте самі.
• 3:26
  Ви піднімаєте слухавку, коли телефон дзвонить.
• 3:28
  Що таке вебхуки?
• 3:29
  Отже, що саме являє собою вебхук?
• 3:31
  Ось найпростіше визначення.
• 3:32
  Вебхук – це HTTP запит, який надсилається автоматично, коли щось стається.
• 3:36
  Ви не просите про це, сервер просто надсилає його вам.
• 3:39
  Уявіть це як дверний дзвінок.
• 3:40
  Ви не стоїте на дворі, перевіряючи кожні кілька хвилин.
• 3:43
  Ви встановлюєте дверний дзвінок.
• 3:44
  Коли хтось приходить, вони дзвонять.
• 3:46
  Ви чуєте дзвінок і відчиняєте.
• 3:47
  Дзвінок стежить за вас.
• 3:49
  Вебхуки іноді називають зворотними ARRI.
• 3:51
  Зі звичайним ARRI ваш додаток робить запит, і сервер відповідає.
• 3:55
  Ваш додаток контролює процес.
• 3:56
  З вебхуком сервер надсилає запит вашому додатку.
• 3:59
  Сервер контролює процес, але надсилає дані, замість того, щоб чекати, поки ви запитаєте.
• 4:02
  Microsoft Graph також використовує вебхуки, але Microsoft називає їх сповіщеннями про зміни.
• 4:07
  Це те саме, просто інша назва.
• 4:09
  Коли щось змінюється в Microsoft 365, Graph надсилає HTTP POST на надану вам URL-адресу.
• 4:15
  Цей POST містить інформацію про те, що саме змінилося.
• 4:17
  Існує багато речей, про які ви можете отримувати сповіщення.
• 4:20
  У вашому клієнті створюється новий користувач, оновлюється файл у SharePoint,
• 4:24
  надсилається повідомлення в Teams, змінюється подія в календарі або до групи додається новий учасник.
• 4:28
  Усе це може ініціювати сповіщення.
• 4:30
  Ось реальний приклад.
• 4:31
  Припустимо, ви керуєте компанією із системою обліку робочого часу.
• 4:34
  Коли з'являється новий співробітник, ви хочете автоматично створити для нього обліковий запис.
• 4:37
  Без вебхуків вам доводиться опитувати кінцеву точку користувачів кожні кілька хвилин, перевіряючи, чи не з'явилися нові люди.
• 4:41
  З вебхуками ви підписуєтеся на події створення користувачів.
• 4:44
  Коли хтось приєднується, граф надсилає вашому додатку сповіщення.
• 4:47
  Ваш додаток отримує його, перевіряє та створює обліковий запис усе за лічені секунди.
• 4:51
  Жодних опитувань, жодних марних запитів.
• 4:53
  Інший приклад.
• 4:54
  Ви маєте бібліотеку документів SharePoint, куди завантажуються квитанції.
• 4:57
  Без вебхуків ви постійно опитуєте бібліотеку.
• 5:00
  З вебхуками граф повідомляє вам, щойно файл додано.
• 5:03
  Ваш додаток отримує його, перевіряє, чи це квитанція, і обробляє її автоматично.
• 5:06
  У цьому і полягає сила вебхуків.
• 5:08
  Замість того, щоб ваш додаток постійно запитував, є щось нове.
• 5:11
  Ви дозволяєте системі повідомляти вас, коли щось стається.
• 5:13
  Це ефективніше, надійніше та значно швидше.
• 5:16
  Як працюють вебхуки Microsoft Graph?
• 5:18
  Тепер ви знаєте, що таке вебхуки та чому опитування є проблемою.
• 5:27
  Підписки, сповіщення та вашої кінцевої точки.
• 5:30
  По-перше, ви створюєте підписку.
• 5:32
  Ви кажете Microsoft Graph «Гей, я хочу знати, коли зміниться цей конкретний об'єкт».
• 5:36
  Ви надаєте граф деталі того, за чим стежити та куди надсилати звіти.
• 5:39
  Уявіть це як підписку на сповіщення.
• 5:41
  Ви повідомляєте системі, що вас цікавить, і надаєте свою контактну інформацію.
• 5:44
  По-друге, Microsoft Graph стежить за цим ресурсом.
• 5:46
  Він відстежує зміни.
• 5:47
  Коли щось трапляється, наприклад, створено користувача,
• 5:50
  оновлено файл або отримано повідомлення, граф помічає це.
• 5:52
  По-третє, граф надсилає сповіщення.
• 5:54
  Він відправляє HTTP POST на надану вами URL-адресу.
• 5:57
  Цей POST містить інформацію про те, що саме змінилося.
• 6:00
  Ваша кінцева точка отримує його, і ваш додаток обробляє це.
• 6:02
  Отже, загальний процес простий.
• 6:04
  Ви підписуєтеся, граф стежить, граф надсилає POST, коли щось змінюється.
• 6:08
  Давайте розберемо ці три компоненти трохи детальніше.
• 6:10
  Підписка – це ваш запит на отримання сповіщення.
• 6:13
  Це ніби сказати «Я хочу знати, коли в моєму клієнті буде додано нового користувача».
• 6:16
  Ви надсилаєте цей запит до Microsoft Graph, і граф зберігає його.
• 6:19
  З цього моменту граф стежить за ситуацією від вашого імені.
• 6:22
  Сповіщення – це власне попередження HTTP POST-запит, який граф надсилає на вашу кінцеву точку.
• 6:26
  Тіло POST-запиту містить деталі про зміни, який ресурс змінився, який тип зміни стався і коли це було.
• 6:31
  Ваша кінцева точка – це двері, які ви залишаєте відчиненими.
• 6:34
  Це URL-адреса на вашому сервері, налаштована для отримання таких POST-запитів.
• 6:37
  Вона має просто слухати та швидко відповідати.
• 6:39
  Ось і все.
• 6:40
  На стороні отримувача непотрібна складна логіка.
• 6:42
  Просто отримайте сповіщення, підтвердьте його і обробіть.
• 6:45
  Тепер порівняйте це з опитуванням Paulin.
• 6:47
  При опитуванні ви робите сотні DT-запитів, запитуючи, чи є щось нове.
• 6:51
  Найчастіше відповідь – ні.
• 6:52
  З вебхуками є лише один POST-запит з повіщення.
• 6:55
  Ось і все.
• 6:56
  Одне повідомлення замість сотень.
• 6:57
  Різниця в ефективності величезна і ваша кінцева точка не повинна бути складною.
• 7:01
  Вона має бути загальнодоступною, працювати через HTTPS і швидко відповідати.
• 7:05
  Ми трохи згодом поговоримо про те, що означає «швидко».
• 7:08
  Але основна ідея проста.
• 7:09
  Ваша точка слухає, граф викликає, ви відповідаєте і готово.
• 7:14
  Створення підписки.
• 7:15
  Отже, як саме це налаштувати?
• 7:17
  Давайте покроково розглянемо створення підписки.
• 7:20
  Ви починаєте з надсилання HTTP POST-запиту на конкретну URL-адресу в Microsoft Graph.
• 7:24
  Ця адреса – HTTPS2.2скіснірискиграф.microsoft.com.косариска.v1.0.косариска.сабскріпшнс.
• 7:29
  Ви надсилаєте запит безпосередньо на кінцеву точку підпису.
• 7:32
  У тілі цього запиту ви вказуєте деталі того, на що хочете підписатися.
• 7:35
  Є чотири ключові поля, які потрібно надати.
• 7:37
  Перше – це URL-сповіщення – Notification URL.
• 7:39
  Це URL вашої кінцевої точки – місце, куди Microsoft Graph надсилатиме сповіщення.
• 7:43
  Він має бути HTTPS і загальнодоступним, оскільки Graph повинен мати доступ до нього з інтернету.
• 7:47
  Друге – це ресурс Razos.
• 7:49
  Це вказує Graph, за чим саме ви хочете стежити.
• 7:51
  Ви вказуєте шлях до ресурсу Microsoft Graph.
• 7:53
  Наприклад, Uses, якщо хочете відстежувати зміни користувачів,
• 7:56
  або Me, MailFolders, Inbox, Messages, якщо хочете стежити за новими листами ухідних.
• 8:00
  Ресурс чітко пояснює Graph, що саме вас цікавить.
• 8:02
  Третє – це тип зміни Change Type.
• 8:04
  Це повідомляє Graph, про які саме типи змін вас сповіщати.
• 8:07
  Ви можете вказати створено Created, оновлено Updated, видалено Deleted або будь-яку комбінацію.
• 8:11
  Отже, якщо вас цікавить лише створення нових користувачів,
• 8:13
  ви встановлюєте тип зміни на Created.
• 8:14
  Якщо вас цікавлять і оновлення, ви встановлюєте Created, Updated.
• 8:17
  Четверте – це дата та час завершення, Expiration Date Time.
• 8:20
  Це час, коли термін дії підписки закінчується, оскільки вони не вічні.
• 8:23
  Ви встановлюєте дату і час, і після цього Graph припиняє надсилати сповіщення.
• 8:27
  Максимальна тривалість залежить від ресурсу, за яким ви стежите.
• 8:37
  Також варто згадати необов'язкове поле «Стан клієнта – Client State».
• 8:41
  Це секретний рядок, який ви створюєте самі.
• 8:43
  Це може бути будь-що на ваш вибір.
• 8:45
  Випадковий рядок – ідентифікатор – GUID, що завгодно.
• 8:48
  Microsoft Graph додає це значення до кожного сповіщення,
• 8:50
  яке надсилає на ваш кінцевий пункт, і ви використовуєте його,
• 8:52
  щоб перевірити, чи дійсно сповіщення надійшло від вашої підписки.
• 8:55
  Якщо хтось спробує надіслати підроблені сповіщення на ваш кінцевий пункт,
• 8:58
  стан клієнта не збігатиметься, і ви зможете одразу їх відхилити.
• 9:01
  Це простий захід безпеки, але він важливий.
• 9:03
  Створення підписки схоже на оформлення передплати на газету.
• 9:06
  Ви надаєте газеті свою адресу.
• 9:08
  Це ваша URL-адреса для сповіщень.
• 9:10
  Ви вказуєте, які розділи хочете отримувати,
• 9:12
  це ваш ресурс і тип змін, а також зазначаєте, як довго має тривати доставка.
• 9:16
  Це ваш час закінчення терміну дії.
• 9:17
  Газета бере на себе все інше.
• 9:19
  Але є нюанс – підписки мають термін дії.
• 9:21
  Ви не можете створити її і забути про це.
• 9:24
  Коли час закінчення терміну дії минає,
• 9:26
  граф припиняє надсилати сповіщення, і ваша підписка зникає.
• 9:29
  Якщо ви хочете й надалі отримувати сповіщення,
• 9:31
  потрібно поновити підписку до закінчення її терміну,
• 9:33
  надіславши запит PATCH до кінцевого пункту підписки з новим часом закінчення.
• 9:36
  Отже, створення підписки – це перший крок, але не останній.
• 9:39
  Вам потрібно керувати життєвим циклом.
• 9:41
  Ми поговоримо про це докладніше пізніше.
• 9:43
  Процес перевірки – handshake.
• 9:44
  Перш ніж ваша підписка запрацює, є один крок, який не можна пропускати.
• 9:48
  Microsoft Graph не просто приймає запит на підписку і починає надсилати сповіщення.
• 9:51
  Спочатку він має переконатися, що ваш кінцевий пункт справжній і готовий їх отримувати.
• 9:55
  Ось як це працює.
• 9:56
  Коли ви надсилаєте POST-запит для створення підписки,
• 9:59
  Microsoft Graph негайно надсилає тестовий запит на вашу URL-адресу для сповіщень.
• 10:02
  Цей тестовий запит містить параметр запиту, який називається токеном перевірки validation token.
• 10:06
  Це просто випадковий рядок.
• 10:07
  Ваш кінцевий пункт повинен отримати цей токен і надіслати його назад як відповідь у форматі звичайного тексту,
• 10:11
  при чому зробити це потрібно протягом 10 секунд.
• 10:12
  Уявіть це як кур'єра, що доставляє посилку.
• 10:15
  Він приходить до ваших дверей і запитує, чи це правильна адреса.
• 10:17
  Чи можете ви це підтвердити?
• 10:18
  Ви повинні розписатися за неї.
• 10:20
  Якщо ви цього не зробите, він піде геть.
• 10:21
  Кур'єр не залишить посилку.
• 10:23
  Він просто піде.
• 10:24
  Саме це відбувається тут.
• 10:25
  Microsoft Graph ніби каже, я збираюся надіслати вам важливі сповіщення.
• 10:29
  Доведіть, що ви та сама особа за правильною адресою.
• 10:32
  Ваша кінцева точка відповідає, повертаючи маркер перевірки, який каже Graph, так, я тут.
• 10:38
  Я слухаю.
• 10:39
  Надсилайте мені сповіщення.
• 10:40
  Ось тут багато розробників припускаються помилок.
• 10:43
  Маркер перевірки має бути повернутий як звичайний текст, не JSON, не HTML, а саме звичайний текст.
• 10:48
  І відповідь повинна містити заголовок Content Type, встановлений на Text Plain.
• 10:51
  Якщо ви відправите його загорнутим у JSON або будь-яким чином закодованим, перевірка не пройде.
• 10:55
  Ваша підписка не буде створена.
• 10:57
  Microsoft Graph поверне помилку, і ви будете думати, що пішло не так.
• 11:00
  Є ще одна технічна деталь, про яку варто знати.
• 11:02
  Сервіс перевірки Microsoft Graph ненадійно підтримує TLS 1.3.
• 11:06
  Він працює з TLS 1.2.
• 11:08
  Тож, якщо ваша кінцева точка приймає лише TLS 1.3,
• 11:11
  рукостискання перевірки не відбудеться ще до запуску вашого коду.
• 11:14
  Ви повинні переконатися, що ваша кінцева точка підтримує TLS 1.2, принаймні для етапу перевірки.
• 11:19
  Після цього ви можете використовувати будь-яку версію TLS для безпосереднього отримання сповіщень.
• 11:23
  Хороша новина в тому, що це рукостискання перевірки відбувається лише один раз на підписку.
• 11:27
  В вашій кінцевій точці не потрібно обробляти це щоразу, коли надходить сповіщення лише вперше.
• 11:31
  Як тільки граф підтверджує справжність вашої кінцевої точки, він довіряє їй протягом усього терміну дії підписки.
• 11:36
  Отже, вам потрібно зробити це правильно лише один раз.
• 11:38
  Обробка сповіщень та безпека.
• 11:40
  Після успішного рукостискання перевірки та активації підписки Microsoft Graph починає надсилати сповіщення.
• 11:46
  Отже, як це виглядає на практиці?
• 11:48
  Коли щось змінюється, Graph надсилає HTTP OST на вашу кінцеву точку з JSON-об'єктом у тілі запиту.
• 11:54
  Цей об'єкт містить ресурс, який змінився тип зміни створення, оновлення чи видалення та мітку часу.
• 12:00
  Він також містить значення клієнтського стану, Client State, яке ви вказали при створенні підписки.
• 12:04
  Це ваш секретний рядок, спосіб переконатися, що повідомлення справжнє.
• 12:07
  Тож ось перше, що потрібно зробити при надходженні сповіщення.
• 12:10
  Перевірте цей клієнтський стан.
• 12:11
  Порівняйте значення у сповіщенні з секретом, який ви зберегли під час створення підписки.
• 12:15
  Якщо вони не збігаються, негайно відкиньте його, оскільки це може бути підробка,
• 12:18
  хтось намагається змусити вашу систему обробити невірні дані.
• 12:21
  Це важливо, оскільки ваша кінцева точка знаходиться у відкритому доступі в інтернеті.
• 12:24
  Будь-хто, хто знає вашу URL-адресу, може надіслати на неї піовості запит.
• 12:27
  Без перевірки клієнтського стану у вас не було б способу відрізнити справжнє сповіщення Microsoft Graph від підробки.
• 12:33
  Це проста перевірка, але це ваш перший рубіж оборони.
• 12:35
  Після того, як ви підтвердили справжність сповіщення, вам потрібно швидко відповісти.
• 12:39
  Microsoft Graph очікує HTTP відповідь 200-го рівня протягом 3 секунд.
• 12:43
  Якщо ви витрачаєте більше часу, Graph це помічає.
• 12:45
  І якщо це стається надто часто, Graph починає ставитися до вас інакше.
• 12:48
  Ось як працює обмеження швидкості.
• 12:50
  Якщо понад 10% ваших відповідей перевищують 3-секундне вікно за будь-який 10-хвилинний період,
• 12:54
  Microsoft Graph позначає вашу кінцеву точку як повільну.
• 12:56
  Коли це стається, нові сповіщення затримуються на 10 хвилин.
• 13:00
  Вони все одно надходять згодом, але ви втрачуєте доставку в реальному часі.
• 13:03
  А якщо ситуація погіршується і понад 15% ваших відповідей перевищують 10 секунд,
• 13:07
  Graph позначає вашу кінцеву точку як відкинуту.
• 13:09
  У такому стані сповіщення повністю відкидаються протягом 10 хвилин.
• 13:18
  Якщо ви не відповідаєте швидко, той, хто дзвонить, спробує знову пізніше.
• 13:22
  Але якщо ви ніколи не відповідаєте, зрештою той, хто дзвонить, здається.
• 13:24
  Microsoft Graph – це той, хто дзвонить, а ваша кінцева точка – це телефон.
• 13:27
  Відповідайте швидко або ризикуєте втратити повідомлення.
• 13:30
  Отже, яка тут найкраща практика?
• 13:32
  Підтверджуйте негайно та обробляйте асинхронно.
• 13:34
  Ваша кінцева точка має перевірити стан клієнта,
• 13:37
  прийняти сповіщення та повернути відповідь 200 або 202 якнайшвидше.
• 13:41
  Потім додайте сповіщення в чергу для фонової обробки.
• 13:44
  Черга Azure – сервісна шина або навіть проста таблиця бази даних.
• 13:47
  Суть у тому, щоб швидко вийти з циклу відповіді
• 13:49
  та дозволити вашим фоновим процесам виконати основну роботу.
• 13:52
  І ще одне нагадування про безпеку –
• 13:54
  ваша кінцева точка має бути HTTPS без винятків.
• 13:56
  Microsoft Graph не надсилатиме сповіщення на HTTP кінцеву точку.
• 13:59
  І ваша кінцева точка має бути публічно доступною.
• 14:02
  Якщо вона забрань мауером або VPN, Graph не зможе до неї дістатися.
• 14:04
  Для розробки ви можете використовувати такі інструменти, як Engrok,
• 14:07
  для створення публічного тунелю до вашої локальної машини.
• 14:09
  Але в робочому середовищі ваша кінцева точка має розміщуватися там,
• 14:12
  де граф може її знайти.
• 14:13
  Підтримка життєвого циклу сповіщень.
• 14:16
  Отже, ви налаштували підписку, сповіщення надходять, і все виглядає добре.
• 14:19
  Але ось що застає багатьох людей з ненацька.
• 14:22
  Ваша підписка має термін дії.
• 14:24
  Вона не триває вічно.
• 14:25
  Залежно від ресурсу, за яким ви стежите,
• 14:27
  максимальна тривалість підписки зазвичай становить від 3 до 7 днів.
• 14:30
  Для деяких ресурсів, як от файли на диску в SharePoint,
• 14:32
  можна отримати до 30 днів.
• 14:34
  Але головне, вона не є постійною.
• 14:36
  Ви не можете створити підписку і забути про неї.
• 14:38
  Уявіть це як підписку на журнал.
• 14:40
  Ви підписалися, почали отримувати номери, і все чудово.
• 14:43
  Але якщо ви не поновите підписку до того, як вона закінчиться,
• 14:45
  номери перестануть надходити.
• 14:46
  Те саме і тут.
• 14:47
  Якщо ваша підписка закінчується, Microsoft Graph припиняє надсилати сповіщення.
• 14:50
  І ви можете цього не помітити, поки не здивуєтеся, чому нічого не відбувається.
• 14:53
  Отже, вам потрібна стратегія оновлення.
• 14:55
  Спосіб оновлення простий.
• 14:56
  Надійшліть PATCH запит до кінцевої точки підписки,
• 14:59
  використовуючи ідентифікатор підписки, іонові дату та час закінчення на нову майбутню дату.
• 15:02
  Це подовжує термін дії підписки.
• 15:04
  Ви можете робити це скільки завгодно разів,
• 15:06
  головне – до моменту закінчення поточного терміну дії.
• 15:08
  Microsoft Graph допомагає вам у цьому за допомогою так званих сповіщень про життєвий цикл.
• 15:13
  При створенні підписки ви можете вказати окрему URL-адресу,
• 15:15
  яка називається URL-адресою сповіщень про життєвий цикл.
• 15:18
  Microsoft Graph надсилає сповіщення на цю адресу, коли відбуваються певні події.
• 15:22
  Наприклад, коли ваша підписка ось-ось закінчиться,
• 15:24
  термін дії маркера доступу добігає кінця або змінюється дозволи вашого застосунку.
• 15:27
  Ці сповіщення про життєвий цикл дають вам попередження.
• 15:30
  Вам не потрібно вгадувати, коли закінчиться ваша підписка.
• 15:32
  Graph каже вам, гей, ваша підписка закінчується за кілька годин.
• 15:35
  Можливо, вам варто її оновити.
• 15:37
  Це як отримати нагадування від видавця журналу про те, що ваша передплата скоро закінчиться.
• 15:41
  Дуже корисно, якщо ви звертаєте на це увагу.
• 15:43
  Але що робити, якщо все пішло не так?
• 15:45
  Можливо, ваша кінцева точка тимчасово вимкнулася,
• 15:47
  або сповіщення були втрачені через вашу повільну роботу.
• 15:49
  Що тоді? Ось тут на допомогу приходить дельта-запит, окрема функція Microsoft Graph,
• 15:53
  яка дозволяє запитати, що змінилося з моменту останньої перевірки.
• 15:56
  І він повертає лише зміни, нічого більше.
• 15:59
  Ось як це працює.
• 16:00
  Коли ви вперше запускаєте дельта-запит до ресурсу, наприклад, до користувачів,
• 16:03
  Graph повертає всіх користувачів вашого тенента.
• 16:04
  Але він також повертає дещо додаткове спеціальне посилання,
• 16:06
  яке називається дельта-посиланням.
• 16:08
  Ви зберігаєте це посилання.
• 16:09
  Наступного разу, коли ви запустите той самий запит, ви використаєте це дельта-посилання.
• 16:12
  І замість того, щоб знову отримувати всіх користувачів,
• 16:14
  ви отримаєте лише тих, хто змінився з моменту вашого останнього запиту.
• 16:16
  Нові користувачі, оновлені користувачі, видалені користувачі.
• 16:19
  Це все.
• 16:20
  Сприймайте це як читання списку новин замість того,
• 16:22
  щоб щоразу перечитувати всю енциклопедію.
• 16:24
  Набагато швидше і значно менше даних.
• 16:26
  А тепер про розумний шаблон.
• 16:28
  Поєднуйте вебхуки з дельта-запитами.
• 16:29
  Використовуйте вебхуки, щоб дізнатися, коли щось змінилося,
• 16:31
  а потім використовуйте дельта-запит, щоб з'ясувати, що саме змінилося.
• 16:34
  Дозвольте пояснити, чому це важливо.
• 16:36
  Вебхуки швидкі, але вони не ідеальні.
• 16:37
  Сповіщення можуть губитися, підписки можуть закінчуватися,
• 16:39
  а ваша кінцева точка може вимкнутися.
• 16:41
  Але дельта-запит надійний.
• 16:42
  Ви можете запустити його будь-коли, і він надасть повний список змін
• 16:44
  з моменту вашої останньої перевірки.
• 16:46
  Отже, навіть якщо ви пропустите сповіщення,
• 16:48
  ви зможете наздогнати втрачене.
• 16:49
  Ось типовий робочий процес.
• 16:50
  Налаштуйте підписку на вебхук для відстеження змін користувачів.
• 16:53
  Виконайте початковий дельта-запит, щоб отримати базовий стан
• 16:55
  і зберегти дельта-посилання.
• 16:57
  Коли надходить вебхук про зміну користувача,
• 16:58
  виконайте дельта-запит, використовуючи збережене дельта-посилання.
• 17:01
  Це надасть вам точну інформацію про зміни.
• 17:03
  Обробіть їх, а потім збережіть нове дельта-посилання з цієї відповіді.
• 17:06
  Наступного разу, коли надійде вебхук, повторіть цей процес.
• 17:09
  І якщо ви раптом пропустите сповіщення або ваша підписка закінчиться,
• 17:12
  просто виконайте дельта-запит знову.
• 17:13
  Ви отримаєте все, що пропустили.
• 17:15
  Це як запобіжна сітка.
• 17:16
  Вебхуки забезпечують швидкість, а дельта-запит – надійність.
• 17:19
  Разом вони складають потужну комбінацію.
• 17:21
  Приклад із реального життя та наступні кроки.
• 17:24
  Уявіть, що завтра до вашої компанії приєднується новий співробітник.
• 17:27
  Хтось із відділу кадрів створює обліковий запис у Microsoft EntraID,
• 17:30
  і ця дія запускає ланцюгову реакцію.
• 17:32
  Якщо ви налаштували підписку на вебхоп для змін користувачів,
• 17:35
  Microsoft Graph миттєво помітиться і надійшли POST-запит на ваш кінцевий вузол.
• 17:39
  Ось що відбувається далі.
• 17:40
  Ваш кінцевий вузол отримує сповіщення, перевіряє стан клієнта,
• 17:43
  і якщо він збігається з вашим секретним ключем, ви знаєте, що це легітимно.
• 17:46
  Ви повертаєте відповідь 202 Accepted протягом трьох секунд,
• 17:49
  підтверджуючи отримання сповіщення, а потім ваш фоновий процес підхоплює його.
• 17:53
  Він бачить, що користувача було створено, але сповіщення не містить усіх деталей,
• 17:56
  тому він виконує дельтазапит, використовуючи збережене дельтапосилання.
• 17:59
  Це повертає повну інформацію про нового користувача, ім'я, імейл, відділ, посаду, керівника, все, що вам потрібно.
• 18:05
  Тепер ваш процес бере цю інформацію і створює обліковий запис для нового співробітника у вашій сторонній системі обліку часу.
• 18:10
  Він надсилає вітальний лист.
• 18:12
  Він додає користувача до відповідних списків розсилки.
• 18:14
  Все це відбувається за лічені секунди після того, як відділ кадрів створив обліковий запис у EntraID.
• 18:18
  Жодних опитувань, жодних ручних дій, жодних затримок.
• 18:21
  Подумайте про альтернативу.
• 18:23
  Без вебхуків вам довелося б опитувати кінцевий вузол користувачів кожні кілька хвилин,
• 18:26
  роблячи сотні запитів на день, і навіть тоді ви могли б дізнатися про нового користувача лише через кілька хвилин.
• 18:30
  З вебхуками це відбувається миттєво.
• 18:32
  Одне сповіщення, один дельтазапит. Готово.
• 18:34
  У цьому й полягає справжня цінність.
• 18:35
  Ваша система стає швидшою, ефективнішою і менш схильною до обмежень швидкості.
• 18:39
  Замість того, щоб постійно запитувати граф про оновлення,
• 18:41
  ви дозволяєте граф повідомляти вас, коли щось стається.
• 18:43
  Це фундаментальна зміна в тому, як ви будуєте інтеграції.
• 18:45
  Тож ось що я хочу, щоб ви спробували.
• 18:47
  Подумайте про один процес, який ви зараз опитуєте.
• 18:49
  Можливо, ви перевіряєте наявність нових листів у спільній поштовій скринці.
• 18:52
  Можливо, ви відстежуєте зміни файлів у бібліотеці SharePoint.
• 18:55
  Можливо, ви моніторите оновлення користувачів для вашої HR-системи.
• 18:57
  Чи може WebHub замінити таке опитування?
• 18:59
  У більшості випадків відповідь так, і вам не потрібно будувати все самому.