Différences entre les applications logiques monolocataires standard et les applications logiques multilocataires consommation

Azure Logic Apps est une plateforme cloud pour la création et l’exécution de workflows d’application logique automatisés qui intègrent vos applications, données, services et systèmes. Avec cette plateforme, vous pouvez rapidement développer des solutions d’intégration hautement scalables pour vos scénarios d’entreprise et B2B (Business to business). Lorsque vous créez une ressource d’application logique, vous sélectionnez l’option d’hébergement Consommation ou Standard. Une application logique consommation ne peut avoir qu’un seul flux de travail qui s’exécute dans multi-locataire Azure Logic Apps. Une application logique standard peut avoir un ou plusieurs flux de travail qui s’exécutent dans un monolocataire Azure Logic Apps ou app Service Environment v3 (ASE v3).

Avant de choisir la ressource d’application logique à créer, passez en revue le guide suivant pour savoir comment les types de flux de travail d’application logique sont comparés entre eux. Vous pouvez ensuite choisir le flux de travail d’application logique et l’environnement qui conviennent le mieux à votre scénario, aux exigences de votre solution et à la destination où vous souhaitez déployer et exécuter vos flux de travail.

Si vous débutez avec Azure Logic Apps, consultez Qu’est-ce qu’Azure Logic Apps ? et Qu’est-ce qu’un flux de travail d’application logique ?.

Types de flux de travail d’application logique et environnements

Le tableau suivant résume les différences entre un flux de travail d’application logique consommation et flux de travail d’application logique standard. Vous découvrez également comment l’environnement monolocataire diffère de l’environnement mutualisé pour le déploiement, l’hébergement et l’exécution de vos flux de travail.

Application logique Standard et flux de travail

L’application logique Standard et son flux de travail reposent sur le runtime Azure Logic Apps monolocataire remanié. Ce runtime utilise le modèle d’extensibilité d’Azure Functions et est hébergé en tant qu’extension sur le runtime d’Azure Functions. Cette conception offre une portabilité, une flexibilité et des performances accrues pour vos flux de travail d’application logique, ainsi que d’autres fonctionnalités et avantages hérités de la plateforme Azure Functions et de l’écosystème Azure App Service. Par exemple, vous pouvez créer, déployer et exécuter des applications logiques monolocataires et leurs flux de travail dans Azure App Service Environment v3 (plans Windows uniquement).

L’application logique Standard introduit une structure de ressources capable d’héberger plusieurs flux de travail, comme la façon dont une application de fonction Azure peut héberger plusieurs fonctions. Avec un mappage de 1 à plusieurs, les workflows dans la même application logique et le même client partagent les ressources de calcul et de traitement, ce qui améliore les performances en raison de leur proximité. Cette structure diffère de la ressource d’application logique Consommation où vous avez un mappage 1 à 1 entre une ressource d’application logique et un flux de travail.

Pour en savoir plus sur la portabilité, la flexibilité et les améliorations des performances, consultez les sections suivantes. Pour plus d’informations sur le runtime Azure Logic Apps monolocataire et l’extensibilité d’Azure Functions, consultez la documentation suivante :

• Azure Logic Apps s’exécutant partout – Présentation approfondie du runtime
• Présentation d’Azure Functions
• Azure Functions triggers and bindings (Déclencheurs et liaisons Azure Functions)

Portabilité et flexibilité

Lorsque vous créez une application logique Standard et son flux de travail, vous pouvez déployer et exécuter vos flux de travail dans d’autres environnements, tels qu’Azure App Service Environment v3 (plans Windows uniquement). Si vous utilisez Visual Studio Code avec l’extension Azure Logic Apps (Standard), vous pouvez développer, générer et exécuter localement votre flux de travail dans votre environnement de développement sans avoir à effectuer de déploiement sur Azure. Si votre scénario requiert des conteneurs, vous pouvez créer des applications logiques monolocataires en utilisant Logic Apps activé par Azure Arc. Pour plus d’informations, consultez Qu’est-ce que Logic Apps activé par Azure Arc ?

