À 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 propose une introduction aux connecteurs, leur fonctionnement général et les plus populaires ainsi que les plus couramment utilisés dans Azure Logic Apps. Pour plus d’informations, consultez la documentation suivante :

Qu’est-ce qu’un connecteur ?

Techniquement, un connecteur est 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.

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 workflow 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 autre action, pas nécessairement SQL, 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 multilocataire ou une application logique à locataire unique, qui n’est actuellement disponible que dans la Azure Logic Apps monolocataire.

Les déclencheurs et actions intégrés s’exécutent en mode natif sur le runtime Logic Apps, ne nécessitent pas la création de connexions, et effectuent ces types de tâches :

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. Les connecteurs managés sont disponibles dans les catégories suivantes :

Configuration de connexion

Pour créer ou gérer des ressources et des connexions d’application logique, vous avez besoin de certaines autorisations, qui sont fournies par le biais de rôles utilisant le contrôle d’accès en fonction du rôle (Azure RBAC). Vous pouvez attribuer des rôles intégrés ou personnalisés aux membres qui ont accès à votre abonnement Azure. Azure Logic Apps a ces rôles spécifiques :

  • Contributeur d’application logique : Permet de gérer des applications logiques, mais pas d’en modifier l’accès.

  • Opérateur d’application logique : Permet de lire, d’activer et de désactiver des applications logiques, mais pas de les modifier ni de les mettre à jour.

  • Contributeur : Accorde un accès total pour gérer toutes les ressources, mais ne vous permet pas d’affecter des rôles dans Azure RBAC, de gérer des affectations dans Azure Blueprints ou de partager des galeries d’images.

    Par exemple, supposez que vous devez utiliser une application logique que vous n’avez pas créée, et authentifier les connexions utilisées par le flux de travail de cette application logique. Votre abonnement Azure requiert des autorisations de Contributeur pour le groupe de ressources qui contient cette ressource d’application logique. Si vous créez une ressource d’application logique, vous bénéficiez automatiquement d’un accès Contributeur.

Avant de pouvoir utiliser les déclencheurs ou les actions d’un connecteur dans votre flux de travail, la plupart des connecteurs exigent que vous établissiez d’abord une connexion avec le service ou le système cible. Pour créer une connexion à partir d’un 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 un petit nombre d’opérations intégrées et de connecteurs managés, vous pouvez configurer et utiliser une identité managée pour l’authentification plutôt que de fournir vos informations d’identification.

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, le service 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.

Bien que les connexions soient créées à partir d’un workflow, 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, téléchargez votre application logique dans Visual Studio à partir d’Azure. C’est le moyen le plus simple de créer un modèle d’application logique paramétrisé, valide et dans l’ensemble prêt à être déployé.

Conseil

Si votre organisation ne vous autorise pas à accéder à des ressources spécifiques par le biais de connecteurs Logic Apps, vous pouvez bloquer la possibilité de créer ce genre de connexion avec 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 le service ou le runtime Logic Apps dans la région Azure où se trouvent vos workflows 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.

Comportement lié à la périodicité

Les déclencheurs intégrés récurrents, tels que le déclencheur Récurrence, s’exécutent sur le runtime Azure Logic Apps et diffèrent des déclencheurs récurrents basés sur les connexions, tels que le déclencheur de connecteur Office 365 Outlook, où vous devez d’abord créer une connexion.

Quel que soit le type de déclencheur, si aucune date/heure de début n’est spécifiée pour une périodicité, la première occurrence s’exécute dès l’enregistrement ou le déploiement de l’application logique, quelle que soit la configuration de périodicité de votre déclencheur. Pour éviter ce comportement, indiquez la date et l'heure de début de l'exécution de la première occurrence.

Périodicité des déclencheurs intégrés

Les déclencheurs intégrés récurrents respectent le calendrier que vous fixez, fuseaux horaires compris. Cela dit, si aucune autre option de planification avancée n’est spécifiée pour une périodicité, comme des heures précises pour l’exécution de futures occurrences, celles-ci sont basées sur la dernière exécution du déclencheur. Par conséquent, les heures de début de ces périodicités peuvent dériver en raison de facteurs tels que la latence lors des appels de stockage.

Pour plus d’informations, consultez la documentation suivante :

Périodicité des déclencheurs basés sur la connexion

Dans les déclencheurs récurrents basés sur des connexions, tels qu’Office 365 Outlook, la planification n’est pas le seul élément qui contrôle l’exécution. Le fuseau horaire détermine uniquement l’heure de début initiale. Les exécutions suivantes dépendent de la planification de la périodicité, de la dernière exécution du déclencheur et d'autres facteurs qui peuvent décaler les heures d'exécution ou produire un comportement inattendu, par exemple :

  • Accès ou non par le déclencheur à un serveur contenant d'autres données, que le déclencheur tente immédiatement d'extraire
  • Échecs ou nouvelles tentatives induites par le déclencheur
  • Latence lors des appels de stockage
  • Non-respect du calendrier fixé lors des passages à l'heure d'été et à l'heure d'hiver
  • Autres facteurs susceptibles d'avoir une incidence sur l'heure de l'exécution suivante

Pour plus d’informations, consultez la documentation suivante :

Résolution des problèmes de périodicité

Pour que votre workflow s’exécute à l’heure de début spécifiée et ne manque aucune périodicité, en particulier lorsque la fréquence est définie en jours ou sur une valeur plus longue, essayez les solutions suivantes :

  • Au moment du passage à l’heure d’été, ajustez la périodicité manuellement afin que votre workflow continue de s’exécuter à l’heure prévue. Sinon, l'heure de début est avancée d'une heure lors du passage à l'heure d'été et reculée d'une heure lors du passage à l'heure d'hiver. Pour plus d’informations et pour obtenir des exemples, consultez Périodicité pour l’heure d’été et l’heure d’hiver.

  • Si vous utilisez un déclencheur Périodicité, spécifiez un fuseau horaire et une date et une heure de début. Configurez également les heures spécifiques d’exécution des périodicités suivantes dans les propriétés Aux heures indiquées et Aux minutes indiquées, qui sont disponibles uniquement pour les fréquences Jour et Semaine. Certaines fenêtres temporelles peuvent néanmoins poser des problèmes lorsque l'heure change.

  • Utilisez un déclencheur Fenêtre glissante au lieu d’un déclencheur Récurrence pour éviter les périodicités manquées.

Connecteurs et API personnalisés

Pour appeler des API qui exécutent du code personnalisé ou qui ne sont pas disponibles en tant que connecteurs, vous pouvez étendre la plateforme Logic Apps en créant des applications API personnalisées. Vous pouvez également créer des connecteurs personnalisés pour n’importe quelle API REST ou SOAP, ce qui rend ces API disponibles pour n’importe quelle application logique dans votre abonnement Azure. Pour rendre les applications API ou les connecteurs personnalisés publics afin que tout le monde puisse les utiliser dans Azure, vous pouvez soumettre des connecteurs à la certification Microsoft.

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 Logic Apps, lorsque vous parcourez les déclencheurs et actions intégrés ou les connecteurs managés que vous souhaitez utiliser pour les applications logiques dans un environnement ISE, l’étiquette CORE apparaît sur les déclencheurs et les actions intégrés et l’étiquette ISE sur les connecteurs managés spécifiquement conçus pour fonctionner avec un environnement ISE.

Exemple de connecteur CORE

CORE

Les déclencheurs et les actions 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