Qu’est-ce que des connecteurs dans Azure Logic Apps

  • Article

Lorsque vous créez un flux de travail à l’aide d’Azure Logic Apps, vous pouvez utiliser un connecteur pour utiliser des données, des événements et des ressources dans d’autres applications, services, systèmes et plateformes, sans écrire de code. Un connecteur fournit une ou plusieurs opérations prédéfinies, que vous utilisez comme étapes dans votre flux de travail.

Dans un connecteur, chaque opération est une condition de déclencheur qui démarre un flux de travail ou une action ultérieure qui effectue une tâche spécifique, ainsi que des propriétés que vous pouvez configurer. Bien que de nombreux connecteurs aient à la fois des déclencheurs et des actions, certains connecteurs offrent uniquement des déclencheurs, tandis que d’autres fournissent uniquement des actions.

Dans Azure Logic Apps, les connecteurs sont disponibles dans une version intégrée, une version managée ou les deux. De nombreux connecteurs nécessitent généralement que vous créez et configurez d’abord une connexion au service ou au système sous-jacent, généralement afin de pouvoir authentifier l’accès à un compte d’utilisateur. Si aucun connecteur n’est disponible pour le service ou le système auquel vous souhaitez accéder, vous pouvez envoyer une requête à l’aide de l’opération HTTP générique ou créer un connecteur personnalisé.

Cette vue d’ensemble constitue une présentation générale des connecteurs et de leur fonctionnement général. Pour plus d’informations sur le connecteur, consultez la documentation suivante :

Connecteurs intégrés et connecteurs managés

Dans Azure Logic Apps, les connecteurs sont intégrés ou gérés. Certains connecteurs ont les deux versions. Les versions disponibles dépendent de la création d’un flux de travail d’application logique consommation qui s’exécute dans Azure Logic Apps multilocataire ou un flux de travail d’application logique standard qui s’exécute dans Azure Logic Apps à locataire unique. Pour plus d’informations sur les types de ressources d’application logique, consultez Les types de ressources et les différences d’environnement hôte.

  • Les connecteurs intégrés sont conçus pour s’exécuter directement et en mode natif dans Azure Logic Apps.

  • Les connecteurs managés sont déployés, hébergés et gérés dans Azure par Microsoft. Les connecteurs managés fournissent principalement un proxy ou un wrapper autour d’une API utilisée par le service ou le système sous-jacent pour communiquer avec Azure Logic Apps.

    • Dans un flux de travail Consommation, les connecteurs managés apparaissent dans le concepteur sous les étiquettes Standard ou Entreprise , en fonction de leur niveau tarifaire.

    • Dans un flux de travail Standard, tous les connecteurs managés apparaissent dans le concepteur sous l’étiquette Azure .

Pour plus d’informations, consultez la documentation suivante :

Déclencheurs

Un déclencheur spécifie la condition à respecter pour que le flux de travail puisse démarrer et est toujours la première étape de n’importe quel flux de travail. Chaque déclencheur suit également un modèle de déclenchement spécifique qui contrôle la façon dont le déclencheur surveille et répond aux événements. En règle générale, un déclencheur suit un modèle d’interrogation ou un modèle push. Parfois, les deux versions de déclencheur sont disponibles.

  • Les déclencheurs d’interrogation vérifient régulièrement un service ou un système spécifique selon une planification spécifiée, afin de savoir s’il existe de nouvelles données ou un événement spécifique. Si de nouvelles données sont disponibles ou si l’événement spécifique se produit, ces déclencheurs créent et exécutent une nouvelle instance de votre workflow. Cette nouvelle instance peut ensuite utiliser les données transmises comme entrée.

  • Les déclencheurs push ou webhook écoutent les nouvelles données ou pour qu’un événement se produise, sans interrogation. Lorsque de nouvelles données sont disponibles ou que l’événement se produit, ces déclencheurs créent et exécutent une nouvelle instance de votre workflow. Cette nouvelle instance peut ensuite utiliser les données transmises comme entrée.

Par exemple, supposons que vous souhaitiez générer un flux de travail qui s’exécute lorsqu’un fichier est chargé sur votre serveur FTP. Lors de la première étape de votre flux de travail, vous pouvez ajouter le déclencheur FTP nommé Lorsqu’un fichier est ajouté ou modifié, qui suit un modèle d’interrogation. Vous spécifiez ensuite la planification à case activée régulièrement pour les événements de chargement.

