Azure 逻辑应用中的自定义连接器

Artículo
10/15/2024

适用范围：Azure 逻辑应用（消耗型 + 标准型）

在 Azure 逻辑应用中使用预生成的连接器操作时，无需编写任何代码即可快速创建自动化集成工作流。连接器可帮助工作流跨其他应用、服务、系统、协议和平台连接和访问数据、事件和操作。每个连接器都以触发器、操作或两者的形式提供操作，你可以将它们添加到工作流中。通过使用这些操作，可以扩展云应用和本地应用的功能，以处理新数据和现有数据。

Azure 逻辑应用中的连接器是内置或托管连接器。内置连接器在 Azure 逻辑应用运行时本地运行，这意味着它们与运行时托管在同一进程中，并提供更高的吞吐量、低延迟和本地连接。托管连接器是 API 的代理或包装器（例如 Office 365 或 Salesforce），可帮助基础服务与 Azure 逻辑应用程序通信。托管连接器由 Azure 中的连接器基础结构提供支持，并由 Microsoft 部署、托管、运行和管理。你可以从数百个托管连接器中进行选择，以用于 Azure 逻辑应用中的工作流。

在工作流中首次使用连接器操作时，某些连接器不需要先创建连接，但许多其他连接器需要此步骤。创建的每个连接实际上都是一个单独的 Azure 资源，提供对目标应用、服务、系统、协议或平台的访问。

但有时，你可能想要调用不可用作预生成连接器的 REST API。若要支持针对性更强的方案，可以创建自己的自定义连接器，以提供不可用作预生成操作的触发器和操作。

本文概述了用于消耗型逻辑应用工作流和标准逻辑应用工作流的自定义连接器。每种逻辑应用类型都由不同的 Azure 逻辑应用运行时提供支持，分别托管在多租户 Azure 和单租户 Azure 中。有关 Azure 逻辑应用中的连接器的详细信息，请查看以下文档：

消耗型逻辑应用

在多租户 Azure 逻辑应用中，可以从基于 Swagger 或基于 SOAP 的 API 创建自定义连接器，最高可达到在消耗型逻辑应用工作流中使用的特定限制。连接器文档提供了有关如何为消耗型逻辑应用创建自定义连接器的更多概述信息，包括完整的基础和高级教程。以下列表还提供了有关消耗型逻辑应用的自定义连接器信息的直接链接：

标准逻辑应用

在单租户 Azure 逻辑应用中，重新设计的 Azure 逻辑应用运行时为标准逻辑应用工作流提供支持。此运行时不同于为消耗型逻辑应用工作流提供支持的多租户 Azure 逻辑应用运行时。单租户运行时使用 Azure Functions 扩展性模型，该模型提供了一项关键功能，可用于创建自己的内置连接器，供任何人在标准工作流中使用。在大多数情况下，内置版本提供更好的性能、更全面的功能以及更实惠的价格。

正式发布单租户 Azure 逻辑应用时，新的内置连接器包括 Azure Blob 存储、Azure 事件中心、Azure 服务总线和 SQL Server。随着时间的推移，此内置连接器列表将继续增长。但是，如果需要标准逻辑应用工作流中未提供的连接器，可以使用标准工作流中基于服务提供商的内置连接器所使用的同一扩展性模型创建自己的内置连接器。

基于服务提供程序的内置连接器

在单租户 Azure 逻辑应用中，具有特定属性的内置连接器称为“服务提供商”（非正式）。例如，这些连接器基于 Azure Functions 扩展性模型，该模型提供用于创建自己的自定义内置连接器的功能，以便在标准逻辑应用工作流中使用。

相比之下，非服务提供商内置连接器具有以下属性：

不基于 Azure Functions 扩展性模型。
直接实现为 Azure 逻辑应用运行时中的作业，例如计划、HTTP、请求和 XML 操作。

目前没有任何功能可用于创建非服务提供程序内置连接器或创建直接在 Azure 逻辑应用运行时中运行的新作业类型。但是，可以使用服务提供程序基础结构创建自己的内置连接器。

以下部分提供了有关扩展性模型如何用于自定义内置连接器的详细信息。

内置连接器扩展性模型

基于 Azure Functions 扩展性模型，单租户 Azure 逻辑应用中的内置连接器扩展性模型具有一个服务提供程序基础结构，可用于创建、打包、注册和安装你自己的内置连接器，作为任何人都可以在其标准工作流中使用的 Azure Functions 扩展。此模型包含自定义内置触发器功能，支持将 Azure Functions 触发器或操作公开为自定义内置连接器中的服务提供程序触发器。

下图显示了 Azure 逻辑应用设计器和运行时对具有基于 Azure Functions 的触发器的自定义内置连接器所期望的方法实现：

显示基于 Azure Functions 的服务提供商基础结构的概念图。

以下部分提供了有关连接器需要实现的接口的详细信息。

IServiceOperationsProvider

此接口包含为自定义内置连接器提供操作清单的方法。

操作清单

操作清单包含有关自定义内置连接器中已实现的操作的元数据。 Azure 逻辑应用设计器主要使用此元数据来驱动连接器操作的创作和监视体验。例如，设计器使用操作元数据来了解特定操作所需的输入参数，便于根据操作输出的架构生成输出的属性标记。

设计器需要并使用 GetService() 和 GetOperations() 方法来查询连接器提供并显示在设计器表面的操作。 GetService() 方法还指定设计器所需的连接输入参数。

有关这些方法及其实现的详细信息，请查看本文后面的要实现的方法部分。
操作调用