Ces fonctionnalités offrent des améliorations majeures et des avantages substantiels par rapport au modèle multilocataire, ce qui vous oblige à développer sur une ressource en cours d’exécution existante dans Azure. Le modèle multilocataire permettant d’automatiser la consommation, le déploiement de ressources d’application logique est basé sur des modèles Azure Resource Manager (modèles ARM), qui combinent et gèrent l’approvisionnement des ressources pour les applications et l’infrastructure.

Avec les ressources d’application logique Standard, le déploiement devient plus facile, car vous pouvez séparer le déploiement d’applications du déploiement de l’infrastructure. Vous pouvez empaqueter le runtime et les workflows d’une instance Azure Logic Apps monolocataire dans le cadre de votre ressource ou projet d’application logique. Vous pouvez utiliser des étapes ou des tâches génériques qui génèrent, assemblent et compressent vos ressources d’application logique dans des artefacts prêts à être déployés. Pour déployer votre infrastructure, vous pouvez toujours utiliser des modèles ARM pour approvisionner séparément ces ressources avec d’autres processus et pipelines que vous utilisez à ces fins.

Pour déployer votre application, copiez les artefacts dans l’environnement hôte, puis démarrez vos applications pour exécuter vos workflows. Ou bien, intégrez vos artefacts dans des pipelines de déploiement à l’aide des outils et processus que vous connaissez et utilisez déjà. De cette façon, vous pouvez déployer à l’aide des outils de votre choix, quelle que soit la pile de technologies que vous utilisez pour le développement.

Avec les options de génération et de déploiement standard, vous pouvez vous concentrer sur le développement d’applications séparément du déploiement d’infrastructure. Ainsi, vous obtenez un modèle de projet plus générique dans lequel vous pouvez appliquer de nombreuses options de déploiement similaires ou identiques à celles que vous utilisez pour une application générique. Vous bénéficiez également d’une expérience plus cohérente lorsque vous générez des pipelines de déploiement pour vos applications et lorsque vous exécutez les tests et validations requis avant de publier en production.

Performances

Avec l’application logique Standard, vous pouvez créer et exécuter plusieurs flux de travail dans la même ressource d’application logique et le même locataire. Avec ce mappage de type 1-à-plusieurs, ces workflows partagent des ressources, telles que le calcul, le traitement, le stockage et le réseau, offrant de meilleures performances en raison de leur proximité.

Les ressources d’application logique Standard et le runtime Azure Logic Apps monolocataire offrent une autre amélioration significative en rendant les connecteurs managés plus populaires disponibles en tant qu’opérations de connecteur intégrées. Par exemple, vous pouvez utiliser des opérations de connecteur intégrées pour Azure Service Bus, Azure Event Hubs, SQL Server et autres. Dans le même temps, les versions du connecteur managé sont toujours disponibles et continuent de fonctionner.

Lorsque vous utilisez les nouvelles opérations de connecteur intégrées, vous créez des connexions appelées connexions intégrées ou connexions de fournisseur de services. Leurs équivalents en connexion managée sont appelés connexions d’API. Elles sont créées et exécutées séparément en tant que ressources Azure que vous devez également déployer à l’aide de modèles ARM. Les opérations intégrées et leurs connexions s’exécutent localement dans le même processus que celui qui exécute vos workflows. Les deux sont hébergées sur le runtime Azure Logic Apps monolocataire. Par conséquent, les opérations intégrées et leurs connexions offrent de meilleures performances en raison de la proximité de vos workflows. Cette conception fonctionne également bien avec les pipelines de déploiement, car les connexions du fournisseur de services sont empaquetées dans le même artefact de build.

Résidence des données

Les ressources d’application logique Standard sont hébergées dans une instance Azure Logic Apps monolocataire, qui ne stocke, ne traite ni ne réplique les données en dehors de la région où vous déployez ces ressources d’application logique, ce qui signifie que les données de vos flux de travail restent dans la région où vous créez et déployez leurs ressources parentes.

