Latest / M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском / Уведомления об изменениях Microsoft Graph простыми словами: реальное время вместо опроса (ИИ-дубляж)

Transcript

Уведомления об изменениях Microsoft Graph простыми словами: реальное время вместо опроса (ИИ-дубляж) · M365.FM – подкаст о Microsoft 365, Copilot и ИИ на русском

• 0:00
  Готовы к 10 дням погружения в Microsoft 365, Капайлот, ИИ, Азур и знакомство с людьми,
• 0:06
  определяющими будущие работы. В этом январе М365Кон возвращается, и мы берем еще более
• 0:11
  высокую планку. Присоединяйтесь к нам, прямые эфиры, реальные демо и практические знания от
• 0:16
  MVP и экспертов со всего мира. Никаких общих слайдов и пустых модных словарей. Мы решаем
• 0:22
  реальные задачи, Капайлот Студия, ИИ агенты, фабрик, безопасность, управление и автоматизация.
• 0:29
  Независимо от того, кто вы IT-специалист, разработчик или бизнес-лидер, для вас найдутся
• 0:34
  подходящие сессии. За 10 полных дней вы сможете изучить множество технологий и пообщаться с
• 0:39
  мировым сообществом. Смотрите в прямом эфире и применяйте практические идеи в своей организации.
• 0:44
  Январь 2027 года, 10 дней, одно сообщество Microsoft. Регистрация уже открыта. Заходите на
• 0:52
  m365con.net и забронируйте свое место сегодня. Это m365con.net. Присоединяйтесь на m365con.net и
• 1:03
  увидимся в прямом эфире в январе. Сегодняшняя тема знакома почти каждому, кто работает с
• 1:07
  Microsoft 365. Но большинство людей не до конца понимают, как это работает изнутри. Я говорю об
• 1:13
  уведомлениях об изменениях в Microsoft Graph. Что это такое и почему это важно для вас? Начнем с проблемы,
• 1:19
  которую они решают. Представьте, что вы создаете приложение, которому нужно знать об изменениях в
• 1:23
  Microsoft 365. Например, пришло новое письмо, кто-то обновил файл в SharePoint или в каталог компании
• 1:28
  добавлен новый пользователь. Как об этом узнает ваше приложение? Дело в том, что старый метод — это
• 1:32
  опрос. Поллинг. Ваше приложение каждые несколько минут отправляет запрос в Microsoft Graph. Есть что-нибудь
• 1:36
  новое с момента моей последней проверки? Если ничего не изменилось, вы потратили запрос впустую. А если
• 1:41
  изменения произошли через 5 секунд после проверки, вы не узнаете об этом до следующего цикла. Вы либо проверяете
• 1:45
  слишком часто, расходуя ресурсы и рискуя получить блокировку, либо слишком
• 1:49
  редко пропуская события. Microsoft действительно ограничивает приложения, которые делают запросы
• 1:53
  слишком часто. Разработчики называют это «тюрьмой граф», ваше приложение блокируется на время из-за
• 1:57
  избытка запросов. Возникает вопрос, разве нет способа лучше? Что, если вместо того, чтобы постоянно
• 2:02
  спрашивать, есть что-нибудь новое? Система сама будет сообщать вам об изменениях. Именно это и делают
• 2:07
  уведомления об изменениях. Что такое уведомления об изменениях Microsoft Graph? Вот самое простое
• 2:12
  определение. Уведомления позволяют вашему приложению мгновенно реагировать на события в Microsoft 365 без
• 2:18
  постоянных проверок. Представьте это как датчик движения на вашем почтовом ящике. Вместо того,
• 2:22
  чтобы каждый час подходить и заглядывать внутрь, вы устанавливаете датчик, который оповещает вас,
• 2:26
  как только пришло письмо. Вы перестаете тратить время на пустые проверки и никогда не пропускаете
• 2:29
  доставку. Именно это уведомление об изменениях делают для вашего приложения. Когда что-то меняется,
• 2:33
  например, приходит новое письмо, обновляется файл или календарное событие, Microsoft Graph автоматически
• 2:38
  отправляет уведомления в ваше приложение. Опрос не требуется. Эта система состоит из двух частей – подписки и
• 2:43
  уведомления, которые работают вместе. Подписка – это-то, как вы сообщаете Microsoft Graph,
• 2:48
  зачем нужно следить. Вы говорите что-то вроде «Эй, сообщи мне», когда кто-то пришлет новое сообщение
• 2:52
  в этот почтовый ящик. Или «Скажи мне», когда обновится файл в этой библиотеке SharePoint. Вы
