使用 Power Platform 实现应用程序现代化

在当今快速发展的数字环境中，组织面临着对其传统应用程序进行现代化改造以跟上不断变化的业务需求的持续挑战。 应用程序现代化对于提高运营效率、增强客户体验和在竞争中保持领先地位至关重要。 Microsoft Power Platform 提供一套全面的工具和技术，使企业能够快速有效地改造和现代化其应用程序。

本文探讨使用 Microsoft Power Platform 将应用程序现代化的好处、策略和最佳做法。 它提供了有关 Microsoft 低代码平台如何帮助您确保应用程序现代化工作取得成功的见解和指导，作为组织数字化转型的一部分。

简介

遗留应用程序给组织带来了许多挑战。 这些应用程序通常建立在过时的技术堆栈和框架上，因此难以与现代系统和工具集成。 它们通常具有可伸缩性和性能限制，阻碍了组织处理不断增加的工作负载和客户需求的能力。 传统应用程序缺乏灵活性和敏捷性，限制了它们快速适应不断变化的业务需求和市场动态的能力。 安全漏洞、高昂的维护成本、有限的集成能力以及依赖供应商的风险进一步加剧了遗留应用程序的挑战。 为了克服这些问题，组织需要对其应用程序基础架构进行现代化改造，以利用新技术。

Microsoft Power Platform 的低代码开发能力使得比以往任何时候都更快、更经济地构建和部署现代应用成为可能。 轻松集成现有系统和数据源，实现无缝数据交换和协作。 添加人工智能以增强用户体验、自动执行流程并从数据中获得有价值的见解。 无论您是在边缘修修补补的平民开发人员，还是从事复杂定制的专业开发人员，您都可以直观、快速、以比传统方法更低的成本推动数字化转型。

为什么选择 Power Platform？

构成 Power Platform 的综合工具和技术大大降低了现代化和数字化转型项目的时间、成本和开发要求。 它的低代码方法可以减少甚至消除对昂贵的编码、数据科学和 AI 工程资源的需求。 平民开发者和专业开发者都从中受益。 公民开发人员可以在现代化过程中发挥积极作用，根据自己的领域专长直接构建应用程序，减少对 IT 团队的依赖。 专业开发人员可以在更短的时间内交付复杂的解决方案，从而更快地进入下一个项目。

Power Platform 产品和概念

Power Platform 系列的每个产品都有其独特的重点领域。 组织可以单独或组合实施产品，以满足其特定要求。 这些产品是相互关联的，形成一个无缝的整体，无论它们是如何组合在一起的。

下表提供了每个 Power Platform 产品的高级概述。

Power Platform 产品系列依赖于一些辅助功能和概念。 下表描述了需要了解的最重要的内容。

使用 Power Platform 实现应用现代化的主要优势

使用 Microsoft Power Platform 对应用程序进行现代化的好处不仅仅是拥有一个使用现代技术的解决方案的初始商业价值。

• 降低成本。 组织可以在应用程序开发和维护上节省资金。 Forrester Consulting 委托进行的一项研究发现，使用 Power Platform 的企业可将应用程序开发成本降低 45%，并实现 140% 的投资回报。

• 扩展资源池并消除瓶颈。 专业开发人员、数据科学家和 AI 工程师的薪水很高，而且需求量很大。 中小型组织通常没有内部编码专业知识，而且外包成本高昂。 低代码 Power Platform 更容易被更多资源所接受。 主题专家和具有业务流程专业知识的员工可以帮助加快现代化工作，即使他们从未编写过一行代码。

• 建造推车，而不是轮子。 传统的软件开发每次都从头开始，每个新项目都会重新发明轮子。 有了低代码、直观、便于制作的 Power Platform 产品作为您的车轮，您就可以专注于打造更好的汽车 - 改进您的业务流程 - 并更快地享受现代化努力带来的收益。

• 减少技术债务。 升级“快速而肮脏”的软件解决方案和维护遗留基础设施的成本（无论是在财务上还是在失去机会方面）都很高。 Power Platform 通过以下方式减少技术债务：第一次就能更轻松、更经济地构建正确的解决方案；使用通用数据模型和连接器简化数据集成和治理；提供用于管理解决方案的集中式平台；以及利用分析和人工智能支持持续改进。

• 增强安全性并确保合规性。 所有 Power Platform 产品均包括开箱即用的全面集成的企业级安全性、合规性和治理功能，并从其运行环境开始。 托管环境是一套工具，可让管理员以更强的控制力和更少的工作量大规模管理 Power Platform。 除其他功能外，还可以限制谁可以共享哪些流和应用以及与谁共享，并使用策略来限制制作者可以使用的连接器。 原生、灵活的数据安全模型意味着每个应用程序都无需自行构建。

• 边运行边现代化。 您想要现代化的应用程序越重要，您想要一次替换它们的可能性就越小。 低代码方法非常适合以可管理的增量构建解决方案。

• 整合传统应用程序。 较旧的应用程序通常没有 API。 Power Platform 的 RPA 功能可将传统应用程序自动化，并将其纳入新的现代化业务流程。 RPA 还有助于逐步实现大型复杂应用的现代化。

• 在不花更多钱的情况下进行创新。 Power Platform 的功能还在不断改进。 在平台上构建的应用程序受益于 Microsoft 创新，而无需您花费更多成本。

• 在现代工作场所提高员工的工作效率。 Power Platform 是 Microsoft 现代工作场所的一部分。 在该平台上实现现代化的应用程序可以利用 Microsoft 365 的功能，包括引人入胜的移动体验和简单直观的协作。 Copilot、AI Builder 等尖端人工智能以及即将发布的功能使用户和开发人员的工作效率更高，挫折感更少，学习曲线更浅。

面向一线员工的创新

一线员工需要现代化的应用程序，他们可以在任何设备上使用，无论他们在哪里工作。 他们需要实时访问见解，以便更快地做出更好的决策。 他们需要与同事和管理层合作，以保持一切顺利进行。 当美国航空公司决定对其运营的各个方面进行现代化改造时，他们得到了所有这些以及更多。

美国航空公司与 Microsoft 合作创建了基于 Power Apps 和 Azure 的 Microsoft Teams 应用程序 ConnectMe。 在任何移动设备上使用该应用程序，一线团队可以实时获得关键的到达、登机、行李和登机口信息，从而简化地面操作，加快飞机周转时间，并为客户提供更愉快的旅行体验。 了解航空公司转型的更多信息

增强知识工作者的人工智能能力

知识工作者在数据的海洋中游泳，而且很多时候，他们都觉得自己快要溺水了。 几乎所有应用程序都会收集数据。 它们很少能帮助用户理解所收集的数据，更不用说提出有助于更好地开展工作的见解了。 作为现代化的一部分，可以将 AI 功能添加到应用程序中，不仅可以自动收集和分析数据，还可以使知识工作者更容易发现模式和趋势。 预测分析可以使用 AI 模型根据历史数据高精度预测未来结果，让领导者充满信心地进行规划。 现代化的应用程序可以包括助手 AI，充当合作伙伴在上下文中生成内容——总结访谈、起草有针对性的营销和销售信息，甚至在客户服务代表或销售人员与客户通电话时实时提供有用的信息。