Lorsque le déclencheur se déclenche, le déclencheur transmet généralement les sorties d’événement pour que les actions suivantes référencent et utilisent. Pour l’exemple FTP, le déclencheur génère automatiquement des informations telles que le nom de fichier et le chemin d’accès. Vous pouvez également configurer le déclencheur pour inclure le contenu du fichier. Par conséquent, pour traiter ces données, vous devez ajouter des actions à votre flux de travail.

Actions

Une action spécifie une tâche à effectuer et apparaît toujours en tant qu’étape suivante dans le flux de travail. Vous pouvez utiliser plusieurs actions dans votre workflow. Par exemple, vous pouvez démarrer le flux de travail avec un déclencheur SQL Server qui case activée s pour les nouvelles données client dans une base de données SQL. Après le déclencheur, votre workflow peut avoir une action SQL Server qui obtient les données client. À la suite de cette action SQL Server, votre flux de travail peut utiliser une autre action qui traite les données, par exemple une action Opérations de données qui crée une table CSV.

Autorisations liées à la connexion

Dans un flux de travail d’application logique Consommation, avant de pouvoir créer ou gérer des ressources d’application logique, des flux de travail et leurs connexions, vous avez besoin d’autorisations spécifiques. Pour plus d’informations sur ces autorisations, consultez Opérations sécurisées : Accès sécurisé et données dans Azure Logic Apps.

création, configuration et authentification de Connecter ion

Avant de pouvoir utiliser les opérations d’un connecteur dans votre flux de travail, de nombreux connecteurs nécessitent de créer une connexion au service ou au système cible. Pour créer une connexion à partir du concepteur de flux de travail, vous devez authentifier votre identité avec les informations d’identification du compte et parfois d’autres informations de connexion.

Par exemple, pour permettre à votre workflow d’accéder à votre compte de messagerie Office 365 Outlook et l’utiliser, vous devez autoriser une connexion à ce compte. Pour certains connecteurs intégrés et connecteurs managés, vous pouvez configurer et utiliser une identité managée pour l’authentification plutôt que de fournir vos informations d’identification.

Bien que les connexions soient créées à partir d’un flux de travail, il s’agit de ressources Azure distinctes avec leurs propres définitions de ressource. Pour passer en revue ces définitions de ressources de connexion, procédez comme suit selon que vous disposez d’un flux de travail Consommation ou Standard :

Sécurité et chiffrement de la connexion

Les détails de configuration de la connexion (adresse du serveur, nom d’utilisateur, mot de passe, etc.), les informations d’identification et les secrets sont chiffrés et stockés dans l’environnement Azure sécurisé. Ces informations peuvent être utilisées uniquement dans les ressources d’application logique et par les clients qui ont des autorisations pour la ressource de connexion, ce qui est assuré par des contrôles de l’accès lié. Connecter ions qui utilisent Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), telles que Bureau 365, Salesforce et GitHub, nécessitent que vous vous connectiez, mais Azure Logic Apps stocke uniquement les jetons d’accès et d’actualisation en tant que secrets, et non les informations d’identification de connexion.

Les connexions établies peuvent accéder au service ou système cible aussi longtemps que ce dernier l’autorise. Pour les services qui utilisent des connexions Microsoft Entra ID OAuth, par exemple Office 365 et Dynamics, Azure Logic Apps actualise les jetons d’accès indéfiniment. D’autres services peuvent imposer des limites concernant la durée pendant laquelle Logic Apps peut utiliser un jeton sans actualisation. Certaines actions, telles que la modification de votre mot de passe, invalident tous les jetons d’accès.

Remarque

Si votre organisation ne vous autorise pas à accéder à des ressources spécifiques par le biais de connecteurs Azure Logic Apps, vous pouvez bloquer la capacité de créer ce type de connexion via Azure Policy.

Pour plus d’informations sur la sécurisation des flux de travail et des connexions d’applications logiques, consultez Sécuriser l’accès et les données dans Azure Logic Apps.

Accès au pare-feu pour les connexions