• 2:56
  регистрируете свой интерес, а граф берет его на заметку. Уведомления – это-то, что происходит дальше.
• 3:00
  Когда происходит изменение, граф отправляет HTTP POST запрос на указанный вами InPoint. Ваше приложение
• 3:05
  получает этот POST запрос, понимает, что что-то произошло и решает, что делать, получить новые данные,
• 3:10
  запустить рабочий процесс или обновить базу данных. В этом главное отличие от опроса.
• 3:15
  Уведомления доставляются автоматически. Вашему приложению не нужно спрашивать. Система сама
• 3:19
  отправляет информацию в момент события. В этом все волшебство. Microsoft Graph поддерживает
• 3:23
  уведомления об изменениях для широкого спектра ресурсов. Сообщения, события, контакты, пользователи,
• 3:28
  группы, файлы, сообщения Teams, оповещения безопасности – практически все. К чему вы получаете доступ
• 3:32
  через граф, можно отслеживать. Но как это настроить? Как сказать граф, зачем следить и куда отправлять
• 3:37
  оповещение? Создание подписки – это указание граф, зачем следить. Итак, что такое подписка?
• 3:42
  Это просто запрос на регистрацию. Ваше приложение говорит «дай мне знать, когда это произойдет»,
• 3:46
  и вы отправляете этот запрос в API Microsoft Graph. Граф сохраняет его и ждет. В этом запросе вам
• 3:50
  нужно предоставить граф несколько деталей. Во-первых, ресурс, за которым вы хотите следить,
• 3:54
  путь к данным. Например, в Узерс, если вы очлеживаете изменения учетных записей пользователей.
• 3:59
  Или М, Mail Folders, Inbox, Messages, если вы хотите знать о новых письмах. Далее, тип изменения.
• 4:04
  Хотите ли вы знать, когда что-то создано, обновлено или удалено? Можно выбрать один тип или
• 4:09
  запросить все три. В-третьих, URL уведомлений. Это адрес вашего инпоинта, место, куда граф
• 4:13
  должен отправить уведомления при возникновении события. Это должен быть общедоступный
• 4:17
  HTTPS InPoint. Никаких исключений. В-четвертых, дата истечения срока действия. Подписки не
• 4:22
  могут длиться вечно. Вы выбираете дату и время в будущем, когда подписка истечет. Однако для разных
• 4:26
  ресурсов установлены разные максимальные сроки действия. Для сообщений Outlook они могут составлять
• 4:30
  до 7 дней. Максимальный срок для сообщений в чатах Teams составляет 3 дня. Файлы SharePoint могут
• 4:33
  храниться около 30 дней. Информация о присутствии. Она истекает всего через 1 час. Вот конкретный
• 4:38
  пример. Допустим, вы хотите знать, когда кто-то в вашей компании меняет должность. Вы создаете
• 4:43
  подписку на ресурс пользователей с типом изменения «Обновлено». Вы указываете URL для уведомлений и
• 4:48
  задаете срок действия на несколько дней вперед. Когда кто-то обновляет свой профиль в Azure Ad,
• 4:51
  граф отправляет POST-запрос на вашу конечную точку с полезной нагрузкой уведомления. Эта нагрузка
• 4:55
  содержит идентификатор пользователя и сообщает вам, что именно изменилось. Ваше приложение может
• 4:59
  среагировать на это, обновить кадровую систему, отправить уведомления менеджеру или сделать что
• 5:03
  угодно еще. Граф отвечает на ваш запрос подписки, предоставляя идентификатор подписки. Он понадобится
• 5:07
  вам позже для управления подпиской, продления, обновления или удаления. Но есть один нюанс. Прежде
• 5:12
  чем граф начнет отправлять уведомления, он должен убедиться, что ваша конечная точка активна и слушает
• 5:17
  запросы. Для этого требуется рукопожатие. Разбор токена проверки рукопожатия. При создании подписки
• 5:22
  Microsoft граф не доверяет вашей конечной точке вслепую. Сначала он отправляет тестовый пинк, запрос на верификацию.
• 5:29
  Этот пинк содержит токен проверки, случайную строку символов. Ваша конечная точка должна получить
• 5:34
  этот токен и вернуть его в виде обычного текста в течение 10 секунд. Представьте, что курьер звонит
• 5:38
  в вашу дверь, чтобы убедиться, что вы дома, прежде чем оставить посылку. Если никто не отвечает,
• 5:42
  курьер ничего не оставляет. Здесь то же самое. Если ваша конечная точка не вернет токен проверки,