对旧应用进行现代化改造的增量之旅

如果您的组织与大多数组织一样，则积压的过时应用程序将不断增加，而这些应用程序将从现代化中受益。 遗留应用程序通常使用过时的技术，并且基于不再受支持的基础结构（硬件和软件）构建。 通常，只有少数员工（通常是即将退休的员工）知道他们的工作方式。 新员工不想与他们有任何关系，因为他们无法使用他们习惯或想要使用的现代工具。 维护它们，更不用说更新它们了，需要积累大量的技术债务，而且你爬得越多，技术债务就越高。 数年甚至数十年的拼凑维护导致代码库无人敢触碰，尤其是当业务的主要部分依赖它时。

组织通常无法轻松地一次性替换这些应用程序。 取而代之的是，他们踏上了渐进式的现代化之旅。 渐进式方法可以最大限度地发挥现代化的好处，同时降低一次性现代化工作的一些风险。

应用现代化的选项

现代化并不总是意味着从头开始重建遗留应用。 其他选项包括停用、替换、重新托管、重构和重新架构。

下表描述了每个选项、最合适的 ALM 阶段以及可能影响其选择的驱动因素。

下表建议了将低代码方法应用于每个应用现代化选项的方法。

Power Platform 的低代码方法有可能提供的不仅仅是另一种开发工具。 将低代码作为现代应用策略的一部分，还可以为授权非开发人员（如主题专家）参与现代化工作奠定基础。 各组织发现，围绕 Power Platform 建立卓越中心 (CoE) 并使用 CoE 入门套件等工具来创建指南和管理，有助于用户成功构建低代码应用程序和自动化，并确保 API 和组件等资产可以重复使用。 低代码可以加速应用程序开发，并帮助组织更快地从数据中提取价值，无论数据位于何处。 事实上，许多组织决定将低代码思维方式整合到他们的文化中。

现代化之旅指南

当您开始考虑对旧版应用进行现代化改造时，很容易感到不知所措。 指南可以帮助您计划您的旅程，并让您一路走在正确的道路上。 一个好的起点是从这三个步骤开始，以低代码的思维方式考虑每个步骤。

1. 规划。 仔细考虑对遗留应用程序进行现代化改造的目标，并定义实现这些目标的策略。 清楚地说明您希望现代化解决的问题。 现在是对应用程序和环境进行评估的时候了，评估时应关注哪些地方不起作用，哪些地方虽然起作用但可以改进，以及最重要的一点，即任何改变都会给业务或用户带来哪些价值。 评估每个现代化机会，了解其利用低代码方法的潜力。 优先考虑采用低代码解决方案的商机。 使用云采用战略评估工具，为应用程序现代化建立业务案例。

2. 实现。 不仅以增量方式，而且以迭代方式对应用进行现代化改造。 迭代方法使组织能够根据需要灵活地更改其项目范围或策略。 Power Platform 与传统开发的应用程序相比，低代码解决方案的开发和测试速度更快，在托管环境中部署只需几个步骤。 虽然与传统编码相比，低代码需要更少的技能提升，但请确保您的员工接受过适当的培训，了解如何作为融合团队工作，融合低代码和传统资源。

3. 操作。 应用现代化并不止于实施。 借助低代码、云优先的方法，您可以使用云平台服务和工具来保护、治理、管理和优化应用。

评估低代码解决方案的机会

组织使用各种方法（从非正式审查到详细决策树）来确定低代码方法是否是实现旧应用现代化的正确方法。 要考虑的最重要的事情是，低代码不是一个全有或全无的决定。 用 Power Platform 组件构建应用程序的一部分和用传统编码技术开发的组件构建应用程序的一部分是很常见的。

若要评估应用程序，建议您首先确定它是否仍然需要和有用，或者是否应停用。 如果决定仍需要它，请评估低代码解决方案是否可以替换整个应用。 如果整个应用不适合低代码替换，请评估应用的一个或多个工作负载或组件是否适合。 您可能会发现，使用传统开发的代码扩展的低代码解决方案提供了两全其美的效果。

例如，如果因为 Power Apps 缺少一个必要的控件而导致应用程序不合适，您可以使用 Power Apps component framework (PCF) 和传统代码来创建自定义控件。 另一个示例是具有复杂逻辑的应用。 您还可以将逻辑集中到 API 中，Power Apps 可以使用自定义连接器访问该 API。 在这两个示例中，Power Platform 的可扩展性允许使用低代码组件构建大部分应用程序，弥补了与传统开发代码之间的差距。

NSure.com，一个专有的在线保险购物平台，提供了一个真实的例子。 该公司的最初发布依赖于传统开发的 Angular、Xamarin 和 Azure 服务。 通过添加 Power Platform 和 Dynamics 365，NSure.com 利用低代码和传统编码技术创建了下一代解决方案，如下图所示。 进一步了解公司的发展历程。

与识别低代码机会同样重要的是识别低代码方法何时不是正确的。 下表描述了通常不适合低代码解决方案的用例。 组织在前端和后端面临不同的挑战，因此让我们分别考虑它们。

不适合低代码方法的前端方案

不适合低代码方法的后端方案

我们建议紧跟 Power Platform 发布浪潮，因为它们不断缩小低代码解决方案的差距。 创建低代码概念验证是确定您的方案是否适合的好方法。

优先考虑低代码机会

在评估应用程序组合时，仅仅确定适合低代码转换的候选者是不够的。 您的团队必须对它们进行优先级排序，以最大限度地提高现代化工作的成功率。

确定优先级时应考虑以下因素：

• 组织的低代码成熟度
• 机会的复杂性
• 组织、用户和 IT 的投资回报率
• 实现价值的时间

对组织的低代码功能保持现实态度可以帮助您选择一个挑战团队成长的机会，但不会让他们不知所措地失败。 您不必毫无挑战地选择最直接的应用程序。 理想的方法是提供一些机会来探索如何将传统代码与低代码解决方案相结合。

与其他系统复杂集成的应用程序通常不是最佳起点。 尝试处理太大或太复杂的应用程序可能会导致挫败感和失败。 避免任何有问题的低代码候选项目。 留待团队成功完成几次现代化后再考虑。

在对大型整体式应用进行现代化改造时，请考虑是否可以以增量方式对其小部分进行现代化改造。 单体式应用程序过去很常见。 现在，以角色或任务为中心的小型应用更为常见。 它们允许增量开发和增强，并允许构建它们的团队进行扩展。

前几项现代化很重要，因为它们让组织看到了低代码解决方案的影响。 在确定商机的优先级时，评估应用利益干系人的好处和风险非常重要。 选择一个没人关心或对组织影响很小的应用程序并不能最好地展示低代码解决方案的优势。