Accès direct aux ressources dans les réseaux virtuels Azure

Les flux de travail s’exécutant dans une instance Azure Logic Apps monolocataire peuvent accéder directement à des ressources sécurisées telles que des machines virtuelles, d’autres services et des systèmes qui se trouvent à l’intérieur d’un réseau virtuel Azure.

Azure Logic Apps à locataire unique est une instance dédiée du service Azure Logic Apps, utilise des ressources dédiées et s’exécute séparément d’Azure Logic Apps à locataire multiple. L’exécution de flux de travail dans une instance dédiée aide à réduire l’impact que d’autres locataires Azure peuvent avoir sur le niveau de performance des applications. Cet impact est également appelé effet « voisins bruyants ».

Azure Logic Apps monolocataire offrent également les avantages suivants :

• Vos propres adresses IP statiques, qui sont séparées des adresses IP statiques partagées par les applications logiques dans Azure Logic Apps multilocataire. Vous pouvez également configurer une adresse IP sortante publique, statique et prévisible pour communiquer avec les systèmes de destination. De cette façon, vous n’avez pas besoin de configurer d’ouvertures de pare-feu supplémentaires sur ces systèmes de destination.

• Des limites accrues quant à la durée d’exécution, la conservation du stockage, le débit, le délai d’attente des requêtes et réponses HTTP, la taille des messages et les requêtes de connecteur personnalisé. Pour plus d’informations, consultez Limites et configuration pour Azure Logic Apps.

Options de création, de génération et de déploiement

Pour créer une ressource d’application logique basée sur l’environnement souhaité, vous avez plusieurs options, par exemple :

Environnement monolocataire

Environnement multilocataire

Bien que vos expériences de développement diffèrent selon que vous créez des ressources d’application logique Consommation ou Standard, vous pouvez rechercher et accéder à toutes vos applications logiques déployées dans votre abonnement Azure.

Par exemple, dans le portail Azure, la page Applications logiques affiche à la fois les ressources Consommation et Standard. Dans Visual Studio Code, les applications logiques déployées apparaissent sous votre abonnement Azure, mais les applications logiques Consommation apparaissent dans la fenêtre Azure sous l’extension Azure Logic Apps (Consommation), tandis que les applications logiques Standard apparaissent sous la section Ressources .

Workflows avec état et sans état

Dans une application logique Standard, vous pouvez créer les types de flux de travail suivants :

• Avec état

  Créez un workflow avec état lorsque vous devez conserver, examiner ou référencer des données d’événements précédents. Ces workflows enregistrent toutes les entrées, sorties et états des opérations dans le stockage externe. Ces informations permettent d’examiner les détails et l’historique de l’exécution du workflow une fois l’exécution terminée. Les workflows avec état offrent une haute résilience en cas d’interruption. Une fois les services et systèmes restaurés, vous pouvez reconstituer les exécutions interrompues à partir de l’état enregistré et réexécuter les workflows jusqu’à leur terme. Les workflows avec état peuvent continuer à s’exécuter plus longtemps que les workflows sans état.

  Par défaut, les flux de travail avec état dans Azure Logic Apps multilocataire et monolocataire s’exécutent de manière asynchrone. Toutes les actions basées sur HTTP suivent le modèle d’opération asynchronestandard. Après l’appel d’une action HTTP ou l’envoi d’une requête à un point de terminaison, un service, un système ou une API, le récepteur de la requête retourne immédiatement la réponse « 202 ACCEPTED ». Ce code confirme que le récepteur a accepté la requête, mais indique qu’il n’a pas terminé le traitement. La réponse peut inclure un location en-tête qui spécifie l’URI et un ID d’actualisation que l’appelant peut utiliser pour interroger ou vérifier l’état de la demande asynchrone jusqu’à ce que le récepteur arrête le traitement et retourne une réponse de réussite « 200 OK » ou une autre réponse non-202. Toutefois, l’appelant n’a pas besoin d’attendre la fin du traitement de la requête et peut exécuter l’action suivante. Pour plus d’informations, consultez L’intégration asynchrone des microservices permet l’autonomie des microservices.

