关于 Azure 逻辑应用中的连接器
使用 Azure 逻辑应用生成工作流时，可以使用连接器来帮助你快速轻松地访问其他应用、服务、系统、协议和平台中的数据、事件和资源，通常情况下无需编写任何代码。 连接器提供预生成的操作，你可以将其用作工作流中的步骤。 Azure 逻辑应用提供数百种可以使用的连接器。 如果没有连接器可用于要访问的资源，可以使用通用 HTTP 操作与服务通信，也可以创建自定义连接器。
本概述提供有关连接器的概要介绍，以及连接器的一般工作原理。
什么是连接器？
从技术上讲，许多连接器都围绕某种 API 提供了代理或包装器，底层服务使用该 API 与 Azure 逻辑应用进行通信。 此连接器提供在工作流中用于执行任务的操作。 操作以“触发器”或“操作”方式提供，可以配置其中的属性 。 例如，一些触发器和操作还要求首先创建和配置基础层服务或系统的连接，以便可以对用户帐户的访问权限进行身份验证。 有关更多概述信息，请参阅 Azure 逻辑应用、Microsoft Power Automate 和 Microsoft Power Apps 的连接器概述。
有关 Azure 逻辑应用中更热门且常用的连接器的信息，请查看以下文档：
触发器
触发器指定用于启动工作流的事件，始终是所有工作流中的第一步。 每个触发器还遵循可控制触发器如何监视和响应事件的特定触发模式。 通常，触发器遵循轮询模式或推送模式，但有时在两个版本中都可用 。
轮询触发器按指定计划定期检查特定服务或系统，查看是否有新数据或特定事件。 如果有新数据可用或发生特定事件，这些触发器将创建并运行工作流的新实例。 然后，这个新实例再使用这些作为输入传递的数据。
推送触发器侦听新数据或即将发生的事件，而非轮询。 有新数据可用或事件发生时，这些触发器将创建并运行工作流的新实例。 然后，这个新实例再使用这些作为输入传递的数据。
例如，你可能想要生成一个在文件上传到 FTP 服务器时执行操作的工作流。 作为工作流的第一步，可使用名为“添加或修改文件时”的 FTP 触发器，它遵循轮询模式。 然后，可指定一个计划来定期检查上传事件。
触发器还会将任何输入和其他所需数据传递给工作流，而随后的操作可以在整个工作流中引用和使用该数据。 例如，假设要使用名为“收到新电子邮件时”的 Office 365 Outlook 触发器在收到新电子邮件时启动工作流， 你可将此触发器配置为传递来自每封新电子邮件的内容，例如发件人、主题行、正文、附件等。 然后，工作流可使用其他操作处理该信息。
注意
当我们使用 Office 365 Outlook 连接器登录 Office 365 Outlook中的 Office 365 Outlook 应用程序时，
必须使用由世纪互联运营的中国 Office 365 帐户登录。 此帐户的格式类似于 <your-account>@<your-organization>.partner.onmschina.cn。
组织管理员可以通过管理员站点管理用户。
操作
操作是紧跟在触发器之后的操作，会在工作流中执行某种类型的任务。 可以在工作流中使用多个操作。 例如，可使用检测 SQL 数据库中新客户数据的 SQL 触发器启动工作流。 触发器触发后，工作流有一个可获取客户数据的 SQL 操作。 执行 SQL 操作后，工作流还有一个处理数据的操作（不一定是 SQL）。
连接器类别
在 Azure 逻辑应用中，大多数触发器和操作都可在内置版本或托管连接器版本中使用 。 这两个版本都提供少量的触发器和操作。 可用的版本取决于创建的是在多租户 Azure 逻辑应用中运行的消耗型逻辑应用，还是在单租户 Azure 逻辑应用中运行的标准型逻辑应用。
内置连接器在 Azure 逻辑应用运行时上以原生方式运行。
托管连接器由 Azure 部署、承载和管理。 这些连接器提供用于云服务和/或本机系统的触发器和操作。
在标准型逻辑应用中，所有托管连接器都作为“Azure”连接器进行组织。 但是，在消耗型逻辑应用中，托管连接器会作为“标准”或“企业”连接器进行组织，具体取决于定价级别。
有关逻辑应用类型的详细信息，请查看资源类型和主机环境差异。
连接配置
在消耗型逻辑应用中，需要先具有特定权限，然后才能创建或管理逻辑应用及其连接。 有关这些权限的详细信息，请查看安全操作 - 在 Azure 逻辑应用中保护访问和数据。
许多连接器都要求先创建与目标服务或系统的连接，然后才能在工作流中使用托管连接器的触发器或操作。 若要从逻辑应用工作流设计器中创建连接，必须使用帐户凭据（有时还使用其他连接信息）对标识进行身份验证。 例如，必须先为指向该帐户的连接授权，然后工作流才可访问和使用 Office 365 Outlook 电子邮件帐户。 对于某些内置连接器和托管连接器，可以设置并使用托管标识进行身份验证，而不必提供凭据。
尽管是在工作流中创建连接，但这些连接实际上也是单独的 Azure 资源，具有其自己的资源定义。 若要查看这些连接资源定义，请根据你拥有的是消耗型逻辑应用还是标准型逻辑应用来执行以下步骤：
消耗型：若要在 Azure 门户中查看这些连接，请查看在 Azure 门户中查看消耗型逻辑应用的连接。
若要在 Visual Studio 中查看和管理这些连接，请查看使用 Visual Studio 管理消耗型逻辑应用，然后将你的逻辑应用从 Azure 下载到 Visual Studio 中。 有关消耗型逻辑应用的连接资源定义的详细信息，请查看连接资源定义。
标准型：若要在 Azure 门户中查看这些连接，请查看在 Azure 门户中查看标准型逻辑应用的连接。
若要在 Visual Studio Code 中查看和管理这些连接，请查看在 Visual Studio Code 中查看逻辑应用。 connections.json 文件包含连接器创建的连接所需的配置。
连接安全和加密
连接配置详细信息（如服务器地址、用户名和密码、凭据以及机密）会加密并存储在受保护的 Azure 环境中。 此信息仅可用在逻辑应用资源中，并且仅可供对连接资源（使用链接访问检查强制实施）具有权限的客户端使用。 使用 Azure Active Directory 开放式身份验证 (Azure AD OAuth)（如 Office 365、Salesforce 和 GitHub）的连接要求你登录，但 Azure 逻辑应用仅存储访问令牌和刷新令牌作为机密，而不存储登录凭据。
只要目标服务或系统允许，建立的连接就可以访问该服务或系统。 对于使用 Azure AD OAuth 连接的服务（例如 Office 365 和 Dynamics），Azure 逻辑应用会无限期地刷新访问令牌。 其他服务可能会限制在不刷新令牌的情况下，逻辑应用能够使用该令牌的时长。 某些操作（例如更改密码）会使所有访问令牌失效。
提示
如果组织不允许通过 Azure 逻辑应用中的连接器访问特定资源，可使用 Azure Policy阻止用于创建这种连接的功能。
若要详细了解如何保护逻辑应用和连接，请参阅保护 Azure 逻辑应用中的访问和数据。
连接的防火墙访问
如果使用限制流量的防火墙，并且逻辑应用工作流需要通过该防火墙进行通信，则必须设置防火墙，以允许访问逻辑应用工作流所在 Azure 区域中 Azure 逻辑应用平台或运行时使用的入站和出站 IP 地址。 如果工作流还使用托管连接器（例如 Office 365 Outlook 连接器或 SQL 连接器），或使用自定义连接器，则防火墙还需要允许访问该逻辑应用所在的 Azure 区域中的所有托管连接器出站 IP 地址。 有关详细信息，请查看防火墙配置。
自定义连接器和 API
在多租户 Azure 逻辑应用中运行的消耗型逻辑应用中，可以调用无法用作现成连接器的基于 Swagger 或基于 SOAP 的 API。 还可以通过创建自定义 API 应用来运行自定义代码。 有关详细信息，请查看以下文档：
创建基于 Swagger 或基于 SOAP 的自定义连接器，从而使这些 API 可用于 Azure 订阅中的任何消耗型逻辑应用。 若要使自定义连接器可供任何人在 Azure 中使用，请提交连接器进行 Azure 认证。
在单租户Azure 逻辑应用中运行的标准型逻辑应用中，可以创建可用于任何标准型逻辑应用、以原生方式运行且基于服务提供程序的自定义内置连接器。 有关详细信息，请查看以下文档：
已知问题
下表包含逻辑应用连接器的已知问题。
| 错误消息 | 说明 | 解决方法 |
|---|---|---|
Error: BadGateway. Client request id: '{GUID}' |
当一个或多个连接不支持 Azure Active Directory (Azure AD) OAuth 身份验证（如 SFTP 和 SQL）时，更新逻辑应用上的标记会生成此错误。 | 若要防止此行为，请避免更新这些标记。 |