用户采用现代化应用程序非常重要。 用户需要感觉到他们的新低代码应用程序适合他们使用的其他应用程序。 采用的另一个风险是他们习惯的定制程度。 如果他们期望获得高度定制的体验，他们可能不太倾向于采用感觉不那么个性化的低代码解决方案。

组织和提升团队技能

成功实现遗留应用现代化的组织不只是将现代化项目分配给传统代码开发人员团队，并希望他们成功。 为您的团队提供成功完成现代化工作所需的低代码开发知识和信心非常重要。

与传统代码资源一起工作的低代码资源团队称为融合团队。 融合团队旨在通过培训两种类型的资源来鼓励协作，以将低代码解决方案与传统代码集成。 解决方案架构师确定如何在低代码和传统代码之间构建解决方案。

虽然默认将所有工作分配给传统开发人员很容易，但低代码现代化工作是扩展项目团队的好机会。 许多业务用户提供了出色的低代码资源。 他们可以加快团队的工作速度，因为他们已经了解业务问题。 他们只需要学习如何完成团队承担的低代码工作类型，并熟悉测试和 ALM 过程。 这可能意味着要学习如何在 Power Apps 中构建应用程序或在 Power Automate 中构建工作流。 他们还应该了解传统编码人员可以开发什么来简化他们的低代码工作。 这并不意味着他们需要知道如何编写传统代码。

传统的代码资源需要对低代码方法有基本的了解，以及这些方法与它们通常编写的代码有何不同。 最重要的是，他们需要学习低代码解决方案的扩展性选项。 他们应该能够轻松地创建测试应用或流，该应用或流使用他们自己编写的代码来确保其正常工作，并准备好支持低代码资源来使用其可扩展性资产。

低代码和传统代码资源都需要了解低代码和传统代码解决方案的起点和终点以及它们的交叉点。

收集需求

您可能会发现您的应用已超过十年或更久，且未记录在案。 它们可能需要逆向工程或业务用户知识才能重新创建。 重要的是要记住，虽然低代码方法很有效，但它不会更快地收集需求和业务流程知识，也不会降低复杂需求的复杂性。 通常，人们有一种不切实际的期望，即对应用进行现代化改造的团队与使用低代码构建新应用的团队所取得的成就一样多。 在确定组织的期望时要牢记这些挑战。

两种方法可以帮助加快获取旧版应用知识的速度。 首先，扩大团队，以包括具有领域知识的业务用户。 其次，专注于了解业务流程及其预期结果，而不是记录如何在遗留系统中实现它。 例外情况是，如果旧版应用程序需要执行您必须遵循的业务规则的专用逻辑。

避免与低代码方法对立

不熟悉使用低代码解决方案对应用程序进行现代化改造的组织经常会犯一个错误，即以与开发传统代码相同的方式开发低代码。 例如，一个组织可能会将为 Angular 应用程序编写的用户体验标准应用到其首个 Power Apps 实施中。 项目团队将花费不必要的时间试图满足为 Angular 框架功能而不是业务需求而设计的标准。

习惯于使用传统代码的团队可能会尝试最小化低代码。 例如，团队可以不使用 Power Apps 控件，而是使用 Power Apps component framework 控件来构建应用程序，以尽可能避免使用低代码。 对于团队来说，最好使用低代码尽可能地走得更远，直到他们遇到无法解决的障碍。 学习如何利用平台功能的团队可以更成功地实现低代码的最大优势。 低代码继续变得更有能力承担过去只有传统代码才能实现的功能。 过去的一个常见挑战是卡住，因为低代码无法复制一些需要的功能。 Power Platform 通过可扩展性选项解决了这一难题，允许大部分低代码应用程序在必要时加入用传统代码编写的专用组件。

低代码方法可以在您的现代化战略中发挥重要作用。 最好的结果需要清楚地说明现代化工作旨在解决的问题、规划、超越默认角色的人员配备、培训和优先级。 如果需要，对其标准和流程进行适当的调整也有助于组织实现低代码的全部潜力。 正确完成的现代化应该可以提高现代化应用程序的整体业务价值。

近年来，低代码平台发展迅速。 虽然他们一直擅长支持个人生产力场景，但最近的重点是企业功能。 组织正在构建支持现代工作场所的低代码应用程序，包括混合工作（远程和现场）以及随之而来的鼓励协作方式的需求。 Power Platform 等低代码平台现在可以扩展到处理企业中所有用户都可以依赖的应用程序，并且可以集成到企业安全模型中。 通过将低代码功能连接到企业基础架构，您可以将低代码技术与传统方法并行使用。 低代码抽象了大部分复杂性，并允许更广泛的人参与构建解决方案。

了解低代码方法的成本结构

组织在考虑现代化工作时会问的一个常见问题是，它的成本是多少？ 虽然对许可和成本分析的完整讨论超出了本文的范围，但我们可以在高层次上探讨这些主题。

Power Platform 产品是授权产品。 您可以单独许可它们以满足您的要求。 您可以将 Azure 计费配置为“即用即付”，这样就可以在没有预先许可承诺或购买的情况下使用，并包括一些应用程序内 Power Automate 使用。 Power Automate 也有针对独立工作的按用户和按流许可。 当您拥有使整个组织受益的自动化时，每流许可非常有效。 Power Apps 许可能够按用户或按应用程序授予。 Power Pages 站点按用户、站点或月授权。 经过身份验证的站点需要其他许可证。 所有许可证都包括使用连接器和 Dataverse，并可选择为大容量方案授权更多存储和 API 请求。

所有 Power Platform 产品都有批量定价，通常适用于应用现代化工作，必须根据每个组织的独特战略进行评估。

在评估低代码与传统代码相比的成本时，必须认识到这种比较并不是同类之间的比较。 使用低代码时，您需要支付在低代码产品中实现独特业务流程的人工费用以及使用该流程的产品许可证费用。 通常，许可证包括多个应用程序和自动化，每个应用程序和自动化都不需要更多成本。

使用传统的编码方法时，您需要支付在代码中实现独特业务流程的人工、构建应用基础结构的人工以及支持应用所需的云服务。

所有解决方案，无论是低代码还是传统代码，都需要持续的维护和保养。 但是，低代码解决方案需要更少的资源来执行此操作。 它们产生的技术债务也较少，因为应用程序基础设施由平台提供。

与非基于低代码平台构建的完全自定义应用程序相比，低代码解决方案的成本更可预测。 避免陷入将低代码许可与传统代码部署的初始成本进行比较的陷阱。

Power Platform 内部一览

Power Platform 组件建立在与使用传统编码方法相同的 Microsoft Azure 云服务上。 这些组件彼此之间以及与安全性、可伸缩性和灾难恢复功能的集成已经为您完成。

Dataverse 内部

