适用于 Power Apps 的区域应用连接器概述

数据是大多数应用(包括在 Power Apps 中构建的应用)的关键所在。 数据存储在数据源中,应用是通过创建的连接来导入数据。 连接使用特定的连接器与数据源进行通信。 Power Apps 提供连接器,适用于许多常用服务和本地数据源,包括 SharePoint、SQL Server、Office 365、Salesforce 和 Twitter。 若要开始向画布应用添加数据,请参阅在 Power Apps 中添加数据连接

连接器可能会提供数据的操作。 某些连接器仅提供表,某些连接器仅提供操作,而某些连接器会提供两者。 此外,您的连接器可能是标准连接器或自定义连接器。

如果您的连接器提供表,则添加数据源,然后选择要管理的数据源中的表。 Power Apps 会将表数据检索到应用中并为您更新数据源中的数据。 例如,可以添加一个包含名为课程的表的数据源,然后在编辑栏中将控件的 Items 属性(如库或表单)设置为以下值:

纯数据源 Items 属性

通过自定义用于显示数据的控件的 Items 属性,您可以指定应用检索的数据。 继续前面的示例,通过将该名称用作 SearchSortByColumn 函数的参数,您可以对课程表中的数据进行排序或筛选。 在此图中,Items 属性所设置的公式指定基于 TextSearchBox1 中的文本对数据进行排序和筛选。

扩展数据源 Items 属性

有关如何使用表自定义公式的详细信息,请参阅以下主题:

了解 Power Apps 中的数据源
通过 Excel 数据生成应用
从头开始创建应用
了解 Power Apps 中的表和记录

备注

若要连接到 Excel 工作簿数据,工作簿必须托管在 OneDrive 等云存储服务中。 有关详细信息,请参阅从 Power Apps 连接到云存储

操作​​

如果您的连接器提供操作,则必须与前面一样仍选择数据源。 而不是选择表作为下一步,但是,通过编辑将显示数据的控件的 Items 属性,可以手动将控件连接到操作。 Items 属性所设置的公式指定用于检索数据的操作。 例如,如果连接到 Yammer,然后将 Items 属性设置为数据源的名称,则应用不会检索任何数据。 若要用数据填充控件,请指定 GetMessagesInGroup(5033622).messages 等操作。

操作数据源 Items 属性

如果需要处理操作连接器的自定义数据更新,请生成包含 Patch 函数的公式。 在公式中,标识操作以及将绑定到操作的字段。

有关如何为自定义更新自定义公式的详细信息,请参阅以下主题:

Patch
Collect
更新

备注

Power Apps 不适用于动态架构。 短语动态架构是指相同的操作可能返回具有不同列的不同表的可能性。 可能导致表中的列不同的条件包括操作输入参数、执行操作的用户或角色,以及用户工作的组等。 例如,如果运行时有不同的输入,SQL Server 存储过程可能返回不同的列。 对于具有动态架构的操作,连接器文档的返回值将显示此操作的输出是动态的。 。 相对而言,Power Automate 与动态架构配合使用,可能会为您的场景提供解决方法。

单击下表中列出的链接,可详细了解最常用的连接器。 若要获取连接器的完整列表,请参阅所有连接器

         
Common Data Service Common Data Service   云存储 云存储 **
Dynamics AX Dynamics AX   Excel Excel
Microsoft Translator Microsoft Translator   Office 365 Outlook Office 365 Outlook
Office 365 Users Office 365 用户   Oracle Oracle
Power BI Power BI   SharePoint SharePoint
SQL Server SQL Server   Twitter Twitter

** 适用于 Azure Blob、Box、Dropbox、Google Drive、OneDrive 和 OneDrive for Business

标准和自定义连接器

Power Apps 为许多常用数据源提供标准连接器。 如果 Power Apps 的标准连接器适用于要使用的数据源的类型,则应使用该连接器。 如果要连接到其他类型的数据源(如已构建的服务),请参阅注册和使用自定义连接器

所有标准连接器

标准连接器不需要特殊许可。 有关详细信息,请参阅 Power Apps 计划

您可以在 Power Apps 论坛中提出有关具体连接器的问题,也可以建议添加连接器或在 Power Apps 建议中做出其他改进。

身份验证的安全性和类型

在创作应用和创建与数据源的连接时,您可能会看到选择的连接器允许您使用不同的方式进行身份验证。 例如,SQL Server 连接器允许您使用 Azure AD Integrated、SQL Server 身份验证和 Windows 身份验证。 每种类型的身份验证都具有与之关联的不同级别的安全性。 了解与使用您的应用程序的用户共享哪些信息和权限很重要。 本文中的主要示例是 SQL Server,但是原理适用于所有类型的连接。

Azure AD Integrated

这是一个安全的连接类型。 例如,SharePoint 使用此类身份验证。 SQL Server 也允许使用此类身份验证。 连接时,Azure AD 服务代表您在 SharePoint 中单独识别您。 您不必提供用户名或密码。 作为作者,您可以使用凭据创建和使用数据源。 当您发布应用程序并且您的应用程序用户登录时,他们也将使用他们的凭据执行这些操作。 如果数据在后端得到适当保护,用户只能根据其凭据查看他们有权查看的内容。 这种类型的安全性使您可以在发布应用程序后在后端数据源更改特定应用程序用户的权限。 例如,您可以授予访问权限、拒绝访问或优化一个用户或一组用户可以在后端数据源上看到的全部内容。

开放标准授权 (Oauth)

这种类型的连接也是安全的。 例如,Twitter 使用此类身份验证。 连接时,您必须提供用户名和密码。 作为作者,您可以使用凭据创建和使用数据源。 当您发布应用程序并且您的应用程序用户登录时,他们也必须提供他们的凭据。 因此,这种连接是安全的,因为您的用户必须使用自己的凭据才能访问数据源服务。

SQL 用户名和密码身份验证

这种连接不是很安全,因为它不依赖最终用户身份验证。 SQL Server 也允许使用此类身份验证。 在 SQL Server 中,这种身份验证称为 SQL Server 身份验证。 许多其他数据库数据源提供类似的功能。 在您发布应用程序时,您的用户不需要提供唯一的用户名和密码。 他们使用您在创作应用程序时提供的用户名和密码。 对数据源的连接身份验证与您的用户隐式共享。 发布应用程序后,连接也将发布并可供您的用户使用。 您的最终用户还可以使用与其共享的任何使用 SQL Server 身份验证的连接来创建应用程序。 您的用户看不到用户名或密码,但是他们可以使用连接。 这种连接肯定有可以有效使用的场景。 例如,如果您有一个只读数据库,可供公司中的每个人使用,那么这种连接类型可能有效。

Windows 身份验证

这种连接不是很安全,因为它不依赖最终用户身份验证。 需要连接到本地数据源时,请使用 Windows 身份验证。 这种连接的一个示例是连接到具有 SQL Server 的本地服务器。 连接必须经过网关。 由于要经过网关,因此连接器有权访问该数据源上的所有数据。 如此一来,您可以使用您提供的 Windows 凭据访问的任何信息对连接器都可用。 而且,发布应用程序后,连接也将发布并可供您的用户使用。 这意味着您的最终用户还可以使用同一个连接来创建应用程序,并访问该计算机上的数据。 数据源的连接也会与共享应用的用户隐式共享。 当您的数据源仅驻留在本地服务器上并且该源上的数据可自由共享时,这种连接类型可能有效。