Partager via

Connecteurs personnalisés dans Azure Logic Apps

  • Article

S’applique à : Azure Logic Apps (Consommation + Standard)

Sans écrire de code, vous pouvez rapidement créer des workflows d’intégration automatisés lorsque vous utilisez les opérations de connecteur prédéfinies dans Azure Logic Apps. Un connecteur permet à vos workflows de se connecter aux données, aux événements et aux actions sur d’autres applications, services, systèmes, protocoles et plateformes et d’y accéder. Chaque connecteur offre des opérations en tant que déclencheurs, actions ou les deux, que vous pouvez ajouter à vos workflows. En utilisant ces opérations, vous développez les fonctionnalités de vos applications cloud et locales pour travailler avec des données nouvelles et existantes.

Les connecteurs dans Azure Logic Apps sont intégrés ou gérés. Un connecteur intégré s’exécute en mode natif sur le runtime Azure Logic Apps, ce qui signifie qu’il est hébergé dans le même processus que le runtime et fournit un débit plus élevé, une faible latence et une connectivité locale. Un connecteur managé est un proxy ou un wrapper autour d’une API, comme Office 365 ou Salesforce, qui aide le service sous-jacent à parler à Azure Logic Apps. Les connecteurs managés sont alimentés par l’infrastructure de connecteur dans Azure et sont déployés, hébergés, exécutés et gérés par Microsoft. Vous pouvez choisir parmi des centaines de connecteurs managés à utiliser avec vos workflows dans Azure Logic Apps.

Lorsque vous utilisez une opération de connecteur pour la première fois dans un workflow, certains connecteurs ne nécessitent pas que vous créiez d’abord une connexion, mais de nombreux autres connecteurs nécessitent cette étape. Chaque connexion que vous créez est en fait une ressource Azure distincte qui fournit l’accès à l’application, au service, au système, au protocole ou à la plateforme cible.

Cependant, il se peut que vous souhaitiez dans certains cas appeler des API REST qui ne sont pas disponibles en tant que connecteurs créés au préalable. Pour prendre en charge des scénarios plus personnalisés, vous pouvez créer vos propres connecteurs personnalisés pour proposer des déclencheurs et des actions qui ne sont pas disponibles en tant qu’opérations prédéfinies.

Cet article fournit une vue d’ensemble des connecteurs personnalisés pour les workflows d’application logique Consommation et les workflows d’application logique standard. Chaque type d’application logique est alimenté par un runtime Azure Logic Apps différent, respectivement hébergé dans Azure multilocataire et Azure à locataire unique. Pour plus d’informations sur les connecteurs dans Azure Logic Apps, consultez la documentation suivante :

Applications logique Consommation

Dans Azure Logic Apps multilocataire, vous pouvez créer des connecteurs personnalisés à partir d’API Swagger ou SOAP jusqu’à des limites spécifiques pour une utilisation dans les workflows d’application logique Consommation. La Documentation sur les connecteurs fournit plus d’informations sur la création de connecteurs personnalisés pour les applications logiques Consommation, notamment des didacticiels de base et avancés. La liste suivante fournit également des liens directs vers des informations sur les connecteurs personnalisés pour les applications logiques Consommation :

Applications logiques Standard

Dans Azure Logic Apps à locataire unique, le runtime Azure Logic Apps repensé alimente les workflows d’application logique Standard. Ce runtime diffère du runtime Azure Logic Apps multilocataire qui alimente les workflows d’applications logiques Consommation. Le runtime monolocataire utilise le modèle d’extensibilité Azure Functions, qui fournit une fonctionnalité clé pour vous permettre de créer vos propres connecteurs intégrés pour toute personne utilisant des workflows Standard. Dans la plupart des cas, la version intégrée offre de meilleures performances, fonctionnalités, conditions tarifaires, et ainsi de suite.

Lors de la sortie d’Azure Logic Apps à locataire unique, les nouveaux connecteurs intégrés incluait Stockage Blob Azure, Azure Event Hubs, Azure Service Bus et SQL Server. Au fil du temps, cette liste de connecteurs intégrés continue de croître. Toutefois, si vous avez besoin de connecteurs qui ne sont pas disponibles dans les workflows d’application logique Standard, vous pouvez créer vos propres connecteurs intégrés à l’aide du même modèle d’extensibilité utilisé par des connecteurs intégrés basés sur un fournisseur de servicesdans les workflows Standard.

Connecteurs intégrés basés sur un fournisseur de services

Dans les Azure Logic Apps monolocataires, le connecteur intégré avec des attributs spécifiques est appelé fournisseurs de services de manière informelle. Par exemple, ces connecteurs sont basés sur le modèle d’extensibilité Azure Functions, ce qui vous permet de créer vos propres connecteurs intégrés personnalisés à utiliser dans les workflows d’application logique Standard.

