Détecter un événement externe à l’aide d’un déclencheur
Dans Azure Logic Apps, un déclencheur démarre toujours un workflow comme première étape. Pour exécuter correctement votre workflow, vous devez trouver le meilleur déclencheur et configurer les propriétés du déclencheur pour votre scénario. Pour notre exemple, nous allons utiliser un déclencheur Twitter qui exécute notre workflow lorsqu’un tweet avec le nom de notre produit est publié.
Dans cette unité, nous allons examiner les types de déclencheurs, ainsi que les forces et faiblesses des options les plus courantes. Nous verrons ensuite comment créer un workflow d’application logique en utilisant le portail Azure et comment ajouter un déclencheur avec le concepteur de workflows.
Types de déclencheurs
Tenez compte des différentes conditions de déclenchement que les entreprises peuvent utiliser pour exécuter leurs workflows d’application logique. La plupart des exemples que nous avons vus sont des déclencheurs qui détectent si des données ou un événement dans un service ou un système répondent à des conditions spécifiques. Par exemple, quand un nouveau tweet est posté, une nouvelle ligne est insérée dans une base de données, un nouvel e-mail arrive ou un nouveau fichier est chargé dans votre stockage cloud. Les déclencheurs qui détectent des données ou des événements peuvent utiliser l’une des techniques suivantes :
- Déclencheurs qui interrogent ou vérifient régulièrement un service ou un système pour y rechercher des données ou des événements spécifiques qui répondent aux conditions
- Déclencheurs qui attendent et reçoivent des notifications Push à partir d’un service ou d’un système lorsque des données ou des événements spécifiques répondent aux conditions
Toutefois, que se passe-t-il si vous avez besoin d’un déclencheur qui n’est pas lié aux données ou aux événements dans le service ou le système ? Supposons que vous souhaitiez exécuter votre workflow tous les samedis à minuit ou à une autre heure. Vous pouvez utiliser le déclencheur Périodicité pour planifier et exécuter toutes les actions dans un workflow. Par exemple, vous pouvez planifier des workflows qui effectuent des tâches administratives, telles que l’exécution de sauvegardes ou l’archivage d’anciennes données. Supposons que vous souhaitez exécuter votre workflow uniquement lorsqu’il est appelé à partir du code ou d’une autre source ? Vous pouvez utiliser le déclencheur Demande ou « manuel » pour attendre les demandes, par exemple, envoyées à partir du code dans votre application web ou votre application mobile.
Le diagramme suivant récapitule les types de déclencheurs précédemment décrits :
Les sections suivantes contiennent plus d’informations sur les déclencheurs d’interrogation et les déclencheurs d’émission.
Qu’est-ce qu’un déclencheur d’interrogation ?
Un déclencheur d’interrogation vérifie régulièrement un service ou un système pour y rechercher des données ou un événement répondant à des conditions spécifiques. Après cette vérification, si le déclencheur trouve des données ou un événement qui répond aux conditions, il démarre une nouvelle exécution de workflow. Par exemple, le connecteur RSS dispose d’un déclencheur d’interrogation qui peut régulièrement rechercher de nouvelles publications dans un flux RSS.
Quand vous ajoutez un déclencheur d’interrogation à votre workflow, vous définissez la fréquence et un intervalle pour contrôler la fréquence d’exécution du déclencheur. La fréquence est une unité de temps, telle que Seconde, Minute, Heure, Jour, Semaine ou Mois. L’intervalle est le nombre d’unités de temps qui expirent avant que le déclencheur vérifie à nouveau les données ou un événement. Par exemple, un déclencheur d’interrogation avec une fréquence Minute et un intervalle 5 effectue une vérification toutes les cinq minutes.
Les déclencheurs d’interrogation vous obligent à choisir entre la fréquence à laquelle les déclencheurs s’exécutent et leur coût. Il y a souvent un délai entre le moment où de nouvelles données ou de nouveaux événements se produisent et le moment où le déclencheur détecte ces données ou événements. Par exemple, supposons qu’un déclencheur d’interrogation vérifie les données toutes les cinq minutes. De nouvelles données sont disponibles au bout de sept minutes. Le déclencheur ne détecte pas les nouvelles données avant l’interrogation suivante, qui se produit à 10 minutes. Le diagramme suivant montre comment fonctionne cette interrogation :
Dans le pire des cas, le délai potentiel de détection de nouvelles données est égal à l’intervalle d’interrogation. Alors pourquoi ne pas utiliser un intervalle plus petit ? Pour vérifier s’il existe de nouvelles données, le moteur d’exécution Azure Logic Apps a besoin d’exécuter votre workflow, ce qui génère des frais. En règle générale, plus l’intervalle est court, plus le coût est élevé, mais le déclencheur répond plus rapidement aux nouvelles données ou aux nouveaux événements. Le meilleur intervalle d’interrogation pour votre déclencheur dépend de votre processus métier et de sa tolérance aux retards.
Qu’est-ce qu’un déclencheur d’émission ?
Un déclencheur d’émission attend les notifications d’un service ou d’un système lorsque des données ou un événement répondent à des conditions spécifiques. Le déclencheur s’abonne à un point de terminaison sur un service ou un système externe. Lorsque de nouvelles données ou un événement répondent aux conditions, le service ou le système avertit le déclencheur, ce qui démarre immédiatement une nouvelle exécution de workflow. Par exemple, le connecteur Azure Service Bus a un déclencheur d’émission qui détecte lorsqu’un message est ajouté à une file d’attente Azure Service Bus.
Notes
Les déclencheurs d’émission utilisent des webhooks, ce qui leur permet de s’abonner au système ou service externe. Au moment de l’abonnement, Azure Logic Apps génère une URL de rappel pour le déclencheur et inscrit l’URL auprès du système ou service externe. De même, Azure Logic Apps se désinscrit et désinscrit l’URL de rappel lorsque vous n’avez plus besoin de l’abonnement, par exemple si vous désactivez ou supprimez votre workflow.
Côté positif, les déclencheurs d’émission ne s’exécutent pas quand aucune donnée ou aucun événement n’est disponible. Ils n’entraînent donc pas de coûts d’interrogation. Ces déclencheurs répondent également immédiatement lorsque de nouvelles données ou événements existent. Le diagramme suivant montre comment fonctionne ce processus d’émission :
Pourquoi ne pas utiliser les déclencheurs d’émission tout le temps puisqu’ils répondent plus rapidement et sont moins coûteux que les déclencheurs d’interrogation ? Malheureusement, tous les connecteurs n’offrent pas un déclencheur d’émission. Le service externe peut ne pas prendre en charge les déclencheurs d’émission, ou peut-être que l’auteur du connecteur n’a pas choisi d’implémenter un déclencheur d’émission. En général, un connecteur propose soit des déclencheurs d’interrogation, soit des déclencheurs d’émission, mais pas les deux. Dans de rares cas où un connecteur offre les deux options, envisagez d’utiliser le déclencheur d’émission qui offre une meilleure efficacité.
Dans ce module, nous allons nous concentrer sur les déclencheurs d’interrogation. Ces déclencheurs sont les plus courants et conviennent parfaitement dans les scénarios de « routage et traitement de données » que nous avons décrits.
Paramètres de déclencheur et valeurs renvoyées
Vous pouvez considérer les opérations de déclencheur comme des appels de fonction qui ont des paramètres et des valeurs renvoyées. Les paramètres de déclencheur vous permettent de configurer l’opération. Le déclencheur Twitter nommé Lorsqu’un nouveau tweet est publié a un paramètre appelé Texte de recherche. Le déclencheur utilise ce paramètre pour sélectionner les tweets correspondants à notre recherche. Certaines opérations utilisent à la fois des paramètres obligatoires et facultatifs. Le déclencheur SQL Server nommé Lorsqu’un élément est créé a un seul paramètre obligatoire nommé Nom de la table et plusieurs paramètres facultatifs comme Trier par et Sélectionner une requête.
Les valeurs renvoyées des déclencheurs sont les résultats de l’opération. Par exemple, le connecteur Bitbucket a un déclencheur nommé Lorsqu’une demande de tirage est fusionnée. Le déclencheur retourne un objet qui contient des données, telles que l’identité du référentiel et l’intervenant qui a approuvé la fusion. La plupart des déclencheurs retournent en fait une collection d’objets, plutôt qu’un seul objet. Par exemple, le déclencheur Twitter nommé Lors de la publication d’un nouveau tweet retourne un tableau d’objets TweetModel. Chaque objet contient des valeurs comme le texte du tweet, le nom d’utilisateur et le nombre d’abonnés. Le diagramme suivant montre une collection retournée à partir d’un déclencheur :
Vous pouvez utiliser une boucle pour traiter chaque élément ou configurer le déclencheur pour qu’il fractionne le tableau pour traitement. Pour la plupart des déclencheurs, notamment le déclencheur Twitter, le comportement par défaut consiste à fractionner automatiquement le tableau. Le moteur Azure Logic Apps crée une instance de workflow pour chaque élément, et toutes les instances s’exécutent en parallèle. Le diagramme suivant montre comment chaque élément du tableau retourné passe à une instance de workflow différente pour le traitement :
Créer un workflow d’application logique dans le portail Azure
Dans le portail Azure, recherchez et sélectionnez le type de ressource Application logique, puis fournissez des informations sur la ressource, telles que le nom, l’abonnement, le groupe de ressources et l’emplacement. Une fois le déploiement terminé, vous pouvez accéder à la ressource d’application logique.
Lorsque vous ouvrez votre nouvelle ressource d’application logique, une page « prise en main » est affichée. Cette page inclut des déclencheurs couramment utilisés et une galerie de modèles avec des modèles de workflow courants et des types d’application. Par exemple, vous pouvez trouver des modèles de workflow comme Publier dans Slack un nouveau tweet correspondant à un hashtag et Recevez des rappels quotidiens par courrier électronique.
Dans la page « prise en main », vous pouvez sélectionner un déclencheur commun à ajouter à votre workflow, ou sélectionner un modèle pour générer un workflow complet. Si un modèle correspond à votre scénario, vous pouvez gagner du temps dans la configuration de votre application. Pour effectuer tout le travail vous-même, vous pouvez sélectionner le modèle Application logique vide.
Une fois que vous avez sélectionné un modèle, le concepteur de workflow s’ouvre automatiquement pour vous.
Ajouter un déclencheur à l’aide du concepteur
Le concepteur de workflow affiche une galerie de connecteurs avec les déclencheurs et les actions que vous pouvez utiliser dans votre workflow. En règle générale, lorsque vous commencez par un workflow vide, vous utilisez la zone de recherche pour trouver un connecteur qui vous intéresse. Ensuite, vous passez en revue tous les déclencheurs que le connecteur fournit. Dans notre exemple, nous sélectionnons le déclencheur Twitter nommé Lorsqu’un nouveau tweet est publié. Pour Twitter, nous devons également créer une connexion en nous connectant à notre compte Twitter.
Après avoir ajouté un déclencheur et créé une connexion au service ou au système si nécessaire, le concepteur affiche les propriétés du déclencheur. Pour Twitter, nous allons définir les paramètres Texte de recherche, Fréquence et Intervalle. La capture d’écran suivante montre le workflow de l’application logique de surveillance des réseaux sociaux dans le concepteur où le déclencheur Twitter est la première étape.