• Sans état

  Créez un workflow sans état lorsque vous n’avez pas besoin de conserver, d’examiner ou de référencer des données d’événements précédents dans un stockage externe après chaque exécution pour les consulter ultérieurement. Ces workflows enregistrent toutes les entrées et les sorties pour chaque action et leurs états uniquement en mémoire, et non dans un stockage externe. Par conséquent, les workflows sans état offrent des temps d’exécution plus courts généralement inférieurs à cinq minutes, des performances plus rapides avec des temps de réponse plus courts, un débit plus élevé, et des coûts d’exécution réduits, car le stockage externe n’enregistre pas les détails et l’historique d’exécution du workflow. Toutefois, en cas de panne, les exécutions interrompues ne sont pas automatiquement restaurées, de sorte que l’appelant doit relancer manuellement les exécutions interrompues.

  Un workflow sans état offre les meilleures performances lors de la gestion des données ou du contenu, tel qu’un fichier, dont la taille totale ne dépasse pas 64 Ko, comme un fichier. Des tailles de contenu plus volumineuses, telles que plusieurs pièces jointes imposantes, peuvent ralentir considérablement les performances de votre workflow ou même provoquer le blocage de votre workflow en raison d’exceptions de mémoire insuffisante. Si votre workflow peut être amené à gérer des tailles de contenu supérieures, utilisez un workflow avec état à la place.

  Remarque

  Dans les flux de travail sans état, vous pouvez uniquement utiliser des déclencheurs Push où vous ne spécifiez pas de planification pour l’exécution de votre flux de travail. Ces déclencheurs webhooks attendent qu’un événement se produise ou que des données soient disponibles. Par exemple, le déclencheur périodicité est disponible uniquement pour les flux de travail avec état. Pour démarrer votre workflow, sélectionnez un déclencheur Push, tel que le déclencheur de demande, Event Hubs ou Service Bus. Pour plus d’informations sur les déclencheurs, actions et connecteurs limités, non disponibles ou non pris en charge, consultez Capacités modifiées, limitées, non disponibles ou non prises en charge.

  Les workflows sans état s’exécutant uniquement de façon synchrone, ils n’utilisent pas le modèle d’opération asynchrone standard utilisé par les workflows avec état. Au lieu de cela, toutes les actions basées sur HTTP qui retournent une réponse « 202 ACCEPTÉ » passent à l’étape suivante de l’exécution du workflow. Si la réponse comprend un location en-tête, un flux de travail sans état n’interrogera pas l’URI spécifié pour vérifier l’état. Pour suivre le modèle d’opération asynchrone standard, utilisez un flux de travail avec état à la place.

  Pour faciliter le débogage, vous pouvez activer l’historique des exécutions pour un workflow sans état (ce qui a un certain impact sur les performances), puis le désactiver lorsque vous avez terminé. Pour plus d’informations, consultez Créer des flux de travail basés sur un locataire dans Visual Studio Code ou Créer des flux de travail basés sur un locataire dans le portail Azure.

Résumé des différences entre les workflows avec état et sans état

Différences de comportement imbriqué entre les workflows avec état et sans état

Vous pouvez faire en sorte qu’un flux de travail puisse être appelé à partir d’autres flux de travail qui existent dans la même application logique Standard à l’aide du déclencheur Requête, du déclencheur Webhook HTTP ou de déclencheurs de connecteur géré de type ApiConnectionWebhook pouvant recevoir des requêtes HTTPS.

La liste suivante décrit les modèles de comportement que les workflows imbriqués peuvent suivre après qu’un workflow parent a appelé un workflow enfant :

• Modèle d’interrogation asynchrone

  Le workflow parent n’attend pas que le workflow enfant réponde à son appel initial. Toutefois, le parent vérifie continuellement l’historique des exécutions de l’enfant jusqu’à la fin de l’exécution de ce dernier. Par défaut, les flux de travail avec état suivent ce modèle, qui est idéal pour les flux de travail enfants de longue durée susceptibles de dépasser les limites de délai d’expiration de demande.