Dataverse 由超过 25 种完全托管的 Azure 服务提供支持，如 Functions、Load Balancer、认知服务、Synapse、DevOps、Active Directory 和 Microsoft Purview。 内置功能包括全面的安全性、强大的分析功能、人工智能、高级业务逻辑和事件处理、数据建模以及与 Dynamics 365、Microsoft 365、Azure 等的集成。 所有这些功能都建立在一个多元 Dataverse 存储层上，该存储层基于 Azure SQL DB（用于关系型数据）、Azure Cosmos DB（用于 NoSQL）、Azure Blob Storage（用于文件）和 Azure Data Lake Storage Gen 2（用于大规模分析和长期数据保留）。 它们可在 Power Platform 的低代码组件中透明使用，也可通过 Dataverse REST API 使用。

高可用性、业务连续性和灾难恢复（BCDR）对于业务关键型应用程序非常重要。 Dataverse 通过 Azure 可靠性服务最大限度地提高了可用性。 主服务器和辅助服务器的复制是同步的，下面有一个结构，可以检测故障并按照正确性协议选择新的主服务器。 高可用性故障切换发生在 Azure 区域内，是无缝的，用户很少会注意到，通常只需几秒钟即可完成。 无论中断是计划内还是计划外，它们都能保证零数据丢失。

灾难恢复故障切换发生在两个 Azure 区域之间。 为确保更快的故障转移和最小的数据丢失，使用异步复制来维护灾难恢复连续副本。 计划的故障转移不会造成数据丢失，对于生产环境，通常可以在几秒钟或几分钟内完成。

除了高可用性和 BCDR 的技术实现外，运营团队还会定期测试其响应各种类型事件的准备情况。

Power Automate 内部

Power Automate 云端流建立在 Azure Logic Apps 之上。 Power Automate 提供抽象并与 Power Apps 等其他低代码组件集成，同时使用 Logic Apps 运行时引擎。 熟悉 Logic Apps 的开发人员会发现 Power Automate 使用了类似的概念，包括表达式语言。

Power Apps 内部

Power Apps 运行时引擎基于 React 框架。 应用程序在 Power Apps 设计器中构建，设计器使用拖放界面来构建屏幕。 Power Fx 公式实现逻辑。 连接器扩展了应用对其他服务的访问，以及允许可重用视觉对象扩展的逻辑和组件。 开发人员可以使用 Power Apps Component framework (PCF) 创建自定义控件。 虽然许多 UI 框架都可以与 PCF 一起使用，但 Power Apps 的特点是内置了对 React 的支持。

连接器内部

连接器使用 Azure API 管理来管理每个用户的凭据和连接。

所有连接器都使用相同的体系结构，包括您为自己的 API 创建的自定义连接器。 Azure API 管理的使用确保了 Power Platform 产品（如 Power Apps 和 Power Automate ）与所有连接器的接口一致。

但 Dataverse 连接器是个例外。 它显示在应用和流的连接器列表中，但实现方式不同。 当应用程序或流使用 Dataverse 数据或操作时，交互是通过 Dataverse 的 OData API 直接进行的。

Power Platform 扩展性选项

可扩展性是 Microsoft Power Platform 区别于其他低代码平台的一个关键特征。 该平台的一个指导原则是“没有悬崖”——你不应该被阻止使用低代码完成一些事情，即使它需要传统代码。 如有必要，可以使用传统代码将整个工作负荷生成为大型应用的一部分。 但是，该平台提供了许多可扩展性选项，允许在同一工作负载中一起使用低代码和传统代码。

下表提供了一些常见扩展性选项的高级概述。 稍后，当我们讨论如何实现现代化和可以应用的模式时，我们将再次提到其中的一些。

探索低代码现代化体系结构方案

与大多数平台一样，您可以使用 Power Platform 组件和其他微软云服务组成无穷无尽的架构方案。 在本文的这一部分中，我们将探讨一些更常见的场景，并讨论在使用它们时应牢记的一些注意事项。

应用体验

实现用户体验现代化可以对用户产生重大影响。 Power Apps 是使用 Power Platform 构建内部应用程序体验的主要方式。 您可以在内部网络应用程序中使用 Power Pages，但它在面向外部的应用程序中更为常见。

Power Apps

工作负载的设计应使用户无需切换应用即可完成大部分工作。 在对大型整体式应用程序进行现代化改造时，可以将其功能拆分为多个应用。 相反，如果用户需要使用多个应用，则可以将它们合并到单个应用中，该应用提供其多个数据源的统一视图。

下表介绍了可以使用 Power Apps 构建的两种应用程序类型：画布应用程序和模型驱动应用程序。

下图演示了画布应用或模型驱动应用的基本体系结构，其中应用直接连接到数据源。

若要最大程度地减少与数据源的直接连接，可以让应用使用指向 API 的自定义连接器，该连接器在数据源中执行任何必要的工作。 此方法允许您控制向低代码组件公开的操作，并可以抽象底层逻辑的复杂性。 下图演示了这种 API 优先的方法。

Power Apps 还可以直接运行 Power Automate 云端流，这些云端流可以将结果返回给应用程序，也可以异步运行。

将 Power Apps 与您的数据存储库或应用程序接口一起使用，可以使用户体验现代化，同时最大限度地减少对传统解决方案其他部分的干扰。 此方法还允许您将多个遗留系统连接到单个应用程序中，从而为用户提供一个完成工作的位置。

Power Pages

Power Pages 的主要数据源是 Dataverse。 在网站上添加页面时，页面定义存储在 Dataverse 中。 页面既可以显示 Dataverse 数据，也可以收集用户数据并存储在 Dataverse 表中。

您可以为匿名访问配置页面，也可以为内部用户配置使用 Microsoft Entra ID 的身份验证访问，或为外部用户配置身份提供程序。 当经过身份验证的用户访问数据时，只有他们有权访问的数据可用。

Power Pages 站点的常见应用是为外部用户提供对组织业务流程的自助访问。 内部用户可以使用 Power Apps 应用程序。 下图演示了这样的体系结构。

数据管理

应用程序现代化需要评估整个解决方案中使用的数据。 现代化应用程序具有多种处理数据的选项。 在许多情况下，多个应用程序使用相同的数据存储库。 将数据迁移到新存储库作为其中一个应用程序现代化的一部分变得很困难。 Power Platform 的核心原则是，数据可以在原处使用，也可以通过 Dataverse 或数据湖引入平台。

对于现代化应用程序的数据体系结构，您有以下选项：

• 将数据留在原处：使用连接器或带有自定义连接器的应用程序接口访问原处的数据。 当数据位于本地时，数据网关可以促进安全连接。 使用虚拟表将兼容的外部数据整合为 Dataverse 表。

• 迁移到 Dataverse：Dataverse 是事务数据和将多个数据源整合到单一记录系统中的好选择。 可使用 Power Query 和自动流从多个来源映射和迁移数据。 Dataverse 还支持弹性表，专为接收以非结构化或半结构化格式存储的大容量数据而设计。

• 迁移到数据湖：对于历史数据、分析数据或遥测数据，可使用数据湖。 数据湖中的数据可用于生成 Power BI 分析，或经处理后生成人工智能驱动的洞察力。

在评估现代化应用程序的数据体系结构选项时，请记住以下注意事项：

