使用实时源生成交互式Microsoft Graph 应用
本文介绍依赖于 Microsoft 365 电子邮件服务数据和功能的业务方案的常见 Microsoft Graph 集成模式。 它使用 Microsoft Graph API 通过 WebSocket 通道使用 Webhook 读取数据、调用电子邮件操作和接收Microsoft Graph 更改通知。 此方案具有以下体系结构要求：
- 应用程序集成类型。
- Microsoft 365 与应用之间的双向数据流。
- 为单个用户提供服务时，数据量较低。
- 推送通知可接受的中等数据延迟。
此模式使用多个 Microsoft Graph 集成选项，包括 API、更改通知以及（可选）更改跟踪 API。 为了通过 WebSocket 接收更改通知，应用使用 SignalR SDK，它抽象化并简化了 WebSocket 管理。
下图显示了此解决方案的体系结构。
解决方案组件
解决方案体系结构包括以下组件：
- Microsoft Entra ID，这是管理Microsoft Graph API 的身份验证所必需的，并支持启用 OAuth 流的委托权限和应用程序权限。
- Microsoft Graph 通知服务，用于管理通知订阅并将更改通知传递到客户端应用。
- Microsoft通过单个终结点访问的 Graph RESTful API：
https://graph.microsoft.com。 - 实现自定义逻辑和 Webhook 并与 Microsoft Graph 通信的自定义移动应用。
注意事项
以下注意事项支持使用此集成模式：
可用性：自定义应用应在边缘设备上高度可用，并且当可靠的 Internet 连接不可用时，该应用可以支持脱机模式。
延迟：Microsoft Graph RESTful HTTP API 通常在一秒内响应，但总体延迟取决于 Internet 连接速度。 Microsoft Graph 通知在更改后几秒钟内生成，但其传递取决于 Internet 连接、移动供应商 SLA 和 Webhook 可用性。
可伸缩性：Microsoft Graph 服务具有高度可缩放性、异地分布性，并支持数百万个客户端的请求和通知。
解决方案复杂性：此解决方案需要自定义代码来协调 API、维护通知订阅以及通过 Webhook 接收更改通知。 尽管此解决方案不需要弹性，但它需要支持不同网络条件下的用户，并可能处理突发的更改通知。 因此，此解决方案非常复杂。