• Modèle synchrone (« fire and forget »)

  Le workflow enfant reconnaît l’appel du workflow parent en retournant immédiatement une réponse 202 ACCEPTED. Toutefois, le parent n’attend pas que l’enfant retourne les résultats. Au lieu de cela, le parent passe à l’action suivante dans le workflow et reçoit les résultats quand l’exécution de l’enfant prend fin. Les workflows avec état enfant qui n’incluent pas d’action de réponse suivent toujours le modèle synchrone et fournissent un historique des exécutions que vous pouvez passer en revue.

  Pour activer ce comportement, dans la définition JSON du flux de travail, définissez la propriété operationOptions sur la valeur DisableAsyncPattern. Pour plus d’informations, consultez Types d’action et de déclencheur – Options d’opération.

• Déclencher et attendre

  Les workflows sans état s’exécutent en mémoire. Ainsi, quand un workflow parent appelle un workflow enfant sans état, le workflow parent attend une réponse retournant les résultats du workflow enfant. Ce modèle fonctionne de manière similaire à l’utilisation du déclencheur ou de l’action HTTP intégrés pour appeler un workflow enfant. Les flux de travail enfants sans état qui n’incluent pas d’action Réponse retournent immédiatement une réponse 202 ACCEPTED, mais le flux de travail parent attend que le flux de travail enfant se termine avant de passer à l’action suivante. Ces comportements s’appliquent uniquement aux flux de travail enfants sans état.

Le tableau suivant identifie le comportement du workflow enfant selon que les workflows parent et enfant sont avec état, sans état ou mixtes. Liste après le tableau

Autres fonctionnalités du modèle monolocataire

Le modèle monolocataire et l’application logique Standard incluent de nombreuses fonctionnalités actuelles et nouvelles, par exemple :

• Créez des applications logiques et leurs workflows à partir de plus de 1 400 connecteurs managés pour les applications et services SaaS (Software-as-a-service) et PaaS (Platform-as-a-service), ainsi que des connecteurs pour les systèmes locaux.

  • D’autres connecteurs managés sont désormais disponibles en tant que connecteurs intégrés dans les flux de travail Standard. Les versions intégrées s’exécutent en mode natif sur le runtime monolocataire Azure Logic Apps. Certains connecteurs intégrés sont également appelés connecteurs de fournisseur de services de manière informelle. Pour obtenir une liste, passez en revue les Connecteurs intégrés dans les plans Consommation et Standard.

  • Vous pouvez créer vos propres connecteurs intégrés personnalisés pour tous les services dont vous avez besoin à l’aide du framework d’extensibilité Azure Logic Apps monolocataire. Comme pour les connecteurs intégrés tels qu’Azure Service Bus et SQL Server, connecteurs intégrés personnalisés offrent un débit plus élevé, une faible latence et une connectivité locale, car ils s’exécutent dans le même processus que le runtime monolocataire. Toutefois, les connecteurs intégrés personnalisés ne sont pas similaires aux connecteurs managés personnalisés, qui ne sont pas pris en charge actuellement. Pour plus d’informations, consultez Vue d’ensemble du connecteur personnalisé et Créer des connecteurs intégrés personnalisés pour les applications logiques Standard dans des Azure Logic Apps monolocataires.

  • Vous pouvez utiliser les actions suivantes pour Liquid Operations et XML Operations sans compte d’intégration. Ces opérations peuvent être notamment les actions suivantes :

    • XML : Transformation XML, Validation XML, Composition XML avec schéma et Analyse XML avec schéma

    • Liquid : Transformer JSON en JSON, Transformer JSON en TEXT, Transformer XML en JSON et Transformer XML en Text

    Notes

    Pour utiliser ces actions dans des flux de travail Standard, vous devez disposer de mappages Liquid, de mappages XML ou de schémas XML. Vous pouvez charger ces artefacts sur le portail Azure à partir du menu des ressources de votre application logique, sous Artefacts, qui inclut les sections Schémas et Mappages. Vous pouvez également ajouter ces artefacts à votre dossier Artefacts du projet Visual Studio Code, en utilisant les Mappages et les Schémas correspondants. Vous pouvez ensuite utiliser ces artefacts sur plusieurs flux de travail au sein de la même application logique.

  • Les workflows d’application logique Standard peuvent se déclencher depuis n’importe où, car Azure Logic Apps génèrent des chaînes de connexion avec signature d’accès partagé (SAP) que ces applications logiques peuvent utiliser pour envoyer des requêtes au point de terminaison du runtime de connexion cloud. Azure Logic Apps enregistre ces chaînes de connexion avec d’autres paramètres de l’application pour vous permettre de stocker facilement ces valeurs dans Azure Key Vault quand vous opérez un déploiement sur Azure.

  • Les flux de travail d’application logique Standard prennent en charge l’activation de l’identité managée affectée par le système et de plusieurs identités managées affectées par l’utilisateur en même temps, même si vous ne pouvez sélectionner qu’une seule identité à utiliser à la fois. Bien que les connecteurs intégrés basés sur le fournisseur de services prennent en charge l’utilisation de l’identité affectée par le système, la plupart ne prennent pas en charge actuellement la sélection d’identités managées affectées par l’utilisateur pour l’authentification, à l’exception de SQL Server et des connecteurs HTTP.

    Notes

    Par défaut, l’identité affectée par le système est déjà activée pour authentifier les connexions au moment de l’exécution. Cette identité diffère des informations d’identification d’authentification ou de la chaîne de connexion que vous utilisez lors de la création d’une connexion. Si vous désactivez cette identité, les connexions ne fonctionneront pas au moment de l’exécution. Pour afficher ce paramètre, dans le menu de votre application logique, sous Paramètres, sélectionnez Identité.