En revanche, les connecteurs intégrés hors fournisseur de services ont les attributs suivants :

  • N’est pas basé sur le modèle d’extensibilité Azure Functions.

  • Est directement implémenté en tant que travail dans le runtime Azure Logic Apps, par exemple Planification, HTTP, Requête et Opérations XML.

Aucune fonctionnalité n’est actuellement disponible pour créer un connecteur intégré à un fournisseur hors services ou un nouveau type de travail qui s’exécute directement dans le runtime Azure Logic Apps. Toutefois, vous pouvez créer vos propres connecteurs intégrés à l’aide de l’infrastructure du fournisseur de services.

La section suivante fournit plus d’informations sur le fonctionnement du modèle d’extensibilité pour les connecteurs intégrés personnalisés.

Modèle d’extensibilité du connecteur intégré

En fonction du modèle d’extensibilité Azure Functions, le modèle d’extensibilité du connecteur intégré dans Azure Logic Apps à locataire unique dispose d’une infrastructure de fournisseur de services que vous pouvez utiliser pour créer, empaqueter, inscrire et installer vos propres connecteurs intégrés en tant qu’extensions Azure Functions que tout le monde peut utiliser dans ses flux de travail Standard. Ce modèle inclut des fonctionnalités de déclencheur intégrées personnalisées qui prennent en charge l’exposition d’un déclencheur ou d’une action Azure Functions en tant que déclencheur de fournisseur de services dans votre connecteur intégré personnalisé.

Le diagramme suivant montre les implémentations de méthode attendues par le concepteur et le runtime Azure Logic Apps pour un connecteur intégré personnalisé avec un déclencheur basé sur Azure Functions :

Diagramme conceptuel illustrant l’infrastructure de fournisseur de services basée sur Azure Functions.

Les sections suivantes fournissent plus d’informations sur les interfaces que votre connecteur doit implémenter.

IServiceOperationsProvider

Cette interface inclut les méthodes qui fournissent le manifeste des opérations pour votre connecteur intégré personnalisé.

  • Manifeste des opérations

    Le manifeste des opérations inclut des métadonnées sur les opérations implémentées dans votre connecteur intégré personnalisé. Le concepteur Azure Logic Apps utilise principalement ces métadonnées pour conduire les expériences de création et de supervision pour les opérations de votre connecteur. Par exemple, le concepteur utilise des métadonnées d’opération pour comprendre les paramètres d’entrée requis par une opération spécifique et faciliter la génération des jetons de propriété des sorties, en fonction du schéma des sorties de l’opération.

    Le concepteur nécessite et utilise les méthodes GetService() et GetOperations() pour interroger les opérations que votre connecteur fournit et affiche sur l’aire du concepteur. La méthode GetService() spécifie également les paramètres d’entrée de la connexion requis par le concepteur.

    Pour plus d’informations sur ces méthodes et leur implémentation, consultez la section Méthodes à implémenter plus loin dans cet article.

  • Appels d’opération

    Les appels d’opération sont les implémentations de méthode utilisées lors de l’exécution du workflows par le runtime Azure Logic Apps pour appeler les opérations spécifiées dans la définition de workflow.

    • Si votre déclencheur est un type de déclencheur Azure Functions, la méthode GetBindingConnectionInformation() est utilisée par le runtime dans Azure Logic Apps pour fournir les informations de paramètres de connexion requises pour la liaison de déclencheur Azure Functions.

    • Si votre connecteur a des actions, la méthode InvokeOperation() est utilisée par le runtime pour appeler chaque action dans votre connecteur qui s’exécute pendant l’exécution du workflow. Dans le cas contraire, vous n’avez pas besoin d’implémenter cette méthode.

Pour plus d’informations sur ces méthodes et leur implémentation, consultez la section Méthodes à implémenter plus loin dans cet article.

IServiceOperationsTriggerProvider

Les fonctionnalités de déclencheur intégrées personnalisées prennent en charge l’ajout ou l’exposition d’un déclencheur ou d’une action Azure Functions en tant que déclencheur de fournisseur de services dans votre connecteur intégré personnalisé. Pour utiliser le type de déclencheur basé sur Azure Functions et la même liaison Azure Functions que le déclencheur de connecteur managé Azure, implémentez les méthodes suivantes pour fournir les informations de connexion et les liaisons de déclencheur requises par Azure Functions.

  • La méthode GetFunctionTriggerType() est requise pour renvoyer la chaîne identique au paramètre de type dans la liaison de déclencheur Azure Functions.

  • La GetFunctionTriggerDefinition() a une implémentation par défaut. Vous n’avez donc pas besoin d’implémenter explicitement cette méthode. Toutefois, si vous souhaitez mettre à jour le comportement par défaut du déclencheur, par exemple fournir des paramètres supplémentaires que le concepteur n’expose pas, vous pouvez implémenter cette méthode et remplacer le comportement par défaut.