• 5:47
  граф не будет отправлять на нее уведомления. Ответ должен быть в формате обычного текста,
• 5:51
  а не JSON или XML, только строка токена. Если ошибиться с форматом, рукопожатие не удастся.
• 5:56
  Это проверка безопасности. Она подтверждает, что ваша конечная точка активна, готова к работе и
• 6:00
  находится под вашим контролем. Это мешает злоумышленникам направлять подписку на чужой URL в
• 6:04
  надежде перехватить чужие уведомления. Нет рукопожатия, нет подписки. Граф отклоняет запрос на
• 6:09
  создание, и вы получаете ошибку. Вы исправляете свою конечную точку и пробуете снова. Как только
• 6:13
  рукопожатие успешно завершено, подписка активируется и уведомления начинают поступать.
• 6:17
  Но вот в чем дело. Они не будут поступать вечно. Поддержание соединения.
• 6:21
  Продление подписки. У каждой подписки есть срок действия. Вы задаете его при создании. Граф
• 6:27
  строго следит за ним. Когда наступает этот день, подписка прекращается. Уведомления больше не
• 6:31
  приходят. Представьте это как парковочный счетчик. Вы оплачиваете время, а когда оно заканчивается,
• 6:36
  срок действия счетчика истекает. Для разных ресурсов установлены разные лимиты. Сообщения
• 6:40
  Outlook могут отчлеживаться до 7 дней. Чаты Teams – 3 дня. Файлы SharePoint – около 30 дней. А информация
• 6:45
  о присутствии – всего 1 час. Итак, ваше приложение не может просто создать подписку и забыть о ней. Вам нужен
• 6:50
  процесс, который поддерживает ее активность. Продление – это просто. Отправьте PATCH запрос с
• 6:54
  идентификатором подписки. Укажите новую дату истечения срока действия. Сделайте это до того,
• 6:58
  как текущая подписка истечет, и граф продлит ее. Вот лучшая практика, которую я рекомендую.
• 7:03
  Проверяйте метку времени истечения срока в каждом получаемом уведомлении. Если срок скоро истекает,
• 7:07
  например, в течение дня, продлите ее сразу. Так вам не понадобится отдельная фоновая задача только
• 7:11
  для управления подписками. Microsoft также добавила уведомления о жизненном цикле. Эти оповещения
• 7:16
  предупреждают вас до того, как подписка истечет. Они сообщают, когда срок действия подписки
• 7:20
  подходит к концу или когда требуется повторная авторизация токена доступа. Подпишитесь на них,
• 7:23
  и ваше приложение сможет продлеваться до того, как что-то сломается. Но что, если ваш
• 7:26
  инпоинт выйдет из строя или вы пропустите окно продления? Вот тут-то и появляется страховочная
• 7:30
  сетка. Когда что-то идет не так, надежность и страховочные механизмы. Ваша подписка активна,
• 7:35
  инпоинт слушает, уведомления поступают. Все выглядит хорошо, но что произойдет, если что-то сломается?
• 7:40
  Может быть, инпоинт отключился на обслуживание, сетевая проблема прервала уведомление или вы просто
• 7:44
  пропустили окно продления и подписка истекла? Такое случается. Вопрос в том, как восстановиться.
• 7:49
  Microsoft граф ожидает, что ваш випхук-инпоинт будет отвечать быстро, в течение 3 секунд. Если
• 7:53
  дольше, граф помечает его как медленный. Если более 10% ответов превышают 3 секунды в любой
• 7:58
  10-минутный период, граф задерживает уведомление на 10 минут. Он отправляет лишь небольшую выборку,
• 8:02
  чтобы проверить, восстановились ли вы. Дальше – хуже. Если более 15% ответов превышают 10-секундный
• 8:07
  тайм-аут повторной попытки, граф помечает инпоинт как отброшенный. Уведомления полностью
• 8:10
  прекращаются на 10 минут. Они исчезают, вы не сможете их вернуть, поэтому ваш инпоинт должен быть
• 8:15
  быстрым и надежным. Это не значит, что вы должны обрабатывать каждое уведомление менее чем за 3
• 8:19
  секунды. Просто быстро подтвердите получение ответом 202 аксептет, а затем обрабатывайте уведомление
• 8:24
  асинхронно. Поставьте его в очередь. Обработайте позже. Главное – это быстрый отклик. Даже при идеальном
• 8:29
  инпоинте что-то может пойти не так. Подписки истекают, сетевые сбои случаются. В редких случаях сам
