Conectores personalizados en Azure Logic Apps

Se aplica a: Azure Logic Apps (consumo + estándar)

Sin necesidad de escribir ningún código, puede crear rápidamente flujos de trabajo de integración automatizados cuando usa las operaciones de conectores predefinidos en Azure Logic Apps. Un conector ayuda a los flujos de trabajo a conectar y acceder a datos, eventos y acciones en otras aplicaciones, servicios, sistemas, protocolos y plataformas. Cada conector ofrece operaciones como desencadenantes, acciones o ambas que puede agregar a sus flujos de trabajo. Al usar estas operaciones, se amplían las capacidades de sus aplicaciones en la nube y local para trabajar con datos nuevos y existentes.

Los conectores en Azure Logic Apps se incorporan o se administran. Un conector integrado se ejecuta de forma nativa en el tiempo de ejecución de Azure Logic Apps, lo que significa que se aloja en el mismo proceso que el tiempo de ejecución y proporciona un mayor rendimiento, baja latencia y conectividad local. Un conector administrado es un proxy o una envoltura alrededor de una API, como Office 365 o Salesforce, que ayuda al servicio subyacente a comunicarse con Azure Logic Apps. Los conectores administrados se basan en la infraestructura de conectores de Azure y se implementan, alojan, ejecutan y administran por Microsoft. Puede elegir entre cientos de conectores administrados para usarlos con sus flujos de trabajo en Azure Logic Apps.

Cuando se usa una operación de conector por primera vez en un flujo de trabajo, algunos conectores no requieren que se cree una conexión primero, pero muchos otros conectores requieren este paso. Cada conexión que se crea es en realidad un recurso de Azure independiente que proporciona acceso a la aplicación, servicio, sistema, protocolo o plataforma de destino.

Sin embargo, a veces puede querer llamar a las API de REST que no están disponibles como conectores preconstruidos. Para dar asistencia a escenarios más personalizados, puede crear sus propios conectores personalizados para ofrecer desencadenantes y acciones que no están disponibles como operaciones prediseñadas.

Este artículo ofrece una visión general de los conectores personalizados para los flujos de trabajo de las aplicaciones lógicas de consumo y los flujos de trabajo de las aplicaciones lógicas estándar. Cada tipo de aplicación lógica se basa en un entorno de ejecución de Azure Logic Apps diferente, respectivamente hospedado en Azure multiinquilino y Azure de un solo inquilino. Para más información sobre los conectores en Azure Logic Apps, revise la siguiente documentación:

• Conectores para Azure Logic Apps
• Conectores integrados en Azure Logic Apps
• Conectores administrados en Azure Logic Apps
• Introducción a los conectores
• Inquilino único frente a multiinquilino en Azure Logic Apps

Aplicaciones lógicas de consumo

En Azure Logic Apps multiinquilino, puede crear conectores personalizados a partir de api basadas en Swagger o basadas en SOAP hasta límites específicos para su uso en flujos de trabajo de aplicaciones lógicas de consumo. La documentación de los conectores proporciona más información general sobre cómo crear conectores personalizados para las aplicaciones lógicas de consumo, incluidos tutoriales básicos y avanzados completos. La siguiente lista también proporciona enlaces directos a información sobre conectores personalizados para aplicaciones lógicas de consumo:

• Creación de un conector de Azure Logic Apps
• Creación de un conector personalizado desde una definición de OpenAPI
• Uso de un conector personalizado desde una aplicación lógica
• Uso compartido de conectores personalizados en la organización
• Envío de conectores para que Microsoft los certifique
• Preguntas más frecuentes sobre conectores personalizados

Aplicaciones lógicas estándar

En Azure Logic Apps de un solo inquilino, el tiempo de ejecución rediseñado de Azure Logic Apps alimenta los flujos de trabajo de las aplicaciones lógicas estándar. Este tiempo de ejecución difiere del entorno de ejecución multiinquilino de Azure Logic Apps que impulsa los Flujos de trabajo de aplicaciones lógicas basados en consumo. El tiempo de ejecución de un solo inquilino usa el modelo de extensibilidad de Azure Functions, que proporciona una capacidad clave para crear sus propios conectores incorporados para que cualquiera pueda usarlos en los flujos de trabajo Estándar. En cambio, en la mayoría de los casos, la versión integrada proporciona un mejor rendimiento, funcionalidades y precios, entre otras cosas.