• Vous pouvez exécuter, tester et déboguer localement vos applications logiques et leurs workflows dans l’environnement de développement Visual Studio Code.

  Avant d’exécuter et de tester votre application logique, vous pouvez faciliter le débogage en ajoutant et en utilisant des points d’arrêt dans le fichier workflow.json d’un workflow. Toutefois, les points d’arrêt sont pris en charge uniquement pour les actions à l’heure actuelle, et non pour les déclencheurs. Pour plus d’informations, consultez Créer des workflows monolocataires dans Visual Studio Code.

• Publiez ou déployez directement des applications logiques et leurs workflows de Visual Studio Code vers divers environnements d’hébergement tels qu’Azure et des Logic Apps Azure Arc.

• Activez les capacités de journalisation et de suivi des diagnostics pour votre application logique en utilisant Application Insights lorsque la fonctionnalité est prise en charge par votre abonnement Azure et les paramètres de l’application logique.

• Accédez à des fonctionnalités réseau, comme la connexion et l’intégration privées aux réseaux virtuels Azure, de la même façon qu’Azure Functions quand vous créez et déployez vos applications logiques, en utilisant le plan Azure Functions Premium. Pour plus d’informations, consultez la documentation suivante :

  • Options de mise en réseau d’Azure Functions

  • Azure Logic Apps s’exécutant partout – Capacités réseau avec Azure Logic Apps

• Régénérez les clés d’accès pour les connexions gérées utilisées par les flux de travail individuels dans une application logique Standard. Pour cette tâche, suivez les mêmes étapes que pour l’application logique Consommation, mais au niveau du flux de travail individuel, et non au niveau de la ressource de l’application logique.

Connecteurs intégrés pour Standard

Un flux de travail Standard peut utiliser un grand nombre de connecteurs intégrés comme un flux de travail Consommation, mais pas tous. À l'inverse, un flux de travail Standard comporte de nombreux connecteurs intégrés qui ne sont pas disponibles dans un flux de travail Consommation.

Par exemple, un flux de travail Standard possède à la fois des connecteurs managés et des connecteurs intégrés pour Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server et autres. Bien qu’un flux de travail consommation n’ait pas ces mêmes versions de connecteur intégrées, d’autres connecteurs intégrés tels que Gestion des API Azure et Azure App Services sont disponibles.