• 对其他应用的影响：虽然迁移到更高效的数据存储可能是某个应用的理想选择，但对使用数据的其他应用的初始影响可能过大。 一些企业考虑将数据留在旧数据存储中，并在 Dataverse 中创建新数据，随着更多应用的现代化而从旧存储中迁移。

• 对新应用的影响：将数据留在旧数据存储中虽然简单，但可能会对现代化应用的使用便利性产生负面影响。 较旧的数据存储可能无法与其他云服务很好地集成，从而更难将数据合并到新的整体体系结构中。

• 数据整合：作为应用现代化的一部分，识别没有明确所有权或责任的数据以确保其正确使用是很常见的。 通过整合 Dataverse 中的数据，企业可以改善对数据的管理，更好地确保数据的正确使用。

• 数据隐私和安全：您应根据当前需求和目标现代化架构来评估隐私和安全问题，而不仅仅是传统应用程序如何处理这些问题。 云解决方案在实施隐私和安全控制方面有更多选项。 通常，单个数据存储可以简化它们。 您还必须考虑如何在跨多个存储库拆分数据的混合应用程序中实施统一的数据安全性。

• 集成问题。 较旧的数据存储可能缺少允许访问所需的 API，而无需迁移数据或创建应用程序可与自定义连接器结合使用的 API。 应评估从旧数据存储到使用它的应用程序的连接，以确定性能是否可以接受。

您应为每个将要现代化的应用程序确定一个数据体系结构。 第一步是确立数据架构整合 Dataverse 的整体愿景。 如果目标是最大限度地发挥低代码的价值，那么就应该尽可能使用 Dataverse。 从一开始就有一个愿景可以帮助您避免传播更多的数据孤岛。

外部数据和 Dataverse

传统应用程序通常依赖于组织外部的数据，这些数据早在 Dataverse 之前就已存在。 这些应用程序的现代化并不需要复制 Dataverse 中的数据。 相反，您可以将数据表示为虚拟 Dataverse 表。 虚拟表可以参与与其他虚拟表以及本地表的关系。 现代化后的应用程序会看到一组统一的表，这些表似乎完全存在于 Dataverse 中。

虚拟表是使用数据提供程序体系结构实现的。 Dataverse 包含一个 OData 提供程序，可与 OData V4 网络服务一起使用。 目前还在预览阶段的虚拟连接器数据提供程序允许将表格 Power Platform 连接器用作虚拟表。

下图说明了虚拟连接器的使用。

开发人员还可以为其他外部数据源创建自定义提供程序。 不过，它们必须理解并实现所有 Dataverse 映射和操作支持。

以下注意事项可帮助您评估在现代化项目中使用虚拟表的情况：

• 所有外部数据源都必须有一个主键，数据提供者必须以 GUID 的形式将其呈现给 Dataverse。 如果填充值稳定且唯一，则可以使用填充来容纳非 GUID 键。
• 数据安全性在虚拟表级别配置。 行级和列级安全性不可用。
• 虚拟表的性能取决于数据提供程序、外部数据源 API 以及与数据源的连接。 在大多数情况下，虚拟表的访问速度比本地 Dataverse 表慢。
• 一些 Dataverse 功能，如搜索、审计、图表和仪表板以及离线访问，在虚拟表中不可用。
• 使用虚拟表作为参考数据可能会导致同步减少。

文件和图像

在对使用文件和图像的应用程序进行现代化改造时，请务必考虑新解决方案将存储它们的位置。 Dataverse 具有存储文件和图像的专门功能。 两者都可以作为列添加到表中，并存储在由 Dataverse 管理的 Azure Blob Storage 中。 应用程序可以使用 Dataverse 连接器处理它们，无需单独的身份验证或应用程序接口。

当文件和图像与数据有直接连接，且多个用户不需要对其进行协作时，将 Dataverse 用于文件和图像是合适的；例如，产品或地点的照片或法律合同的最终副本。 但是，如果多个用户需要同时修改法律合同，使用 SharePoint 将提供更强的协作能力。 如果需要与 Dataverse 分开管理安全性，或者需要使用某些特定文件功能，请考虑直接使用 Azure Blob Storage。

集成

应用程序现代化通常包括与内部或外部系统的集成。 集成可以大致分为数据、应用程序或流程。

• 数据集成将不同来源的数据结合起来，为用户提供统一的视图。 它提供了一种解耦的方法，但不允许实时构建逻辑或流程。 性能可以更好，因为所有数据都是本地的。

• 应用集成在应用层进行连接，通常通过应用程序接口（API）或低代码解决方案连接器完成。 应用程序级集成在两个解决方案之间提供了定义的边界，但在许多情况下也会产生实时依赖关系。 这种类型的集成还会创建一个安全边界，其中访问可以由提供 API 的系统控制。

• 流程集成连接多个不同的系统，每个系统都是整体业务流程的一部分。 这种类型的集成是最解耦的，允许参与的系统处理业务流程的每个部分。 在现代化方案中，使用低代码对现代化流程的一部分进行分区，并与仍由遗留系统处理的其他部分集成会很有帮助。

在评估如何实现集成时，重要的是不要认为旧方法最适合您正在现代化的应用程序。 例如，如果流程是实时和同步的，请考虑是否可以异步执行该流程。 在云解决方案中，同步集成可能更加脆弱。 例如，具有适当错误处理功能的低代码 Power Automate 流可以协调集成。 这种方法不仅可以提高可靠性，还可以提高用户的工作效率，因为他们不再需要等待集成完成。

以下注意事项可帮助您评估如何推进现有集成：

• 是否仍需要集成？ 发现没有人再使用集成的结果并且可以停用的情况并不少见。

• 如果现代化应用程序位于云中，是否存在连接挑战？ 挑战可能包括延迟和对本地 API 或数据存储的访问。 在某些情况下，本地数据网关可以帮助从云访问服务或数据。 如果对数据或服务的访问速度太慢，请考虑是否可以将数据设为现代化应用的本地数据，还是在后台执行集成。

集成还可以帮助调整现代化应用程序的规模。 您可以对旧应用程序的一个或多个部分进行分区，以保留或在单独的应用程序中实现。 当不同角色的用户使用旧版应用程序的不同部分时，此方法将非常有效。 您可以使用低代码实现一个或多个角色，并使用流程集成让现有应用程序处理流程的其余部分。 使用这种方法，您可以随着时间的推移逐步对其余部件进行现代化改造。 单独实施流程的独立部分还可以促进以更敏捷的方式推出独立于流程其他部分的增强功能。

在进行任何自定义集成之前，应评估 Power Apps 内置的集成功能。

• Microsoft Teams：Power Apps 画布应用程序和 Copilot Studio 代理可以嵌入 Teams 频道。 使用 Teams 连接器，应用和流可以轻松发布和使用 Teams 消息。 Power Apps 卡可以像微应用程序一样用于在 Teams 频道中共享可操作信息。