Cuando se lanzó oficialmente Azure Logic Apps, los nuevos conectores integrados incluían Azure Blob Storage, Azure Event Hubs, Azure Service Bus y SQL Server. Con el tiempo, esta lista de conectores incorporados sigue creciendo. Sin embargo, si necesita conectores que no están disponibles en los flujos de trabajo de la aplicación lógica estándar, puede crear sus propios conectores integrados con el mismo modelo de extensibilidad que usan los conectores integrados basados en el proveedor de servicio en los flujos de trabajo estándar.

Conectores integrados basados en el proveedor de servicios

En las instancias de Azure Logic Apps de inquilino único, los conectores integrados con atributos específicos se conocen informalmente como proveedores de servicios. Por ejemplo, estos conectores se basan en el modelo de extensibilidad Azure Functions, que proporciona la capacidad de crear sus propios conectores integrados personalizados para usarlos en flujos de trabajo de aplicaciones lógicas estándar.

En cambio, los conectores integrados que no son de proveedor de servicios tienen los siguientes atributos:

• No se basa en el modelo de extensibilidad de Azure Functions.

• Se implementa directamente como un trabajo dentro del tiempo de ejecución de Azure Logic Apps, como las operaciones Schedule, HTTP, Request y XML.

En la actualidad, no se dispone de capacidad para crear un conector incorporado que no sea de proveedor de servicios o un nuevo tipo de trabajo que se ejecute directamente en el tiempo de ejecución de Azure Logic Apps. Sin embargo, puede crear sus propios conectores integrados con la infraestructura del proveedor de servicios.

La siguiente sección proporciona más información sobre cómo funciona el modelo de extensibilidad para los conectores incorporados personalizados.

Modelo de extensibilidad de conectores incorporados

Basado en el modelo de extensibilidad de Azure Functions, el modelo de extensibilidad de conectores incorporados en Azure Logic Apps de un solo inquilino tiene una infraestructura de proveedores de servicios que puede usar para crear, empaquetar, registrar e instalar sus propios conectores incorporados como extensiones de Azure Functions que cualquiera puede usar en sus flujos de trabajo estándar. Este modelo incluye capacidades de activación incorporada personalizada que admiten la exposición de un desencadenador o acción de Azure Functions como un activador del proveedor de servicios en su conector incorporado personalizado.

El siguiente diagrama muestra las implementaciones de métodos que el diseñador y el tiempo de ejecución de Azure Logic Apps esperan para un conector integrado personalizado con un desencadenador basado en Azure Functions:

Las siguientes secciones proporcionan más información sobre las interfaces que debe implementar su conector.

IServiceOperationsProvider

Esta interfaz incluye los métodos que proporcionan el manifiesto de operaciones para el conector integrado personalizado.

• Manifiesto de operaciones

  El manifiesto de operaciones incluye metadatos sobre las operaciones implementadas en el conector integrado personalizado. El diseñador de Azure Logic Apps usa principalmente estos metadatos para impulsar las experiencias de creación y supervisión de las operaciones del conector. Por ejemplo, el diseñador usa metadatos de operación para comprender los parámetros de entrada requeridos por una operación específica y para facilitar la generación de los tokens de propiedad de las salidas, en función del esquema de las salidas de la operación.

  El diseñador requiere y usa los métodos GetService() y GetOperations() para consultar las operaciones que proporciona el conector y se muestran en la superficie del diseñador. El método GetService() también especifica los parámetros de entrada de la conexión que requiere el diseñador.

  Para más información sobre estos métodos y su implementación, revise la sección Métodos a implementar más adelante en este artículo.

• Invocaciones de operación

  Las invocaciones de operaciones son las implementaciones de métodos que se usan durante la ejecución del flujo de trabajo por el tiempo de ejecución de Azure Logic Apps para llamar a las operaciones especificadas en la definición del flujo de trabajo.

  • Si su desencadenante es un tipo de desencadenador que se basa en Azure Functions, el método GetBindingConnectionInformation() se usa en el tiempo de ejecución de Azure Logic Apps para proporcionar la información de los parámetros de conexión necesarios para el enlace del desencadenante de Azure Functions.

  • Si el conector tiene acciones, el método InvokeOperation() se usa por el tiempo de ejecución para llamar a cada acción en el conector que se ejecuta durante la ejecución del flujo de trabajo. De lo contrario, no es necesario implementar este método.

Para más información sobre estos métodos y su implementación, revise la sección Métodos a implementar más adelante en este artículo.

IServiceOperationsTriggerProvider

