Power Platform不仅仅是低代码/无代码开发

Power Platform不仅仅是低代码/无代码开发

Reed Robison反思了微软的power平台和低代码/无代码开发如何为Office 365客户提供了一个方面的价值

作为一个已经存在了很长时间的开发者，我看到了许多低代码/无代码平台的出现和消失。在我的记忆中，有一些产品承诺无需“编写一行代码”就能构建应用程序。这是一个引人注目的销售说辞，但实际开发要复杂得多。我发现大多数工具解决了非常基本的问题，但在规模、集成、治理和安全性方面遇到了严重的限制。诚然，这些经历让我厌倦了认真对待新的“低代码”平台。电力平台有什么不同?

在花了一些高质量的时间使用Power platform之后——在我自己的项目中使用它，并看到它在我的一些客户中获得了成功，我开始意识到这个生产力领域发生了多大的变化。我也重新思考了我对云计算时代低代码开发平台的看法，在云计算时代，连接服务为所有这些工作打开了新的大门。Power Platform非常强大。如果你是Power Platform的新手，有很多很好的理由去看看它，但是如果你已经在使用Office 365了，你可能就错过了。

涵盖Power Platform的所有功能和能力超出了这篇文章的范围，但我想分享一些让我对这个平台的价值和生产力着迷的事情。我还应该注意到，在这篇文章的时候，Power Platform由Power automation, Power Apps, Power BI和Power Virtual Agents组成。在这篇文章中，我主要是指Power automation和Power Apps，但还有很多功能需要深入研究。

ower Virtual Agents让你创建强大的聊天机器人，可以回答客户、员工或网站或服务访问者提出的问题，而不需要数据科学家或人工智能开发人员。

Power BI允许您轻松地连接到数据源，可视化并发现重要的内容，并与您想要的任何人或任何人共享。

我开始使用Power automation来处理驱动这个博客的SharePoint工作流。围绕列表数据构建自动化非常容易，但我没有想到它只是一个用户生产力工具。当我开始与客户一起进行2010年工作流迁移时，我受到了挑战，要从一个组织平台来看待它，以及它能提供多少。

将SharePoint工作流迁移到Power automation：我猜想，你们中的许多人可能会像我一样，开始探索Power Platform，将其作为SharePoint现代化战略的一部分。Power Platform被定位为InfoPath表单和SharePoint工作流的前进路径。随着SharePoint 2010工作流的退休，很多客户开始关注Power平台，以及移动遗留解决方案所涉及的内容。在开始迁移解决方案之前，重要的是要建立Power Platform环境，并对它们的工作方式有基本的了解。使用Power Platform的一些基本步骤——尝试Power automation、Power Apps和Power BI是一个很好的开始方式。

我猜想，你们中的许多人可能会像我一样，开始探索Power Platform，将其作为SharePoint现代化战略的一部分。Power Platform被定位为InfoPath表单和SharePoint工作流的前进路径。随着SharePoint 2010工作流的退休，很多客户开始关注Power平台，以及移动遗留解决方案所涉及的内容。在开始迁移解决方案之前，重要的是要建立Power Platform环境，并对它们的工作方式有基本的了解。使用Power Platform的一些基本步骤——尝试Power automation、Power Apps和Power BI是一个很好的开始方式。

Office 365和Azure Active Directory让这变得更加容易

任何一项新技术面临的最大挑战之一，就是尝试将启动所需的一切都带上飞机——环境、硬件、用户、安全、管理等。

对于已经拥有Office 365租户的客户，启动所需的一切都已经就绪。环境是在Azure Active Directory (AAD)租户下创建的Power Platform所使用的逻辑容器。作为租户的一部分，它构建在您已经使用AAD设置的所有内容之上，用于管理用户、组、策略、身份验证方法、审计日志和服务。

Power Platform管理所有底层服务的资源分配，因此不需要部署vm或数据库。要开始构建流和应用程序，只需在租户下配置一个环境并分配用户/许可证。

如果您是一名开发人员，需要与租户一起工作，只是需要一个地方进行试验，那么使用Office 365开发人员计划并获得开发人员订阅是非常容易的。