• SharePoint：Power Apps 模型驱动的应用程序可以配置为连接到存储在 SharePoint 库中的文档，以便在 Dataverse 行中提供这些文档。 通过 Microsoft 列表或 SharePoint 列表，用户可以在列表项的上下文中运行 Power Automate 流。

• Power BI：Power BI 见解可以在 Power Apps 画布应用程序的上下文中显示。 您可以在 Power BI 报告中嵌入模型驱动应用程序，让用户无需离开 Power BI 就能对洞察结果采取行动。

使用 Dataverse 作为现代化应用程序的主要数据存储库，可提供一些有助于集成的内置功能。

• Dataverse 自定义 API 可用于入站应用程序级集成。 自定义 API 提供与少量自定义代码逻辑关联的唯一操作。 例如，发送系统可以使用 RequestNewProject 自定义 API，相关的逻辑将知道如何把接收到的数据放入适当的 Dataverse 表中。 发送系统将从 Dataverse 表结构中抽象出来。

• 出站集成可以使用 Dataverse 的发布事件功能来完成。 可以将 Dataverse 配置为发布到 Azure 服务总线、Azure 事件集线器或任何 Webhook 接收器。 例如，创建新的 Dataverse 项目表行时，可将其发布到 Azure 服务总线队列。 您还可以发布与业务流程事件匹配的更多概念性事件。 例如，您可以在项目完成时定义和发布事件。

下图说明了 Dataverse 环境中入站和出站事件的示例。

企业还应考虑 Microsoft AppSource 上第三方提供的预建集成选项。 例如，Microsoft 为需要将 SAP 与 Power Platform 集成的组织提供了一个预建解决方案。 该预建解决方案包含应用程序和流，并增加了新的功能，可促进企业的 SAP 系统与 Power Platform 之间的通信。

例如，安永会计师事务所（Ernst & Young）使用预构建的 SAP 集成来快速开发解决方案，以优化高频全球财务流程。 下图是公司的 PowerPost 解决方案，显示了财务用户如何使用 Power Platform 将文档发布到总账 SAP ERP 系统。

集成连接选项

随着解决方案迁移到云，与本地资源的连接对于确保集成仍适用于现代化应用程序至关重要。 这些应用程序还必须能够与可能驻留在不同网络环境中的其他传统云资源集成。 Power Platform 支持四种主要的安全连接选项：数据网关、虚拟网络数据网关、专用链接和 ExpressRoute。

• 数据网关允许 Power Apps、Power Automate 和 Power BI 的低代码组件返回到内部资源，以支持混合集成方案。 网关为现代化的低代码应用程序提供了一种快速访问仍在本地的数据源的方法。 通过网关，您可以从本地文件系统、DB2、Oracle、SAP ERP、SQL Server 和 SharePoint 等来源连接到内部部署数据。 一个网关可以支持多个用户并访问多个源。 您还可以将数据网关配置为集群，以提供高可用性。

  网关支持已集成到连接器的连接流程中，允许在需要网关时进行指示，并选择已配置的网关。 连接配置完成后，应用程序和数据流可以像没有网关一样使用连接器。

  

• 虚拟网络数据网关允许 Power BI 和 Power Platform 数据流连接到 Azure 虚拟网络中的数据服务，而无需在虚拟网络内部的虚拟机上安装内部数据网关。

• Azure 专用链接和 Azure 网络专用端点允许应用程序和流安全地访问 Power BI。 专用终结点用于使用 Microsoft 的主干网络基础结构私下发送数据流量，而不是通过 Internet。 专用端点可确保进入企业 Power BI 资源（如报告或工作区）的流量始终遵循企业配置的专用链接网络路径。

• Azure ExpressRoute 提供了一种先进的方式，使用专用连接将企业内部网络连接到 Microsoft 云服务。 单个 ExpressRoute 连接可访问多个在线服务，如 Power Platform、Dynamics 365、Microsoft 365 和 Azure 云服务，而无需穿越公共互联网。 ExpressRoute 需要大量的规划和配置，并且 ExpressRoute 服务和连接提供商的成本更高。

无论您使用哪种方法进行集成连接，都应评估连接，以确保其具有足够低的延迟和足够的带宽来支持您的集成和现代化应用程序。

业务逻辑

在构建现代应用程序时，您可以选择使用什么内容实现业务逻辑以及在应用程序体系结构中实现业务逻辑的位置。 如果没有指导，大多数组织最终都会陷入业务逻辑混乱。 拥有可重用的逻辑来确保实现的一致性有助于加快现代化工作。

出于我们的目的，我们将业务逻辑定义为不同于用户体验逻辑。 例如，基于检查数据值在屏幕之间导航的逻辑就是用户体验逻辑。 用于确定检查是否完成的逻辑可能包括多个条件评估，并将被视为业务逻辑。

在构建包含低代码的解决方案时，以下注意事项可帮助您确定业务逻辑的放置位置。

• 在 Power Apps 应用程序中：在低代码应用程序中放置业务逻辑是最简单的方法，但它提供的重用或跨应用程序和自动化执行一致性的选择有限。 通常，应将此方法限制为其他应用程序或自动化不需要使用的非任务关键型简单逻辑。 低代码工具不提供逐行调试体验。 如果逻辑跨越多个屏幕或难以阅读，则应考虑其他更易于维护的方法。 在应用程序和云中本地复制某些业务逻辑的情况并不少见。 例如，如果用户输入酒店预订，则业务规则是退房日期不能早于入住日期。 如果应用程序未对此进行验证，则用户将一直走到最后并提交预订，却发现自定义连接器拒绝了它。 在应用程序和云中本地处理验证可提供更好的用户体验。

• 在 Power Automate 云端流中：您可以在流中的操作中表达业务逻辑，流可以响应事件或来自其他应用程序和流的按需运行请求而触发。 该流可以提供一种低代码方法来集中逻辑。 流中的步骤是独立的，不是事务的一部分；但是，如果发生错误，流可以实现补偿以处理回滚。 流可以使用连接运行步骤，这些连接的权限超出了应用用户可能能够执行的操作，从而提供了一种提升权限的方法。 此方法还允许最大程度地减少应用用户可能需要的权限。

• 在 Dataverse 插件中：插件响应数据行事件（如创建、更新或删除）而运行。 无论哪个应用程序或流执行了该操作，也无论该操作是否直接通过 Dataverse API 完成，只要事件发生，该逻辑就会运行。 此行为的好处是，它确保了所有用途的一致性。 此外，来自插件逻辑的所有 Dataverse 数据更改都是事务性的，要么全部完成，要么全部回滚。 插件逻辑必须简短高效，不要尝试实现长时间运行的工作。 有时，如果必须侦听多个表上的事件才能完成单个业务事件（如 Close Inspection），则事件插件并不是最佳方法。 例如，您可以考虑使用 Dataverse 自定义 API，而不是在多个表上安装插件。 插件可以执行用户通常可能不具有的提升权限的逻辑。 此方法还允许最大程度地减少应用用户可能需要的权限。 插件可与应用程序和流一起部署在 Dataverse 解决方案中。