Las capacidades de activación integradas personalizadas admiten la adición o exposición de un desencadenador o acción de Azure Functions como un desencadenador de proveedor de servicios en su conector integrado personalizado. Para usar el tipo de desencadenador basado en Azure Functions y el mismo enlace de Azure Functions que el desencadenador del conector administrado de Azure, implemente los siguientes métodos para proporcionar la información de conexión y los enlaces desencadenadores según sea necesario en Azure Functions.

• El método GetFunctionTriggerType() es necesario para devolver la cadena que igual que el parámetro de tipo en el enlace de desencadenador de Azure Functions.

• GetFunctionTriggerDefinition() tiene una implementación predeterminada, por lo que no es necesario implementar explícitamente este método. Sin embargo, si desea actualizar el comportamiento predeterminado del desencadenador, como, por ejemplo, poder proporcionar parámetros adicionales que el diseñador no expone, puede implementar este método e invalidar el comportamiento predeterminado.

Métodos para implementar

En las secciones siguientes se proporciona más información sobre los métodos que el conector necesita implementar. Para ver el ejemplo completo, consulte Sample CosmosDbServiceOperationProvider.cs y Creación de conectores integrados personalizados para aplicaciones lógicas estándar en Azure Logic Apps de inquilino único.

Importante

Cuando tenga información confidencial, como cadenas de conexión que incluyen nombres de usuario y contraseñas, asegúrese de usar el flujo de autenticación más seguro disponible. Por ejemplo, Microsoft recomienda autenticar el acceso a los recursos de Azure con una identidad administrada cuando la compatibilidad esté disponible y asignar un rol que tenga el privilegio menos necesario.

Si esta funcionalidad no está disponible, asegúrese de proteger las cadenas de conexión a través de otras medidas, como Azure Key Vault, que puede usar con la configuración de la aplicación. De ese modo, puede hacer referencia directamente a cadenas seguras, como claves y cadenas de conexión. De forma similar a las plantillas de ARM, donde puede definir variables de entorno en el momento de la implementación, puede definir la configuración de la aplicación dentro de la definición de flujo de trabajo de la aplicación lógica. A continuación, puede capturar valores de infraestructura generados dinámicamente, como puntos de conexión, cadenas de almacenamiento, etc. Para más información, consulte Tipos de aplicaciones para la plataforma de identidad de Microsoft.

GetService()

El diseñador requiere que este método obtenga los metadatos de alto nivel para el servicio, incluida la descripción del servicio, los parámetros de entrada de conexión, las funcionalidades, el color de marca, la dirección URL del icono, etc.

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

Para obtener más información, consulte Sample CosmosDbServiceOperationProvider.cs.

GetOperations()

El diseñador requiere este método para obtener las operaciones implementadas por el servicio. La lista de operaciones se basa en el esquema de Swagger. El diseñador también utiliza los metadatos de la operación para comprender los parámetros de entrada para operaciones específicas y generar las salidas como tokens de propiedad, en función del esquema de la salida de una operación.

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

Para obtener más información, consulte Sample CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Si quiere usar el tipo de desencadenador basado en Azure Functions, este método proporciona la información de los parámetros de conexión necesarios al enlace de desencadenador de Azure Functions.

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

Para obtener más información, consulte Sample CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Si el conector integrado personalizado solo tiene un desencadenador, no tiene que implementar este método. Sin embargo, si el conector tiene acciones que implementar, debe implementar el método InvokeOperation(), al que se llama para cada acción del conector que se ejecuta durante la ejecución del flujo de trabajo. Puede usar cualquier cliente, como FTPClient, HTTPClient, etc., según las acciones del conector. En este ejemplo se usa 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);
}

Para obtener más información, consulte Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Para usar un desencadenador basado en Azure Functions como desencadenador en el conector, debe devolver la cadena que es igual que el parámetro de tipo en el enlace de desencadenador de Azure Functions.

En el siguiente ejemplo se devuelve la cadena del desencadenador integrado de Azure Cosmos DB, "type": "cosmosDBTrigger":

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

Para obtener más información, consulte Sample CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Este método tiene una implementación predeterminada, por lo que no es necesario implementar explícitamente este método. Sin embargo, si desea actualizar el comportamiento predeterminado del desencadenador, como, por ejemplo, poder proporcionar parámetros adicionales que el diseñador no expone, puede implementar este método e invalidar el comportamiento predeterminado.

Pasos siguientes

Cuando esté listo para iniciar los pasos de implementación, continúe con el siguiente artículo:

• Creación de conectores integrados personalizados para aplicaciones lógicas estándar en Azure Logic Apps de inquilino único