简单地说，要开始探索Power Platform，几乎没有什么需要配置的，如果你是一个已经使用Office 365的组织，它基本上已经在那里等着你开始了。

有效和可扩展的数据访问

Power Platform提供了功能丰富的基于云的环境来构建工作流和应用程序，但这一切都无关紧要，除非它与您的数据无缝集成。作为一名开发人员，我喜欢把时间花在处理业务问题上——而不是试图让api工作。Power Platform通过连接器使这一点变得很容易。

连接器是API的代理或包装器，它允许任何底层服务与Power Platform对话。它为用户提供了一种方式来连接他们的帐户，并利用一组预先构建的操作和触发器来构建应用程序和工作流。连接器从您构建的解决方案(例如流或应用程序)中抽象出如何与已连接服务交互的所有技术细节。

几乎每种类型的服务都可以使用预构建连接器，更重要的是，该模型是可扩展的，因此，如果您需要处理目前还不支持的内容或您的业务需要定制的内容，您可以编写自己的连接器。

连接器通常是基于REST API的，根据实现，支持各种身份验证方法(Azure AD、OAuth、SQL Auth或Windows Auth)。每个连接器提供一组操作，分类为“Actions”和“Triggers”。操作是由用户指导的更改。例如，您可以使用一个操作在SQL数据库中查找、写入、更新或删除数据。触发器在特定事件发生时通知应用程序。例如，FTP连接器有OnUpdatedFile触发器。您可以构建一个逻辑应用程序或一个监听此触发器并在触发器触发时执行操作的流。触发器可以是Push或Poll。

对于O365服务和连接器，其美妙之处在于无论您为用户提供了什么安全性，都将其应用到解决方案中。例如，访问SharePoint Online资源的flow或PowerApps使用O365凭证，并且被限制为用户通常能够访问的相同数据。这使得构建访问Office 365中的组织数据的解决方案变得很容易，而无需处理要管理的过多权限层。

如果您需要连接到本地资源(如SQL Server)，您可以使用本地数据网关来安全地控制对所有这些服务的访问，如果将数据连接到这么多不同的服务是一个问题，那么可以配置DLP策略来控制在您的环境中启用哪些连接器来控制允许用户与之交互的数据和服务。结合租户级控制(如条件访问策略和外逃控制)，组织对员工可以做什么和不能做什么有广泛的控制。连接器使获取数据和与各种服务交互变得很容易，因此，在提供控制以确保数据受到保护的同时，为各种需求构建自动化和应用程序是很简单的。

这是集中和管理解决方案的好方法

几乎每家大公司都面临影子应用或影子IT的挑战。这些是员工开发的应用程序或脚本，它们没有得到官方的支持，但却得到了poplar的广泛使用。对任何公司来说，这既是福也是祸。您如何支持Citizen开发人员，同时仍然提供一定程度的治理，以保护您公司的利益?对于如何提高工作效率，员工通常都有很好的想法，但同样重要的是，要确保应用程序的构建方式不会违反公司政策或引入不可预见的风险。

在组织中创建和共享的应用程序可能运行在浏览器或流行的移动设备上，但你不需要处理在哪里查找、维护或放置它们。你可以在Office 365应用程序页面、Power apps Mobile应用程序，甚至在SharePoint或Teams内部找到它们。

Power Platform提供了一种很好的方式，通过组织治理和意识来拥抱公民发展，而不是努力控制影子应用/IT解决方案。这里有一些很好的资源可以帮助您定义设置环境的策略。本Power Apps和Power automation管理白皮书可能也有帮助。

总之，ure和Office 365建立了所有的构建模块，这些模块支持高效的低代码/无代码平台的生产力。Power Platform利用这些功能使公民开发易于访问、高效且可扩展，适用于您需要构建的任何解决方案。组织可以保护环境并控制数据的使用方式，同时仍能在整个劳动力中实现创新。Power Platform还可以帮助集中生产力应用程序和自动化，以便轻松地监控、管理和治理。如果你的组织正在为如何处理Shadow Apps/IT而挣扎，这是另一个选择Power Platform的好理由。

Microsoft Power管理员平台SharePoint工作流转换到Power automationPower BI分析Microsoft Power平台采用最佳实践

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。