Si vous utilisez un pare-feu qui limite le trafic et que votre application logique doit communiquer via ce pare-feu, vous devez configurer votre pare-feu de manière à autoriser l’accès à la fois aux adresses IP entrantes et sortante utilisées par la plateforme ou le runtime Azure Logic Apps dans la région Azure où se trouvent vos flux de travail d’application logique.

Si vos flux de travail utilisent également des connecteurs managés, tels que le connecteur Bureau 365 Outlook ou le connecteur SQL, ou utilisez des connecteurs personnalisés, votre pare-feu doit également autoriser l’accès pour toutes lesadresses IP sortantes du connecteur managé dans la région Azure de votre ressource d’application logique. Pour plus d’informations, consultez configuration du pare-feu.

Connecteurs personnalisés et API

Dans les flux de travail Consommation pour Azure Logic Apps mutualisée, vous pouvez appeler des API basées sur Swagger ou SOAP qui ne sont pas disponibles en tant que connecteurs prêtes à l’emploi. Vous pouvez également exécuter un code personnalisé en créant des applications API personnalisées. Pour plus d’informations, consultez la documentation suivante :

Dans les flux de travail Standard pour Azure Logic Apps à locataire unique, vous pouvez créer des connecteurs intégrés personnalisés basés sur un fournisseur de services en mode natif qui sont disponibles pour n’importe quel flux de travail d’application logique standard. Pour plus d’informations, consultez la documentation suivante :

ISE et connecteurs

Pour les workflows qui ont besoin d’un accès direct aux ressources d’un réseau virtuel Azure, vous pouvez créer un ISE dédié vous permettant de générer, de déployer et d’exécuter vos workflows sur des ressources dédiées. Pour plus d’informations sur la création d’environnements ISE, consultez l’article Se connecter à des réseaux virtuels Azure à partir d’Azure Logic Apps.

Les connecteurs personnalisés créés au sein d’un ISE ne fonctionnent pas avec la passerelle de données locale. Toutefois, ces connecteurs peuvent accéder directement aux sources de données locales qui sont connectées à un réseau virtuel Azure hébergeant l’ISE. Par conséquent, les flux de travail d’application logique dans un environnement ISE n’ont probablement pas besoin de la passerelle de données lors de la communication avec ces ressources. Si vous avez des connecteurs personnalisés que vous avez créés en dehors d’un ISE qui nécessitent la passerelle de données locale, les flux de travail d’un ISE peuvent utiliser ces connecteurs.

Dans le concepteur de flux de travail, lorsque vous parcourez les connecteurs intégrés ou les connecteurs managés que vous souhaitez utiliser pour les flux de travail dans un ISE, l’étiquette CORE apparaît sur les connecteurs intégrés, tandis que l’étiquette ISE apparaît sur les connecteurs gérés conçus pour fonctionner avec un ISE.

Example CORE connector

CORE

Les connecteurs intégrés avec cette étiquette s’exécutent dans le même ISE que vos flux de travail.

Example ISE connector

ISE

Les connecteurs managés avec cette étiquette s’exécutent dans le même ISE que vos workflows.

Si vous disposez d’un système local connecté à un réseau virtuel Azure, l’environnement ISE permet à vos workflows d’accéder directement à ce système sans utiliser la passerelle de données locale. Au lieu de cela, vous pouvez utiliser le connecteur ISE du système s’il est disponible, une action HTTP ou un connecteur personnalisé.

Pour les systèmes locaux dépourvus de connecteurs ISE, utilisez la passerelle de données locale. Pour trouver les connecteurs ISE disponibles, consultez Connecteurs ISE.

Example non-ISE connector

Sans étiquette

Les connecteurs sans étiquette, qui peuvent toujours être utilisés, s’exécutent dans le service Logic Apps multilocataire global.

Problèmes connus

Le tableau suivant inclut des problèmes connus pour les connecteurs dans Azure Logic Apps :

Message d’erreur Description Résolution
Error: BadGateway. Client request id: '{GUID}' Cette erreur résulte de la mise à jour des balises sur une ressource d’application logique où une ou plusieurs connexions ne prennent pas en charge l’authentification OAuth d’ID Microsoft Entra, comme SFTP ad SQL, cassant ces connexions. Pour éviter ce comportement, évitez de mettre à jour ces étiquettes.

Étapes suivantes

Créer un flux de travail d’application logique Consommation - Portail Azure

Créer un flux de travail d’application logique standard - Portail Azure