• 在 Dataverse 自定义 API 中：Dataverse 自定义 API 允许您实现自己的自定义 API 消息，从而运行逻辑。 例如，可以创建一个“关闭检查”自定义 API，调用该 API 来执行检查和关闭检查的所有工作。 它不会由事件驱动，而是由需要它的应用和流按需使用。 与事件驱动插件一样，在自定义 API 插件中完成的数据更改是事务性的。 当自定义 API 使用的唯一服务是用于其他数据工作的 Dataverse API 时，它的效果最佳。 自定义 API 的插件可以与应用程序和流一起部署在 Dataverse 解决方案中。

实现代码 API

您可以在自己喜欢的 API 托管运行时中实现 API，例如 Azure Functions、Azure Container Apps 或任何能够托管 REST API 的服务。 这些自定义 API 可以实现任何逻辑，低代码和传统代码应用程序都可以使用它们。 自定义 API 不提供任何事务支持，除了它们使用的 API 可能提供的内容。 例如，如果自定义 API 使用 SQL Server，则可以使用 SQL Server 事务构造。 代码 API 的部署将独立于可能使用它的低代码资源。 可以使用 Azure API 管理来控制这些 API 的使用，并帮助使它们更易于发现。

安全性

安全性（包括身份验证和授权）是现代化应用程序体系结构的重要组成部分。 与传统应用程序相比，现代应用程序在保护方面通常更具挑战性。 它们包括多个云服务，用户可以从更不同的位置使用它们。 从概念上讲，平台的安全性是为了确保用户执行需要执行的操作时干扰最少，同时继续保护数据和服务。

Power Platform 采用了一种多层次的安全方法，您可以用它来构建您的安全架构。 这些功能的核心原则是，低代码解决方案应与您现有的安全设备集成，以最大程度地减少引入它们的影响。

让我们来看看构成 Power Platform 安全模型的多层安全架构。

• 用户通过 Microsoft Entra ID 进行身份验证，并可使用条件访问策略限制使用。
• 许可是允许访问 Power Platform 组件的第一道防线。
• 创建应用程序和工作流的能力由环境中的安全角色控制。
• 用户查看和使用 Power Platform 资源的能力由与他们共享应用程序来控制。 资源直接与用户或 Entra ID 组共享。
• 环境作为安全边界，允许在每个环境中实施不同的安全需求。
• Power Automate 流和画布应用程序使用连接器。 应用程序使用连接器时，具体的连接凭证和相关服务权限决定了权限。
• 具有 Dataverse 实例的环境支持更高级的安全模型，这些模型专门用于控制对该 Dataverse 实例中数据和服务的访问。
• 可以通过数据策略来进一步限制连接器使用。 也可以对连接器应用交叉租户入站和出站限制。

值得注意的是，在使用连接器访问数据源时，数据源提供的所有底层安全都是对所述安全层的补充。 Power Apps 和 Power Automate 默认情况下不会向用户提供他们尚未拥有的对连接器数据源的访问权限。 用户只能访问他们真正需要访问的数据。

当您使用 Dataverse 作为解决方案的一部分时，它包括一个基于角色的安全模型，可以适应许多业务场景。 数据的安全性可以一直延伸到数据行上的每一列。 为用户分配了一个或多个安全角色，这些角色共同决定了用户的整体权限。 Dataverse 提供了业务单元和团队等安全建模构件。 例如，业务部门可用于定义安全边界，以使数据在两组不同的组织用户之间保持隔离。 您可以使用团队对需要类似数据访问权限的用户进行分组。 您甚至可以分配数据行的组所有权。 下图演示了如何使用业务部门隔离组织各部门的数据。

设计安全模型

针对应用程序的整体体系结构定制现代化应用程序的安全模型。 使用单个数据存储库且没有连接器的应用程序需要最少的安全设计工作。 随着应用程序使用更多的连接器和数据存储库，您的安全建模必须包括其他注意事项。

• 用户身份：用户如何进行身份验证，在来自企业内部的场景中，用户身份是否已映射到 Microsoft Entra ID 中？ 这包括支持云数据存储（如 Dataverse）中应用组或团队分配所需的组映射。

• 连接器连接身份：当应用程序使用一个或多个连接器时，连接的身份验证类型是什么？ 例如，使用服务主体进行连接的应用程序不需要应用程序的用户能够直接访问连接器，这在某些情况下可能很有用。 单个用户连接可能适用于需要知道哪个用户执行了操作或将响应范围限定为特定用户的应用程序。

• 安全结构的可移植性：当您的应用程序使用更多连接器和数据存储库时，请务必记住，并非所有安全结构都能直接映射到另一种安全结构。 例如，在 Dataverse 中，用户可以通过多种方式访问数据行，包括与用户共享数据行。 如果应用程序将 SharePoint 文档库与数据行关联起来，则访问文档库的安全性与控制 Dataverse 访问的安全性是分开的。 它们不直接映射。 现代化应用程序必须适应它们使用的连接器和数据存储库之间的这些类型的不匹配。

人工智能

在过去几年中，人工智能已经进入了应用程序现代化工作。 在对应用程序进行现代化改造时，组织应考虑使用人工智能来帮助用户提高工作效率并更好地做出明智的决策。 注入人工智能的结果还可以转化为更好的客户体验，从而对业务成果产生积极影响。

包括 AI，过去在集成应用程序逻辑和构建自定义训练模型方面涉及繁重的工作。 借助大型语言模型的可用性和强大功能，应用程序现在可以引入使用 AI 的新方法来帮助用户获取答案和执行任务。 用户可以使用自然语言提示，在广泛的辅助业务场景中与 AI 功能进行交互。

Microsoft 在核心产品和服务中引入了 Copilot，使访问高级 AI 技术变得更加容易。 Copilot 使用现代人工智能技术和大型语言模型，用户可以在他们日常使用的应用程序中与之交互，如 Microsoft 365、Windows、Dynamics 365 和 Power Platform。

借助插件扩展

Copilot 支持的应用程序的用户可以向 Copilot 请求有关应用程序中常见任务的帮助。 您可以扩展 Copilot，以包括他们尚不知道的数据和任务，这些数据和任务超出了用户正在使用的应用范围。 Microsoft 365 Copilot 可以整合存储在 Dataverse 中的 Power Platform 数据，这样用户就不必在应用程序之间来回切换。 例如，在 Outlook 中，用户可以要求 Copilot 为今天完成的所有失败检查生成状态更新。 Microsoft 365 Copilot 可自动继承 Dataverse 的本地安全和管理框架，并在运行时应用用户安全和权限。

连接器即插件

Power Platform 连接器对 Copilot 体验也很重要。 连接器能够作为插件进行连接，以扩展 Copilot 的功能。 例如，Microsoft 365 Copilot 搭配适用于 Jira 软件的 Power Platform 连接器可使项目经理请求 Jira 支持票单的状态，并根据响应采取行动，例如将其转发给更多审批人员或开始新硬件的采购订单。 使用插件，您可以将业务流程和数据与 Copilot 集成，使用户能够通过他们使用的任何应用程序进行交互。