Dans les Azure Logic Apps monolocataires, les connecteurs intégrés avec des attributs spécifiques sont appelés fournisseurs de services de manière informelle. Certains connecteurs intégrés ne prennent en charge qu’une seule façon d’authentifier une connexion au service sous-jacent. D’autres connecteurs intégrés peuvent offrir un choix, comme l’utilisation d’une chaîne de connexion, de Microsoft Entra ID ou d’une identité managée. Tous les connecteurs intégrés s’exécutent dans le même processus que le runtime Azure Logic Apps repensé. Pour plus d’informations, consultez la liste des connecteurs intégrés pour les workflows d’application logique Standard.

Capacités modifiées, limitées, non disponibles ou non prises en charge

Pour le workflow d’application logique Standard, les capacités suivantes sont différentes, actuellement limitées, indisponibles ou non prises en charge :

• Déclencheurs et actions : les déclencheurs et actions intégrés s’exécutent en mode natif dans Azure Logic Apps, tandis que les connecteurs managés sont hébergés et exécutés à l’aide de ressources partagées dans Azure. Pour les workflows Standard, certains déclencheurs et actions intégrés sont actuellement indisponibles, comme Fenêtre glissante et les opérations Azure App Service. Pour démarrer un workflow avec ou sans état, utilisez un déclencheur intégré tel que le déclencheur de demande, Event Hubs ou Service Bus. Le déclencheur de périodicité est disponible pour les workflows avec état, mais non pour les workflows sans état. Dans le concepteur, les déclencheurs et les actions intégrés apparaissent avec l’étiquette Dans l’application, tandis que les déclencheurs et actions de connecteur managé apparaissent avec l’étiquette Partagé.

  Les flux de travail sans état peuvent utiliser uniquement des déclencheurs Push où vous ne spécifiez pas de planification pour l’exécution de votre flux de travail. Ces déclencheurs webhooks attendent qu’un événement se produise ou que des données soient disponibles. Par exemple, le déclencheur périodicité est disponible uniquement pour les flux de travail avec état. Pour démarrer votre workflow, sélectionnez un déclencheur Push, tel que le déclencheur de demande, Event Hubs ou Service Bus. Bien que vous puissiez activer les connecteurs gérés pour les workflows sans état, la galerie de connecteurs n’affiche aucun déclencheur d’interrogation géré que vous pouvez ajouter.

  Remarque

  Pour s’exécuter localement dans Visual Studio Code, les déclencheurs et les actions basés sur un webhook nécessitent une configuration supplémentaire. Pour plus d’informations, consultez Créer des workflows monolocataires dans Visual Studio Code.

  • Ces déclencheurs et actions ont été modifiés ou sont actuellement limités, non pris en charge ou non disponibles :

    • L’action intégrée, Azure Functions - Choisir une fonction Azure est désormais Opérations Azure Functions - Appeler une fonction Azure. Cette action ne fonctionne actuellement que pour les fonctions créées à partir du modèle Déclencheur HTTP.

      Dans le portail Azure, vous pouvez sélectionner une fonction de déclencheur HTTP à laquelle vous pouvez accéder en créant une connexion via l’expérience utilisateur. Si vous inspectez la définition JSON de l’action de fonction en mode code ou le fichier workflow.json avec Visual Studio Code, l’action fait référence à la fonction à l’aide d’une référence connectionName. Cette version extrait les informations de la fonction en tant que connexion, que vous pouvez trouver dans le fichier connections.json de votre projet d’application logique, qui est disponible après la création d’une connexion dans Visual Studio Code.

      Notes

      Dans le modèle monolocataire, l’action de la fonction ne prend en charge que l’authentification par chaîne de requête. Azure Logic Apps obtient la clé par défaut de la fonction lors de l’établissement de la connexion, stocke cette clé dans les paramètres de votre application et utilise la clé pour l’authentification lors de l’appel de la fonction.

      Comme dans le modèle multilocataire, si vous renouvelez cette clé, par exemple, via l’expérience Azure Functions dans le portail, l’action de fonction ne fonctionne plus en raison de la clé non valide. Pour résoudre ce problème, vous devez recréer la connexion à la fonction que vous souhaitez appeler ou mettre à jour les paramètres de votre application avec la nouvelle clé.

    • L’action intégrée Code inline intégrée est renommée Opérations de code inline, n’a plus besoin d’un compte d’intégration et a des limites mises à jour.

    • L’action intégrée, Azure Logic Apps – Choisir un workflow d’application logique est désormais Workflow Operations – Appeler un workflow dans cette application de workflow.

    • Les connecteurs gérés personnalisés ne sont actuellement pas pris en charge. Toutefois, vous pouvez créer des opérations intégrées personnalisées lorsque vous utilisez Visual Studio Code. Pour plus d’informations, consultez Créer des workflows monolocataires avec Visual Studio Code.

    • Un workflow Standard ne peut avoir qu’un seul déclencheur et ne prend pas en charge plusieurs déclencheurs.