• 8:34
  Microsoft Graph может пропустить уведомления. Вот почему вам нужна страховочная сетка
• 8:38
  Дельта-запросы. Подумайте об этом так. Уведомления об изменениях – это пожарная сигнализация.
• 8:42
  Они сообщают вам, что что-то происходит прямо сейчас. Дельта-запросы – это система пожаротушения.
• 8:45
  Они ловят все, что пропустила сигнализация. Они работают вместе. Уведомления дают вам информацию
• 8:49
  в реальном времени. Дельта-запросы дают вам полную картину, которую можно сверить в любой момент.
• 8:53
  Рекомендуемый шаблон прост. Используйте уведомления об изменениях для мгновенного реагирования.
• 8:57
  Периодически. Скажем, раз в несколько часов или раз в день. Запускайте Дельта-запрос,
• 9:04
  или подписка из стекла. Вы никогда не пропустите изменения навсегда. Реальные сценарии
• 9:08
  использования. Что можно создать? Итак, что это дает на практике? Позвольте привести вам
• 9:12
  несколько реальных примеров. Возьмем автоматизацию кадров. Представьте, что завтра в вашу
• 9:16
  компанию придет новый сотрудник. В момент создания пользователя в интро-айде отправляется
• 9:19
  уведомление об изменении. Ваше приложение получает его профиль и за секунды создает учетные записи
• 9:23
  в кадровой системе, системе учета времени и контроля доступа. Никакого опроса, никаких задержек.
• 9:28
  Для оповещения безопасности, скажем, учетная запись пользователя заблокирована. Уведомление об изменении
• 9:32
  запускает рабочий процесс, который проверяет подозрительные действия и оповещает службу
• 9:35
  безопасности. Раньше вам приходилось опрашивать систему каждые несколько минут. Теперь это
• 9:38
  происходит мгновенно. Обработка контента работает точно так же. Когда файл попадает в библиотеку
• 9:42
  документов SharePoint, вы хотите знать, является ли он счетом. Уведомление сообщает вам о появлении
• 9:47
  нового файла. Ваше приложение забирает его, классифицирует с помощью и отправляет в нужную систему
• 9:51
  расходов все автоматически. Панели мониторинга в реальном времени позволяют видеть аналитику по мере
• 9:54
  поступления данных, а не с задержкой в часы. Уведомление об изменениях мгновенно синхронизирует
• 9:58
  Dataverse Fabric. Ваши панели Power BI обновляются практически в реальном времени. Вот пример,
• 10:02
  который кажется мне интересным. Коннекторы Copilot. Microsoft добавляет синхронизацию в реальном
• 10:07
  времени через вип-хуки, поэтому и агенты реагируют в ту же секунду, когда меняются данные.
• 10:10
  Когда запись клиента обновляется в Dynamics 365, агент Copilot немедленно готовит ответ «ждать не нужно».
• 10:17
  Все эти примеры объединяет одно. До появления уведомлений об изменениях вы создавали
• 10:21
  запланированные задания, которые опрашивали систему каждый час или день. Это работало,
• 10:25
  но было медленно, неэффективно и ненадежно. Уведомления об изменениях меняют эту модель.
• 10:29
  В реальном времени на основе событий мгновенно. Выбор правильного канала доставки. Не каждому
• 10:34
  приложению нужен один и тот же метод доставки. Давайте рассмотрим ваши варианты.
• 10:37
  Вип-хуки — самый простой способ. Граф отправляет HTTP OST на вашу конечную точку,
• 10:41
  вы обрабатываете его и работаете дальше. Для низкого или среднего объема, скажем,
• 10:44
  несколько сотен уведомлений в час, это отлично подходит. Но что, если вы создаете что-то более
• 10:48
  масштабное? Тысячи уведомлений в секунду могут перегрузить одну конечную точку. Вам нужно более
• 10:52
  мощное решение. Event Hub is обрабатывает миллионы событий в секунду. Вместо того,
• 10:56
  чтобы граф отправлял уведомления по одному, он отправляет их в хаб. Ваше приложение считывает
• 11:00
  их в своем темпе. Риск перегрузки минимален. Это решение для крупных корпоративных задач,
• 11:04
  таких как тысячи сайтов SharePoint или миллионы почтовых ящиков. И есть еще Event Grid — бессерверный
• 11:08
  вариант. Он отправляет уведомления в Azure Functions или Logic Apps, а также автоматически
• 11:11
  обрабатывает повторные попытки и отправку в очередь недоставленных сообщений.