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.
| Option d’hébergement | Avantages | Partage et utilisation des ressources | Modèle de tarification et facturation | Gestion des limites |
|---|---|---|---|---|
| Consommation Environnement hôte : Azure Logic Apps multilocataire |
- Le plus simple pour commencer – Paiement à l’utilisation - Complètement managé |
Une même ressource d’application logique ne peut avoir qu’un seul workflow. Toutes les applications logiques au niveau de tous les locataires Microsoft Entra partagent le même traitement (calcul), le même stockage, le même réseau, etc. À des fins de redondance, les données sont répliquées dans la région jumelée. Pour la haute disponibilité, le stockage géoredondant (GRS) est activé. |
Consommation (paiement à l’exécution) | Azure Logic Apps gère les valeurs par défaut de ces limites, mais vous pouvez modifier certaines de ces valeurs, si cette option est disponible pour la limite en question. |
| Standard (plan de service de flux de travail) Environnement hôte : Azure Logic Apps monolocataire Remarque : Si votre scénario nécessite des conteneurs, créez des applications logiques monolocataires via Logic Apps avec Azure Arc. Pour plus d’informations, consultez Qu’est-ce que Logic Apps avec Azure Arc ? |
– Davantage de connecteurs intégrés hébergés sur le runtime monolocataire pour un débit plus élevé et des coûts réduits à grande échelle - Plus de contrôle et d’optimisation des fonctionnalités autour des paramètres d’exécution et de performances - Prise en charge intégrée des réseaux virtuels et des points de terminaison privés. - Créez vos propres connecteurs intégrés. |
Une même ressource d’application logique peut avoir plusieurs workflows avec état et sans état. Les workflows qui se trouvent dans une même application logique et qui sont monolocataires partagent le même traitement (calcul), le même stockage, le même réseau, et ainsi de suite. Les données restent dans la même région que celle où vous déployez votre application logique. |
Standard, basé sur un plan d’hébergement avec un niveau tarifaire sélectionné. Si vous exécutez des workflows avec état, qui utilisent un stockage externe, le runtime Azure Logic Apps effectue des transactions de stockage basées sur les tarifs du service Stockage Azure. |
Vous pouvez modifier les valeurs par défaut de nombreuses limites, en fonction des besoins de votre scénario. Important : certaines limites sont assorties de valeurs maximales supérieures. Dans Visual Studio Code, les modifications que vous apportez aux limites par défaut dans les fichiers de configuration de votre projet d'application logique n'apparaissent pas dans l'expérience du concepteur. Pour plus d’informations, consultez Modifier les paramètres de l’environnement et de l’application pour les applications logiques dans Azure Logic Apps monolocataire. |
| Standard (App Service Environment v3) Environnement hôte : App Service Environment v3 (ASEv3) - Plans Windows uniquement |
Mêmes fonctionnalités que le modèle monolocataire en plus des avantages suivants : - Isolez entièrement vos applications logiques. - Créez et exécutez davantage d’applications logiques que dans le modèle Azure Logic Apps monolocataire. - Payez uniquement pour le plan App Service ASE, quel que soit le nombre d’applications logiques que vous créez et exécutez. - Permet d’activer la mise à l’échelle automatique ou la mise à l’échelle manuelle avec davantage d’instances de machine virtuelle ou un autre plan App Service. - Permet d’hériter de la configuration réseau de l’environnement ASEv3 sélectionné. Par exemple, lorsque vous déployez sur un environnement ASE interne, les workflows peuvent accéder aux ressources d’un réseau virtuel associé à l’environnement ASE et disposer de points d’accès internes. Remarque : En cas d’accès depuis l’extérieur d’un environnement ASE interne, les historiques d’exécution des workflows de cet environnement ASE ne peuvent pas accéder aux entrées et aux sorties d’actions. |
Une même application logique peut avoir plusieurs workflows avec état et sans état. Les workflows qui se trouvent dans une même application logique et qui sont monolocataires partagent le même traitement (calcul), le même stockage, le même réseau, et ainsi de suite. Les données restent dans la même région que celle où vous déployez vos applications logiques. |
Plan App Service | Vous pouvez modifier les valeurs par défaut de nombreuses limites, en fonction des besoins de votre scénario. Important : certaines limites sont assorties de valeurs maximales supérieures. Dans Visual Studio Code, les modifications que vous apportez aux limites par défaut dans les fichiers de configuration de votre projet d'application logique n'apparaissent pas dans l'expérience du concepteur. Pour plus d’informations, consultez Modifier les paramètres de l’environnement et de l’application pour les applications logiques dans Azure Logic Apps monolocataire. |
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
| Option | Outils et ressources | Informations complémentaires |
|---|---|---|
| Portail Azure | Application logique Standard | Créer un exemple de workflow d’application logique Standard dans Azure Logic Apps à locataire unique – Portail Azure |
| Visual Studio Code | Extension Azure Logic Apps (Standard) | Créer un exemple de workflow d’application logique Standard dans Azure Logic Apps à locataire unique – Visual Studio Code |
| Azure CLI | Extension Azure CLI Logic Apps | az logicapp |
| Azure Resource Manager | - Local - DevOps |
Azure Logic Apps monolocataire |
| Logic Apps avec Azure Arc | Exemple de Logic Apps avec Azure Arc | - Qu’est-ce que Logic Apps avec Azure Arc ? - Créer et déployer des workflows d’application logique monolocataire en utilisant Logic Apps avec Azure Arc |
| API REST Azure | API REST Azure App Service* Remarque : l’API REST d’application logique Standard est incluse avec l’API REST Azure App Service. |
Référence Bien démarrer avec l’API REST Azure |
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
locationen-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
locationen-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.
Important
Vous devez choisir le type de workflow, avec état ou sans état, à implémenter au moment de la création. Les modifications apportées au type de workflow après la création entraînent des erreurs d’exécution.
Résumé des différences entre les workflows avec état et sans état
| Avec état | Sans état |
|---|---|
| Stocke l’historique des exécutions, les entrées et les sorties | Ne stocke pas l’historique des exécutions, les entrées ou les sorties par défaut |
| Les déclencheurs de connecteur managé sont disponibles et autorisés | Les déclencheurs de connecteur managé ne sont pas disponibles ou ne sont pas autorisés |
| Prise en charge de la segmentation | Aucune prise en charge de la segmentation |
| Prend en charge les opérations asynchrones | Pas de prise en charge des opérations asynchrones |
| Modifier la durée d’exécution maximale par défaut dans la configuration d’hôte | Idéal pour les workflows avec une durée maximale inférieure à 5 minutes |
| Gère les messages volumineux | Idéal pour gérer les petites tailles de messages (moins de 64 Ko) |
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é
operationOptionssur la valeurDisableAsyncPattern. 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
| Flux de travail parent | Flux de travail enfant | Comportement du flux de travail enfant |
|---|---|---|
| Avec état | Avec état | Asynchrone ou synchrone avec le paramètre "operationOptions": "DisableAsyncPattern" |
| Avec état | Sans état | Déclencher et attendre |
| Sans état | Avec état | Synchrone |
| Sans état | Sans état | Déclencher et attendre |
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 centaines de 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 et Validation XML
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 flux de travail d’application logique Standard peuvent s’exécuter en tout lieu, 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 demandes 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 :
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.
Important
Assurez-vous de configurer et tester correctement tout déclencheur basé sur un fournisseur de services pour confirmer la réussite de l’opération. L’échec d’un déclencheur basé sur un fournisseur de services peut engendrer une mise à l’échelle inutile, ce qui peut augmenter considérablement vos coûts de facturation. Par exemple, une erreur courante consiste à définir un déclencheur, sans accorder à votre application logique l’autorisation ou l’accès à la destination, comme une file d’attente Service Bus, un conteneur d’objets blob Stockage Azure, etc. Assurez-vous également de surveiller en permanence ces déclencheurs afin de pouvoir détecter et résoudre rapidement des problèmes.
Capacités modifiées, limitées, non disponibles ou non prises en charge
Pour le flux de travail d’application logique Standard, ces capacités ont changé, ou elles sont actuellement limitées, non disponibles 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 flux de travail Standard, certains déclencheurs et actions intégrés sont actuellement indisponibles, comme la fenêtre glissante, Azure App Service et la gestion des API Azure. 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 s’affichent avec l’étiquette Dans l’application, tandis que les déclencheurs et actions de connecteur managé s’affichent 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.
Actuellement, le connecteur Gmail n’est pas pris en charge.
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 d’application logique ne peut avoir qu’un seul déclencheur et ne prend pas en charge plusieurs déclencheurs.
Authentification : les types d’authentification suivants ne sont actuellement pas disponibles pour les flux de travail Standard :
Authentification ouverte Microsoft Entra ID (Microsoft Entra ID OAuth) pour les appels entrants vers les déclencheurs basés sur une demande, tels que le déclencheur de requête et le déclencheur de Webhook HTTP.
Authentification d’identité managée : La prise en charge est disponible pour les identités managées affectées par le système et par l’utilisateur. L’identité managée affectée par le système est automatiquement activée par défaut. Toutefois, actuellement la plupart des connecteurs de services intégrés basés sur un fournisseur ne prennent pas en charge la sélection d’identités managées affectées par l’utilisateur pour l’authentification.
Transformation XML : seul XSLT 1.0 est actuellement pris en charge.
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 une application logique Standard, l’historique des déclencheurs et l’historique des exécutions s’affichent dans le portail Azure au niveau du flux de travail, et non au niveau de la ressource d’application logique. Pour plus d’informations, consultez Créer des workflows monolocataires avec le portail Azure.
Sauvegarde et restauration de l’historique des exécutions de flux de travail: applications logiques standard ne prennent actuellement pas en charge la sauvegarde et la restauration pour l’historique des exécutions de flux de travail.
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 ?.
Azure API Management : vous ne pouvez actuellement pas importer de ressource d’application logique Standard dans Azure API Management. Toutefois, vous pouvez importer une ressource d’application logique Consommation.
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.