Partager via


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

Lorsque vous créez un flux de travail à l’aide d’Azure Logic Apps, vous pouvez utiliser un connecteur pour travailler avec 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 un déclencheur condition qui démarre un flux de travail ou une action ultérieure qui effectue une tâche spécifique, ainsi que les propriétés que vous pouvez configurer. Si de nombreux connecteurs proposent à la fois des déclencheurs et des actions, certains ne proposent que des déclencheurs, tandis que d'autres ne proposent que 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éiez d’abord et configurer une connexion au service ou au système sous-jacent, généralement afin que vous puissiez 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 la opération HTTP générique, ou vous pouvez 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 managé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 d’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 différences entre les types de ressources et l’environnement hôte.

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

  • 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 envoi (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.

    Remarque

    Pour les connecteurs managés par Microsoft, hébergés et exécutés dans Azure, les déclencheurs d’interrogation utilisent uniquement les valeurs Intervalle et Fréquence pour calculer la périodicité suivante. Ils n’utilisent pas les options de planification avancées, telles que à ces heures et à ces jours. Ces options ne fonctionnent qu'avec les déclencheurs d'interrogation intégrés qui s'exécutent directement avec le moteur d'exécution Azure Logic Apps, tels que les déclencheurs Périodicité, Sliding Window, et HTTP.

  • Envoi (push) ou webhook déclenche l’écoute de 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 pour vérifier régulièrement les événements de chargement.

Lorsque le déclencheur se met en route, 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 vérifie les nouvelles données client dans une base de données SQL. Après le déclencheur, votre flux de travail 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 connexion

Avant de pouvoir utiliser les opérations d’un connecteur dans votre flux de travail, de nombreux connecteurs nécessitent de créer d’abord 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é. Les connexions qui utilisent Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), telles qu’Office 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’application logique, 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 Office 365 Outlook ou le connecteur SQL, ou utilisez des connecteurs personnalisés, votre pare-feu doit également autoriser l’accès pour toutes les adresses 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êts à 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 :

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 Microsoft Entra ID, comme SFTP ad SQL, cassant ces connexions. Pour éviter ce comportement, évitez de mettre à jour ces étiquettes.

Étapes suivantes