Microsoft Power Platform 让您能够使用 REST API 扩展 Power Apps 画布应用程序的功能。 当处理复杂的算法或很多数据源时，将逻辑从画布应用转移到 RESTful API 是一个很好的选择，可以帮助保持 Power Apps 画布应用程序中的公式简单，同时将更复杂的功能转移到服务器端。 Power Platform 自定义连接器允许画布应用像使用其他数据源一样使用 REST API。
小费
本文提供了一个示例场景和可视化表示，说明如何使用 REST API 扩展画布应用的功能。 该解决方案是一个通用的示例场景架构，可用于许多不同的场景和行业。
体系结构示意图
Workflow
- 画布应用：Power Apps 画布应用使用自定义连接器访问 Azure Function 公开的操作。 用户使用 Entra ID 对应用程序进行身份验证，并且对数据的访问仅限于用户有权访问的数据。
- 自定义连接器：自定义连接器描述应用程序可以从 REST API（在示例中由 Azure Function 实现）使用哪些操作。 通过使用自定义连接器，Power Apps 画布应用程序能够像使用任何其他数据源一样使用该逻辑。
- Microsoft Entra ID 应用：使用 Microsoft Entra ID 应用保护 Azure Function。 将在自定义连接器上注册并配置第二个 Microsoft Entra ID 应用，以允许 Power Apps 画布应用访问 Azure Function 操作。
- Azure Function：Azure Function 实现 RESTful API，通过从 Azure 门户导出自定义连接器或手动配置，提供向 Power Apps 画布应用程序公开的一个或多个操作。 Azure Function 通过 Entra ID 应用注册获得保护，以确保只有授权的呼叫者能够访问。
- Azure Cosmos DB：Azure Function 可以使用 Azure Cosmos DB 或 Azure SQL 或管理数据所需的任何其他云数据存储。 事实上，由于逻辑的复杂性，该函数可以在 Microsoft Dataverse 中使用函数方法处理数据。
组件
- Power Platform 环境：包含实现店内应用用户体验的 Power Platform 资源，如 Power Apps。 这些资源使用 Dataverse 解决方案从一个环境移动到另一个环境（例如，从开发到测试）。
- Power Apps：Power Apps 用于实现解决方案的用户体验。 制作者可以使用 Azure Function 开发人员创建的自定义连接器作为应用程序数据源来构建应用程序。
- 自定义连接器：Power Platform 自定义连接器描述 RESTful API 的操作和数据结构。 它们允许从 Power Apps 画布应用程序等资源轻松使用 API。 从 Power Apps 使用时，它们允许像任何其他数据源一样引用 API。
方案详细信息
Power Apps 允许组织创建自定义用户体验，通过使用 REST API，业务逻辑将集中化，由应用程序使用自定义连接器进行访问。 此方法还可以允许 Power Apps 应用程序充当多个后端服务的集成商，为用户提供来自所有来源的数据和逻辑的单一视图。 使用 REST API 方法，您还可以将与多个其他系统交互的复杂性转变为实现 REST API 的组件，并简化画布应用程序的实现，同时仍然提供相同的用户体验。
在上面的示例中，商店内应用是使用 Power Apps 画布应用程序创建的。 该应用程序允许商店员工在商品缺货时快速保存客户的缺货通知请求。 该应用程序使用在描述后端 Azure Function 操作的自定义连接器上配置的单个操作 RecordBackorder。 在此示例中，Azure 函数是 REST API 的实现。 您可以使用任何允许创建 RESTful 服务的技术来实现此模式。
此体系结构提供了灵活性，但也意味着需要更多的代码优先开发人员工作来开发和维护 RESTful 服务和数据层。 通常，随着画布应用公式复杂性的增加，您应该考虑这种类型的体系结构。 例如，当需要多个数据源来构建单个视图时，使用 API 层可以帮助提供高性能体验，因为数据响应可以在服务器端进行调整并更高效地传递到客户端。 使用这个中间层意味着您可以添加服务器端缓存层并为应用实现更丰富的遥测。
注意事项
这些注意事项实现了架构良好的 Power Platform 支柱，这是一组可提高工作负荷质量的指导原则。 在架构良好的 Microsoft Power Platform 中了解详细信息。
可靠性
设计工作负荷以避免不必要的复杂性 – 通过自定义连接器从 Power Apps 应用程序使用 REST API 方法论可以避免不必要的复杂性，并将逻辑集中在组织中其他应用程序可以使用的地方。 自定义连接器让 Power Apps maker 能够像任何其他数据源操作一样使用 RESTFul API 中的操作。
测试复原能力和可用性 – 通过将逻辑从画布应用转移到 REST API，您应该能够独立于使用它的应用来独立测试 API。
度量和发布运行状况指标 – 应从 REST API 组件捕获遥测数据来跟踪其运行状况。 例如，使用 Azure Monitor – Application Insights 记录将确保对组件进行充分跟踪。
安全组
创建有意图的细分和边界 – 确保应用程序使用单独的 Power Platform 环境来支持您的应用程序生命周期阶段，并确保只有合适的用户有权访问每个阶段，可以支持您的细分策略。 注册的 Entra ID 应用在环境之间是独立的，以保持对每个数据阶段的保护，而不会在不同环境间混淆数据，这同样重要。
卓越运营
采用安全部署实践 - 使用自动化部署流程（如管道）标准化对 Power Apps 应用程序的任何更改的部署。 仅在测试更改后将应用程序提升到生产环境。
实施部署失败缓解策略 – 由于应用程序和 REST API 之间存在依赖关系，因此您应该确保您有一个经过测试的策略，来缓解其中一个组件更新后出现错误的推出。
性能效率
进行设计以满足性能要求 – 评估解决方案性能和数据量要求。 评估应包括如何访问数据，以及评估直接使用不同数据源的 Power Apps 可能过于频繁地与数据源通信的程度。 由于发送到每个数据存储的单个请求的延迟，这可能会造成性能下降。 例如，如果应用程序的逻辑在数据源中的大量行中运行，有可以可以将所有网络流量转移到后端 Azure Function。 减少到与 REST API 的单一交互，而 REST API 又将管理与多个其他数据源的交互，从而可以更有效地完成交互。
优化逻辑 – 随着逻辑在画布应用、Azure Functions 或类似的后端 RESTful API 实现中变得更加复杂，可以将该逻辑卸载到集中式可重用服务中。 使用自定义连接器功能来描述这些 RESTful API，允许画布应用像任何其他数据源一样使用配置的操作。
测试性能 – 除了测试功能和故障外，如果 API 对工作完成时间的变化敏感，测试和开发性能基线并将其作为发布周期的一部分进行评估也很重要。
体验优化
针对效率进行设计 – 允许用户从单个 Power Apps 应用程序访问多个数据源而无需他们与多个单独应用程序交互的应用程序正在提高用户的效率，并且很好地利用了自定义程度更高的视觉体验。
参与者
Microsoft 维护这篇文章。 以下贡献者撰写了本文。
主要作者：
- Mehdi Slaoui Andaloussi，首席工程经理