À propos des connecteurs dans Azure Logic Apps

Lorsque vous générez des workflows à l’aide de Azure Logic Apps, vous pouvez utiliser des connecteurs pour accéder rapidement et facilement à des données, des événements et des ressources dans d’autres applications, services, systèmes, protocoles et plateformes, souvent sans écrire de code. Un connecteur fournit des opérations prédéfinies que vous pouvez utiliser comme étapes dans vos workflows. Azure Logic Apps fournit des centaines de connecteurs que vous pouvez utiliser. Si aucun connecteur n’est disponible pour la ressource à laquelle vous souhaitez accéder, vous pouvez utiliser l’opération HTTP générique pour communiquer avec le service 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.

Qu’est-ce qu’un connecteur ?

Techniquement, de nombreux connecteurs fournissent un proxy ou un wrapper autour d’une API que le service sous-jacent utilise pour communiquer avec Azure Logic Apps. Ce connecteur fournit des opérations que vous utilisez dans vos workflows pour effectuer des tâches. Une opération est disponible dans un déclencheur ou une action avec des propriétés que vous pouvez configurer. Certains déclencheurs et actions nécessitent également la création et la configuration d’une connexion en premier lieu au service ou au système sous-jacent, par exemple, pour vous permettre d’authentifier l’accès à un compte d’utilisateur. Pour plus d’informations générales, consultez Présentation des connecteurs pour Azure Logic Apps, Microsoft Power Automate et Microsoft Power Apps.

Pour plus d’informations sur les connecteurs les plus populaires et les plus couramment utilisés dans Azure Logic Apps, consultez la documentation suivante :

Déclencheurs

Un déclencheur spécifie l’événement qui démarre le workflow et constitue toujours la première étape d’un workflow. 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 le modèle d'interrogation ou d’émission , mais il peut parfois être disponible dans les deux versions.

  • 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 sont à l’écoute de nouvelles données ou d’un événement, 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, vous souhaiterez peut-être créer un workflow qui effectue une opération lorsqu’un fichier est chargé sur votre serveur FTP. En guise de première étape de votre worflow, vous pouvez utiliser le déclencheur FTP nommé Lors de l’ajout ou de la modification d’un fichier, qui suit le modèle d’interrogation. et ensuite spécifier une planification afin de vérifier régulièrement les événements de chargement.

Un déclencheur transmet également les entrées et autres données requises dans votre workflow, où des actions ultérieures peuvent référencer et utiliser ces données dans l’ensemble du workflow. Supposons, par exemple, que vous souhaitiez utiliser le déclencheur Office 365 Outlook nommé Quand un nouvel e-mail arrive pour démarrer un workflow lorsque vous recevez un nouvel e-mail. Vous pouvez configurer ce déclencheur afin qu’il transmette le contenu de chaque nouvel e-mail, tel que l’expéditeur, la ligne d’objet, le corps, les pièces jointes, et ainsi de suite. Votre workflow peut ensuite traiter ces informations à l’aide d’autres actions.

Actions

Une action est une opération qui suit le déclencheur et effectue un certain type de tâche dans votre workflow. Vous pouvez utiliser plusieurs actions dans votre workflow. Par exemple, vous pouvez démarrer le flux de travail avec un déclencheur SQL qui détecte les nouvelles données client dans une base de données SQL. Après le déclencheur, votre workflow peut intégrer une action SQL qui obtient les données client. Après l’action SQL, votre workflow peut intégrer une action différente qui traite les données.

Catégories de connecteurs

Dans Azure Logic Apps, la plupart des déclencheurs et des actions sont disponibles dans une version intégrée ou une version de connecteur managé. Peu de déclencheurs et d’actions sont disponibles dans les deux versions. Les versions disponibles varient selon que vous créez une application logique Consommation qui s’exécute dans Azure Logic Apps multilocataires ou une application logique Standard qui s’exécute dans Azure Logic Apps à locataire unique.

  • Les connecteurs intégrés s’exécutent en mode natif sur le runtime Azure Logic Apps.

  • Les connecteurs managés sont déployés, hébergés et managés par Microsoft. Ces connecteurs fournissent des déclencheurs et des actions pour les services cloud, les systèmes locaux, ou les deux.

    Dans une application logique Standard, tous les connecteurs managés sont organisés en tant que connecteurs Azure. Toutefois, dans une application logique Consommation, les connecteurs managés sont organisés en tant que Standard ou Entreprise, en fonction du niveau tarifaire.

Pour plus d’informations sur les types d’applications logiques, consultez Différences entre les types de ressource et l’environnement hôte.

Configuration de connexion

Dans les applications logiques Consommation, vous avez besoin d’autorisations spécifiques pour pouvoir créer ou gérer des applications logiques et leurs connexions. Pour plus d’informations sur ces autorisations, consultez Opérations sécurisées : sécuriser l’accès et les données dans Azure Logic Apps.

Avant de pouvoir utiliser les déclencheurs ou les actions d’un connecteur managé dans votre flux de travail, de nombreux connecteurs exigent 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 d’application logique, 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’une application logique 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 Azure Active Directory Open Authentication (Azure AD OAuth), comme 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 OAuth Azure AD, tels qu’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.

Conseil

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 connexions et des 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 workflows utilisent également des connecteurs managés, comme le connecteur Office 365 Outlook ou le connecteur SQL, ou des connecteurs personnalisés, votre pare-feu doit aussi autoriser l’accès pour toutes les adresses IP sortantes de connecteur managé dans la région Azure de votre application logique. Pour plus d’informations, consultez Configuration du pare-feu.

Connecteurs personnalisés et API

Dans les applications logiques Consommation qui s’exécutent dans des Azure Logic Apps multilocataires, vous pouvez appeler des API basées sur Swagger ou basées sur 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 applications logiques Standard qui s’exécutent dans des Azure Logic Apps monolocataires, 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 toute 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 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 applications logiques d’un ISE n’ont généralement pas besoin de la passerelle de données lorsqu’elles communiquent avec ces ressources. Si vous avez des connecteurs personnalisés créés hors d’un ISE qui ont besoin de la passerelle de données locale, les applications logiques d’un ISE peuvent utiliser ces connecteurs.

Dans le Concepteur de flux de travail, quand vous parcourez les connecteurs intégrés ou managés que vous souhaitez utiliser pour les applications logiques dans un environnement ISE, l’étiquette CORE apparaît sur les connecteurs intégrés, tandis que l’étiquette ISE apparaît sur les connecteurs managés qui sont spécifiquement conçus pour fonctionner avec un environnement ISE.

Exemple de connecteur CORE

CORE

Les connecteurs intégrés portant cette étiquette s’exécutent dans le même environnement ISE que vos applications logiques.

Exemple de connecteur ISE

ISE

Les connecteurs managés portant cette étiquette s’exécutent dans le même environnement ISE que vos applications logiques.

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.

Exemple de connecteur non-ISE

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 répertorie les problèmes connus liés aux connecteurs Logic Apps.

Message d’erreur Description Résolution
Error: BadGateway. Client request id: '{GUID}' Cette erreur est due à la mise à jour des étiquettes sur une application logique dans laquelle une ou plusieurs connexions ne prennent pas en charge l’authentification OAuth Azure Active Directory (Azure AD), telle que SFTP et SQL, entraînant une rupture de ces connexions. Pour éviter ce comportement, évitez de mettre à jour ces étiquettes.

Étapes suivantes