使用 Microsoft Graph API 生成交互式应用
本文介绍业务场景的常见 Microsoft Graph 集成模式，该方案需要一个可以实时创建、更新和管理通道消息的 UI。 此方案取决于Microsoft 365 服务，例如从不同团队发送和接收消息。
此方案具有以下体系结构要求：
- 应用程序集成类型，因为它依赖于复杂的 Microsoft 365 功能。
- 应用与 Microsoft 365 之间的双向数据流。
- 与基于单个人工干预的自动化系统相比，数据量较低。 但是，根据用户的数量，数据量可能很高。
- 应用上的实时数据操作，具有一些异步服务器端操作，例如将电子邮件传递到远程客户端。
此应用程序的最佳选择是使用 Microsoft Graph RESTful HTTP API。 客户端应用响应用户操作，并且可以以客户端环境控制的速度发出请求和处理数据。
下图显示了此解决方案的体系结构。
解决方案组件
解决方案体系结构包括以下组件：
- Azure 应用服务，它允许你以首选编程语言生成和托管 Web 应用、移动后端和 RESTful API，而无需管理基础结构。 它提供自动缩放和高可用性，支持 Windows 和 Linux，并支持从 GitHub、Azure DevOps 或任何 Git 存储库进行自动部署。
- 需要Microsoft Entra ID来管理Microsoft Graph API 的身份验证，并支持委派权限和应用程序权限才能启用 OAuth 流。
- SQL 数据库用于存储应用程序数据和状态;此组件是可选的。
- Microsoft图形 RESTful API，通过单个终结点访问：
https://graph.microsoft.com。 - 实现自定义逻辑的应用。
注意事项
以下注意事项支持使用此集成模式：
可用性：客户端应用定期Microsoft Graph API 轮询数据。 客户端应用可以发出请求并按客户端环境控制的速度处理数据。
延迟：客户端应用Microsoft图形 API 实时查询数据;但是，可能会有一些延迟，具体取决于网络条件和Microsoft Graph 服务的负载。
可伸缩性：客户端应用可以通过向App 服务计划添加更多实例来水平缩放。 Microsoft Graph API 可以处理大量请求，但它们也有用于防止滥用的限制和策略。 客户端应用应实现重试逻辑和指数退避，以正常处理限制错误。
解决方案复杂性：尽管此解决方案可能使用 Microsoft Graph SDK，但仍需要自定义代码来轮询和处理数据。 如果数据量很大，顺序处理可能不够，可能需要并行处理。 因此，此解决方案具有中等级别的复杂性。