• Authentification

  • Certains déclencheurs basés sur une requête qui gèrent les appels entrants, comme le déclencheur Requête, ne prennent actuellement pas en charge l’authentification Microsoft Entra ID OAuth (Microsoft Entra ID Open Authentication), tandis que d’autres, comme le déclencheur Webhook HTTP, la prennent en charge.

  • Certains connecteurs de services intégrés basés sur un fournisseur ne prennent actuellement pas en charge la sélection de l’identité managée affectée par l’utilisateur pour l’authentification. La prise en charge à la fois de l’identité managée affectée par le système et de l’identité managée affectée par l’utilisateur est cependant généralement disponible. L’identité managée affectée par le système est automatiquement activée par défaut.

• Débogage des points d’arrêt dans Visual Studio Code : Bien que vous puissiez ajouter et utiliser des points d’arrêt à l’intérieur du fichier workflow.json pour un workflow, les points d’arrêt sont pris en charge uniquement pour les actions pour le moment, et non pour les déclencheurs. Pour plus d’informations, consultez Créer des workflows monolocataires dans Visual Studio Code.

• Historique des déclencheurs et historique des exécutions : pour un workflow d’application logique Standard, l’historique des déclencheurs et l’historique des exécutions s’affichent dans le portail Azure au niveau du workflow, et non pas au niveau de la ressource d’application logique. Pour plus d’informations, consultez Créer des workflows monolocataires avec le portail Azure.

• Modèles Terraform : vous ne pouvez pas utiliser ces modèles avec une ressource d’application logique Standard pour un déploiement d’infrastructure complet. Pour plus d’informations, consultez Qu’est-ce que Terraform sur Azure ?.

Autorisations strictes de trafic réseau et de pare-feu

Si votre environnement a des exigences réseau strictes ou des pare-feu qui limitent le trafic, vous devez autoriser l’accès pour toutes les connexions de déclencheur ou d’action dans vos workflows. Vous pouvez éventuellement autoriser le trafic à partir d’étiquettes de service et utiliser le même niveau de restrictions ou de stratégies qu’Azure App Service. Vous devez également rechercher et utiliser les noms de domaine complets (FQDN) pour vos connexions. Pour plus d’informations, consultez les sections correspondantes dans la documentation suivante :

• Autorisations de pare-feu pour les applications logiques monolocataires - Portail Azure
• Autorisations de pare-feu pour les applications logiques monolocataires - Visual Studio Code

Étapes suivantes

• Créer des workflows monolocataires dans le portail Azure
• Créer des workflows monolocataires dans Visual Studio Code

Nous aimerions également que vous nous fassiez part de votre expérience avec $$$Azure Logic Apps monolocataire !

• Pour tout bogue ou problème que vous rencontreriez, créez un problème dans GitHub.
• Pour toute question, demande, commentaire ou retour d’expérience, utilisez de formulaire de commentaires.