Méthodes à implémenter

Les sections suivantes fournissent plus d’informations sur les interfaces que votre connecteur doit implémenter. Pour obtenir l’exemple complet, passez en revue l’exemple CosmosDbServiceOperationProvider.cs et Créer des connecteurs intégrés personnalisés pour les applications logiques Standard dans des Azure Logic Apps à locataire unique.

Important

Quand vous avez des informations sensibles, comme des chaînes de connexion qui incluent des noms d’utilisateur et des mots de passe, veillez à utiliser le flux d’authentification le plus sécurisé disponible. Par exemple, Microsoft vous recommande d’authentifier l’accès aux ressources Azure avec une identité managée quand sa prise en charge est disponible et d’attribuer un rôle qui a le privilège minimum nécessaire.

Si cette fonctionnalité n’est pas disponible, veillez à sécuriser les chaînes de connexion via d’autres mesures, comme Azure Key Vault, que vous pouvez utiliser avec des paramètres d’application. Vous pouvez ensuite référencer directement des chaînes sécurisées, telles que des chaînes de connexion et des clés. Comme pour les modèles ARM, où vous pouvez définir des variables d’environnement au moment du déploiement, vous pouvez définir des paramètres d’application dans la définition de workflow de votre application logique. Vous pouvez ensuite capturer des valeurs d’infrastructure générées dynamiquement, comme des points de terminaison de connexion, des chaînes de stockage, etc. Pour plus d’informations, consultez Types d’application pour la plateforme d’identités Microsoft.

GetService()

Le concepteur nécessite cette méthode pour obtenir les métadonnées de haut niveau de votre service, notamment la description du service, les paramètres d’entrée de connexion, les fonctionnalités, la couleur de la marque, l’URL de l’icône et ainsi de suite.

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

Pour plus d’informations, consultez l’exemple CosmosDbServiceOperationProvider.cs.

GetOperations()

Le concepteur nécessite cette méthode pour obtenir les opérations implémentées par votre service. La liste des opérations est basée sur le schéma Swagger. Le concepteur utilise également les métadonnées d’opération pour comprendre les paramètres d’entrée pour des opérations spécifiques et générer les sorties en tant que jetons de propriété, en fonction du schéma de la sortie pour une opération.

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

Pour plus d’informations, consultez l’exemple CosmosDbServiceOperationProvider.cs.

GetBindingConnectionInformation()

Si vous souhaitez utiliser le type de déclencheur basé sur Azure Functions, cette méthode fournit les informations de paramètres de connexion requises pour la liaison de déclencheur Azure Functions.

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

Pour plus d’informations, consultez l’exemple CosmosDbServiceOperationProvider.cs.

InvokeOperation()

Si votre connecteur intégré personnalisé n’a qu’un déclencheur, vous n’avez pas besoin d’implémenter cette méthode. Toutefois, si votre connecteur a des actions à implémenter, vous devez implémenter la méthode InvokeOperation(), qui est appelée pour chaque action de votre connecteur qui s’exécute pendant l’exécution du flux de travail. Vous pouvez utiliser n’importe quel client, tel que FTPClient, HTTPClient, etc., comme requis par les actions de votre connecteur. Cet exemple utilise 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);
}

Pour plus d’informations, consultez l’exemple CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerType()

Pour utiliser un déclencheur Azure Functions en tant que déclencheur dans votre connecteur, vous devez retourner la chaîne identique au paramètre type dans la liaison de déclencheur Azure Functions.

L’exemple suivant retourne la chaîne pour le déclencheur de base de données Azure Cosmos intégré et opérationnel, "type": "cosmosDBTrigger":

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

Pour plus d’informations, consultez l’exemple CosmosDbServiceOperationProvider.cs.

GetFunctionTriggerDefinition()

Cette méthode est implémentée par défaut. Vous n’avez donc pas besoin d’implémenter explicitement cette méthode. Toutefois, si vous souhaitez mettre à jour le comportement par défaut du déclencheur, par exemple fournir des paramètres supplémentaires que le concepteur n’expose pas, vous pouvez implémenter cette méthode et remplacer le comportement par défaut.

Étapes suivantes

Lorsque vous êtes prêt à entamer les étapes d’implémentation, passez à l’article suivant :