操作调用是 Azure 逻辑应用运行时在工作流执行期间使用的方法实现，用于调用工作流定义中的指定操作。
- 如果触发器是基于 Azure Functions 的触发器类型，则 Azure 逻辑应用中的运行时使用 GetBindingConnectionInformation() 方法向 Azure Functions 触发器绑定提供所需的连接参数信息。
- 如果连接器具有操作，则运行时使用 InvokeOperation() 方法来调用连接器中在工作流执行期间运行的每个操作。否则，无需实现此方法。

有关这些方法及其实现的详细信息，请查看本文后面的要实现的方法部分。

IServiceOperationsTriggerProvider

自定义内置触发器功能支持将 Azure Functions 触发器或操作添加并公开为自定义内置连接器中的服务提供程序触发器。若要使用基于 Azure Functions 的触发器类型和与 Azure 托管连接器触发器相同的 Azure Functions 绑定，请实现以下方法以提供 Azure Functions 所需的连接信息和触发器绑定。

GetFunctionTriggerType() 方法需要返回与 Azure Functions 触发器绑定中的 type 参数相同的字符串。
GetFunctionTriggerDefinition() 具有默认实现，因此无需显式实现此方法。但是，如果要更新触发器的默认行为，例如提供设计器未公开的额外参数，则可以实现此方法并替代默认行为。

要实现的方法

以下部分提供了有关连接器需要实现的方法的详细信息。有关完整示例，请查看示例 CosmosDbServiceOperationProvider.cs 和为单租户 Azure 逻辑应用中的标准逻辑应用创建自定义内置连接器。

重要

当你有敏感信息（例如包含用户名和密码的连接字符串）时，请确保使用可用的最安全身份验证流。例如，Microsoft 建议你在有支持的情况下使用托管标识验证对 Azure 资源的访问权限，并分配具有最低必需权限的角色。

如果此功能不可用，请务必通过其他措施（例如可与应用设置一起使用的 Azure 密钥保管库）保护连接字符串。然后，可以直接引用安全字符串，例如连接字符串和密钥。与 ARM 模板类似，在部署时可以定义环境变量，可以在逻辑应用工作流定义中定义应用设置。然后，可以捕获动态生成的基础结构值，例如连接终结点、存储字符串等。有关详细信息，请参阅Microsoft 标识平台的应用程序类型。

GetService()

设计器需要此方法来获取服务的高级元数据，包括服务说明、连接输入参数、功能、品牌颜色、图标 URL 等。

public ServiceOperationApi GetService()
{
   return this.{custom-service-name-apis}.ServiceOperationServiceApi();
}

有关详细信息，请查看示例 CosmosDbServiceOperationProvider.cs。

GetOperations()

设计器需要此方法来获取服务实现的操作。操作列表基于 Swagger 架构。设计器还使用操作元数据来了解特定操作的输入参数，并根据操作输出的架构生成输出作为属性标记。

public IEnumerable<ServiceOperation> GetOperations(bool expandManifest)
{
   return expandManifest ? serviceOperationsList : GetApiOperations();
}

有关详细信息，请查看示例 CosmosDbServiceOperationProvider.cs。

GetBindingConnectionInformation()

如果要使用基于 Azure Functions 的触发器类型，此方法会向 Azure Functions 触发器绑定提供所需的连接参数信息。

public string GetBindingConnectionInformation(string operationId, InsensitiveDictionary<JToken> connectionParameters)
{
   return ServiceOperationsProviderUtilities
      .GetRequiredParameterValue(
         serviceId: ServiceId,
         operationId: operationID,
         parameterName: "connectionString",
         parameters: connectionParameters)?
      .ToValue<string>();
}

有关详细信息，请查看示例 CosmosDbServiceOperationProvider.cs。

InvokeOperation()

如果自定义内置连接器只有一个触发器，则无需实现此方法。但是，如果连接器有要实现的操作，则必须实现 InvokeOperation() 方法，连接器中在工作流执行期间运行的每个操都将调用此方法。可以根据连接器操作的需要使用任何客户端，例如 FTPClient、HTTPClient 等。此示例使用 HTTPClient。

public Task<ServiceOperationResponse> InvokeOperation(string operationId, InsensitiveDictionary<JToken> connectionParameters, ServiceOperationRequest serviceOperationRequest)
{
   using (var client = new HttpClient())
   {
      response = client.SendAsync(httpRequestMessage).ConfigureAwait(false).ToJObject();
   }
   return new ServiceOperationResponse(body: response);
}

有关详细信息，请查看示例 CosmosDbServiceOperationProvider.cs。

GetFunctionTriggerType()

若要将基于 Azure Functions 的触发器用作连接器中的触发器，必须返回与 Azure Functions 触发器绑定中的 type 参数相同的字符串。

以下示例返回了现成的内置 Azure Cosmos DB 触发器的字符串 "type": "cosmosDBTrigger"：

public string GetFunctionTriggerType()
{
   return "CosmosDBTrigger";
}

有关详细信息，请查看示例 CosmosDbServiceOperationProvider.cs。

GetFunctionTriggerDefinition()

此方法具有默认实现，因此无需显式实现此方法。但是，如果要更新触发器的默认行为，例如提供设计器未公开的额外参数，则可以实现此方法并覆盖默认行为。

后续步骤

准备好启动实现步骤后，请继续阅读以下文章：

为单租户 Azure 逻辑应用中的标准逻辑应用创建自定义内置连接器

Compartir a través de

Azure 逻辑应用中的自定义连接器

消耗型逻辑应用

标准逻辑应用

基于服务提供程序的内置连接器

内置连接器扩展性模型

IServiceOperationsProvider

IServiceOperationsTriggerProvider

要实现的方法

GetService()

GetOperations()

GetBindingConnectionInformation()

InvokeOperation()

GetFunctionTriggerType()

GetFunctionTriggerDefinition()

后续步骤

Recursos adicionales