1

更新：问题解决了！Webhook 现在又开始工作了。
因此问题变为：有没有办法轻松查看 Azure/Microsoft Graph 是否有问题？

昨天的故事
在创建了由订阅 Office365 日历事件更改触发的整个事件链后，事件停止滚动。创建新订阅仍会产生验证端点的请求；但是没有收到任何实际事件。

我们验证了我们确实在创建订阅，随后使用 Microsoft 的Graph Explorer手动创建订阅，以排除我们代码的任何问题。我们还可以肯定地说传入的请求被正确记录了。

在向@AzureSupport 发推文后，我们被指示在这里创建一个他们可以传递给“团队”的问题。

原始问题：
突然，azure graph 不再发送 webhook 调用以更改订阅的图形项目。

认为这可能是一个代码问题，而不是一个天蓝色的问题，我去 Graph Explorer 检查它。

脚步：

  • 使用查找日历 IDGET /me/calendars
  • 创建了一个（创建、更新、删除）订阅POST /subscriptions
  • 注意：这返回了一个有效的响应，并且还使用服务器日志证明的验证请求调用了我的端点
  • 已订阅日历的列出事件GET /me/calendars/<id>/events
  • 获取特定事件GET /me/events/<id>
  • 通过将请求方法更改DELETE为下拉列表中的删除该事件。收到一个204。

这一切，在我们尝试了与我们实际构建的类似的事情（并通过outlook.office.com 网络界面编辑订阅的事件）之后......并且在输入所有这些之后，除了验证请求之外什么都没有。

昨天，它在世界标准时间 17:06:45 开始工作，但在世界标准时间 17:45:09 之前还没有。

我们创建/更新 webhook 的方式没有任何改变，它们刚刚停止工作。

是否有某种限制会默默地失败？（我一直在创建/让很多 webhook 过期，但一次只有一两个处于活动状态）

想法？（除了诉诸民意调查？）还要感谢@AzureSupport Twitter 上的指点我！

那么，是否有图形事件的状态端点？

4

1 回答 1

1

对于您在使用 Microsoft Graph webhook 通知时遇到的问题，我们深表歉意。

这是发生的事情：

我们遇到了容量问题，导致部分通知延迟交付。一些订阅受到的影响比其他订阅更大，一些订阅者看到发送的通知显着下降。此问题的时间段为 2018 年 12 月 12 日凌晨 2 点至 2018 年 12 月 13 日下午 6 点（太平洋标准时间）。

我们要做的事情：

  1. 我们正在调查根本原因，并将采取措施防止这种情况在未来发生。

  2. 我们认识到我们缺少 Graph 通知的中断通信。我们正在努力改进我们的通信，目标是在我们意识到服务退化信息发生后立即主动向我们的客户发布服务退化信息。

感谢您使用 Graph 和我们的 webhook 通知框架。抱歉给您添麻烦了！

于 2018-12-14T19:46:27.133 回答