构建自己的助手

随着用户越来越习惯在他们的应用程序中使用人工智能助手，他们希望所有应用程序都能有人工智能助手。 您可以通过使用 Copilot 堆栈（一个人工智能开发框架）创建的助手，使您的现代应用程序更具吸引力。

您可以使用 Power Apps 中的预构建 Copilot 控件，在画布应用程序和模型驱动应用程序中添加助手。 通过配置数据源的视图和一些基本的提示信息，您可以快速提供自己的应用内助手体验。

应用程序生命周期管理

任何现代化工作的一个重要部分是建立适当的应用程序生命周期管理过程。 组织通常希望他们的低代码工作能够适应他们使用传统代码 ALM 的方式。 Power Platform 提供了 ALM 工具，因此您可以在您通常使用的流程中或旁边加入低代码工件。

Power Platform 中的 ALM 从如何构建低代码资源开始。 您构建的资源处于 Power Platform 环境中。 一个环境可以有一个 Dataverse 数据存储。 您可以使用多个环境（通常是开发、测试和生产）在包含低代码的 ALM 进程中实现登陆区域。 环境的数量和用途是灵活的，组织可以调整它们以满足单个项目的需求。 Dataverse 解决方案是相关低代码资源的容器，便于版本控制和从一个环境传输到另一个环境。

Power Platform 管道提供了一种低代码方法，用于自动部署和实施持续集成与持续交付 (CI/CD)。 Power Platform 在配置管道时管理流程。 管理员可以集中管理和治理管道。

组织还可以使用他们选择的 CI/CD 工具。 Power Platform CLI 是一种命令行工具，可与大多数 CI/CD 自动化工具一起使用。 Power Platform 构建工具为 GitHub 提供了操作，为 Azure DevOps 提供了任务，提供了构建包含低代码工件的 CI/CD 自动化所需的所有常用操作。

下图说明了团队构建检查应用的示例。 在他们的内部循环中，他们在开发环境中工作，并将他们的工作存储在 Git 存储库中。 外循环由测试环境和生产环境组成。 构建管道采用版本控制的解决方案，执行任何必要的检查，并生成检查解决方案工件。 然后，发布管道将解决方案部署到测试中，测试人员可以在其中验证它是否已准备好用于生产。 获得批准后，发布管道会将解决方案部署到生产环境。

当您从 Dataverse 导出解决方案时，它会以单个压缩文件的形式导出。 若要在版本控制中存储低代码资源，可以使用生成工具将解决方案文件解压缩为各个组件文件。 在生成自动化期间，生成工具将版本控制中的单个文件合并到单个压缩文件中。

将解决方案部署到包含早期版本的解决方案的环境中时，会使用仅应用更改的智能升级过程。 此升级过程避免了使用差异脚本或其他方法来确定需要部署的内容。

当您的现代化应用程序包含低代码和传统代码资源时，您可以将它们组合到单个 CI/CD 流程中，也可以单独管理它们。 通过独立管理，可以单独部署资源，项目团队可以实现更高的敏捷性。 例如，如果团队不引入重大更改，则低代码应用程序使用的 API 可以独立部署。

监控和洞察

现代化应用程序需要集成到操作环境中，以便能够诊断从开发到生产的不同环境的问题。 Application Insights 是 Azure Monitor 扩展，可收集来自 Power Apps 和 Dataverse 的遥测数据。 此信息不仅有助于识别和解决问题，还可以深入了解用户在应用程序中执行的操作。 您可以使用这些见解来帮助改进现代化应用程序中的应用和流程。

在开发 Power Apps 应用程序时，开发人员可以加入记录自定义事件的逻辑。 将已部署的应用程序连接到 Application Insights 后，扩展会在用户与应用程序交互时自动收集基本的遥测信息，包括从记录的事件中获取更多上下文。

管理员还可以配置 Dataverse 环境，将遥测数据导出到 Application Insights。 记录的数据可包括 Dataverse API 调用、插件执行、SDK 操作和异常。 创建自定义插件逻辑的开发人员可以将更多自定义遥测数据直接记录到 Application Insights。

在应用程序中使用 Application Insights 可以更轻松地关联多个资源的问题。 运营人员可以在 Azure Monitor 中创建警报，以便在检测到大量异常时触发。 对现代化应用程序进行定期分析可以确定需要更多调查的趋势。

结束语

在本文中，我们探讨了使用 Microsoft Power Platform 将旧版应用程序现代化的好处、策略和最佳做法。 您将获得有关使用 Power Platform 的低代码功能的见解和指导，以确保作为企业数字化转型一部分的现代化工作取得成功。

遗留应用程序给组织带来了许多挑战。 为了克服这些困难，组织必须着手实施应用程序现代化计划，以振兴其基础设施并利用现代技术。 本文介绍了如何对现代化工作采取低代码方法，特别是如何使用 Microsoft Power Platform 的低代码开发功能快速生成和部署新式应用程序。

与传统编码人员相比，低代码为更广泛的人群打开了大门。 成功采用低代码方法的组织的一个关键因素是确保参与应用程序现代化的人员接受过低代码开发方面的培训，无论他们是专业开发人员还是业务用户。 业务用户更接近正在解决的业务问题，并且可以贡献节省时间的专业知识。 传统的代码开发人员可以应用他们已经拥有的技术和技能来构建扩展，以填补任何低代码空白。 通过将业务和技术资源融合到我们喜欢称之为“融合团队”的团队中，组织可以发挥最大的作用。

本文为你奠定了基础。 接下来的步骤就交给您了。 以下是一些建议：

• 花几分钟时间了解您的组织已经在使用低代码执行了哪些操作。 这可能会让您大吃一惊！
• 评估您的应用程序现代化机会。
• 确定并优先考虑优秀的第一候选人。
• 为应用现代化团队配备人员。 为取得最佳效果，请确保这是一个融合团队。
• 确保团队接受过必要的培训才能取得成功。
• 允许团队对应用程序进行现代化改造。
• 反思现代化工作。 优化它并将其扩展到其他旧应用程序。

每个组织的应用程序现代化之旅都是独一无二的。 您的 Microsoft 客户团队或 Power Platform 合作伙伴可以帮助您规划您的旅程，并让您一路走在正确的道路上。

资源

• Microsoft Power Platform Premium 功能的总体经济影响™
• 美国航空 ConnectMe 应用程序为客户创造更顺畅的旅行体验，为团队成员提供更好的技术工具
• GitHub 上的 Power Fx 开源存储库
• CoE 初学者工具包
• Power Platform 采用情况评估
• 数字保险机构利用 Power Platform 实现复杂采购流程的自动化
• PCF 图库
• EY 使用 Microsoft Power Platform 重新设计其全球财务流程
• Azure 专用链接
• MicrosoftAzure ExpressRoute
• Power Platform 发布计划器
• Microsoft Power Platform 许可指南
• Microsoft 概述构建人工智能应用程序和助手框架；扩展人工智能插件生态系统