Mesure de l’utilisation, facturation et tarification d’Azure Logic Apps
S’applique à : Azure Logic Apps (Consommation + Standard)
Azure Logic Apps vous aide à créer et à exécuter des flux de travail d’intégration automatisés et pouvant être mis à l’échelle dans le cloud. Cet article décrit le fonctionnement des modèles de mesure, de facturation et de tarification pour Azure Logic Apps et les ressources associées. Pour des informations telles que les tarifs spécifiques, la planification des coûts ou les différents environnements d’hébergement, consultez le contenu suivant :
- Tarifs d’Azure Logic Apps
- Prévoir et gérer les coûts d’Azure Logic Apps
- Architecture monolocataire ou multilocataire et environnement de service d’intégration
Consommation (multilocataire)
Dans Azure Logic Apps multilocataire, une application logique et son flux de travail suivent le plan Consommation pour la tarification et la facturation. Vous créez de telles applications logiques de différentes manières, par exemple, lorsque vous choisissez le type de ressource Logic App (Consommation) , que vous utilisez l’extension Azure Logic Apps (Consommation) dans Visual Studio Code, ou que vous créez des tâches d’automatisation.
Le tableau suivant résume la façon dont le modèle Consommation gère la mesure et la facturation des composants suivants lorsqu’il est utilisé avec une application logique et un flux de travail dans Azure Logic Apps multilocataire :
| Composant | Métriques et facturation |
|---|---|
| Opérations de déclenchement et d’action | Le modèle Consommation comprend un nombre initial d’opérations intégrées gratuites, par abonnement Azure, qu’un flux de travail peut exécuter. Au-delà de ce nombre, la mesure s’applique à chaque exécution et la facturation suit la tarification Actions pour le plan Consommation. Pour les autres types d’opérations, tels que les connecteurs managés, la facturation suit la tarification du connecteur Standard ou Entreprise pour le plan Consommation. Pour plus d’informations, consultez la section Opérations de déclenchement et d’action dans le modèle Consommation. |
| Opérations de stockage | La mesure s’applique uniquement à la consommation de stockage liée à la conservation des données, telle que la sauvegarde des entrées et des sorties de l’historique des exécutions de votre flux de travail. La facturation suit la tarification de la conservation des données pour le plan Consommation. Pour plus d’informations, consultez Opérations de stockage. |
| Comptes d’intégration | La mesure s’applique en fonction du type de compte d’intégration que vous créez et utilisez avec votre application logique. La facturation suit la tarification Compte d’intégration, sauf si votre application logique est déployée et hébergée dans un environnement de service d’intégration (ISE). Pour plus d’informations, consultez Comptes d’intégration. |
Opérations de déclenchement et d’action dans le modèle Consommation
À l’exception du nombre initial d’exécutions gratuites d’opérations intégrées, par abonnement Azure, qu’un flux de travail peut exécuter, le modèle Consommation mesure et facture une opération en fonction de chaque exécution, que le flux de travail global s’exécute correctement, se termine ou soit même instancié. Une opération n’est généralement exécutée qu’une seule fois, à moins que les nouvelles tentatives ne soient activées. De même, une exécution effectue généralement un seul appel, sauf si l’opération prend en charge et active la segmentation ou la pagination pour obtenir de grandes quantités de données. Si la segmentation ou la pagination est activée, l’exécution d’une opération peut nécessiter plusieurs appels.
Le modèle Consommation mesure et facture une opération par exécution, et non par appel. Supposons, par exemple, qu’un flux de travail commence par un déclencheur d’interrogation qui obtient des enregistrements en effectuant régulièrement des appels sortants vers un point de terminaison. L’appel sortant est mesuré et facturé comme une seule exécution, que le déclencheur soit activé ou ignoré, par exemple lorsqu’un déclencheur vérifie un point de terminaison, mais ne trouve pas de données ou d’événements. L’état du déclencheur contrôle la création et l’exécution ou non de l’instance de flux de travail. Supposons à présent que l’opération prend également en charge et a activé la segmentation ou la pagination. Si l’opération doit effectuer 10 appels pour finir d’obtenir toutes les données, l’opération est toujours mesurée et facturée comme une seule exécution, même si elle passe plusieurs appels.
Notes
Par défaut, les déclencheurs qui retournent un tableau ont un paramètre Fractionner sur déjà activé. Ce paramètre génère un événement de déclencheur, que vous pouvez consulter dans l’historique du déclencheur, et une instance de workflow pour chaque élément de tableau. Toutes les instances de flux de travail s’exécutent en parallèle afin que les éléments du tableau soient traités en même temps. La facturation s’applique à tous les événements de déclencheur, que l’état du déclencheur soit Réussi ou Ignoré. Les déclencheurs sont toujours facturables même dans les scénarios où les déclencheurs n’instancient pas et ne démarrent pas le workflow, mais où l’état du déclencheur est Réussi, Échec ou Ignoré.
Le tableau suivant résume la façon dont le modèle Consommation gère la mesure et la facturation de ces types d’opérations lorsqu’il est utilisé avec une application logique et un flux de travail dans Azure Logic Apps multilocataire :
| Type d'opération | Description | Métriques et facturation |
|---|---|---|
| Intégré | Ces opérations s’exécutent directement et en mode natif avec le runtime Azure Logic Apps. Dans le concepteur, vous pouvez trouver ces opérations sous l’étiquette Intégré. Par exemple, le déclencheur HTTP et le déclencheur Requête sont des déclencheurs intégrés. L’action HTTP et l’action Réponse sont des actions intégrées. Les autres opérations intégrées comprennent les actions de contrôle du flux de travail, telles que les boucles et les conditions, les opérations de données, les opérations de traitement par lot, etc. |
Le modèle Consommation comprend un nombre initial d’opérations intégrées gratuites, par abonnement Azure, qu’un flux de travail peut exécuter. Au-delà de ce nombre, les exécutions d’opérations intégrées suivent la tarification Actions. Remarque : Certaines opérations de connecteur managé sont également disponibles en tant qu’opérations intégrées, qui sont incluses dans les opérations initiales gratuites. Au-delà des opérations gratuites initiales, la facturation suit la tarification Actions, et non celle du connecteur Standard ou Entreprise. |
| Connecteur managé | Ces opérations s’exécutent séparément dans Azure. Dans le concepteur, vous pouvez trouver ces opérations sous l’étiquette Standard ou Entreprise. | Les exécutions de ces opérations suivent la tarification du connecteur Standard ou Entreprise. Remarque : Les exécutions d’opérations du connecteur Entreprise en préversion suivent la tarification du connecteur Consommation Standard. |
| Connecteur personnalisé | Ces opérations s’exécutent séparément dans Azure. Dans le concepteur, vous pouvez trouver ces opérations sous l’étiquette Personnalisé. Pour connaître les limites de nombre de connecteurs, de débit et de délai d’attente, consultez Limites des connecteurs personnalisés dans Azure Logic Apps. | Les exécutions de ces opérations suivent la tarification du connecteur Standard. |
Pour plus d’informations sur le fonctionnement du modèle Consommation avec les opérations qui s’exécutent à l’intérieur d’autres opérations, comme les boucles, le traitement de plusieurs éléments (p. ex. : les tableaux) et les stratégies de nouvelles tentatives, consultez Comportement des autres opérations.
Conseils pour l’estimation des coûts du modèle Consommation
Pour vous aider à estimer plus précisément les coûts de consommation, consultez les conseils suivants :
Ne basez pas vos calculs juste sur l’intervalle d’interrogation, mais prenez plutôt en compte le nombre possible de messages ou d’événements qui pourraient arriver chaque jour.
Lorsqu’un événement ou un message répond aux critères de déclencheurs, plusieurs déclencheurs essaient immédiatement de lire les autres événements ou messages en attente qui répondent aux critères. Ce comportement signifie que le déclencheur se lance selon le nombre d’événements ou de messages en attente qualifiés pour le démarrage de workflows, même si vous sélectionnez un intervalle d’interrogation plus étendue. Les déclencheurs qui adoptent ce comportement incluent Azure Service Bus et Azure Event Hubs.
Par exemple, imaginons que vous configuriez un déclencheur qui vérifie un point de terminaison par jour. Lorsqu’il vérifie le point de terminaison et trouve 15 événements qui répondent aux critères, il se lance et exécute le workflow correspondant 15 fois. Le service Logic Apps mesure toutes les actions réalisées par ces 15 workflows, dont les requêtes du déclencheur.
Standard (monolocataire)
Dans Azure Logic Apps monolocataire, une application logique et ses flux de travail suivent le plan Standard pour la tarification et la facturation. Vous créez de telles applications logiques de différentes manières, par exemple, lorsque vous choisissez le type de ressource Logic App (Standard) ou que vous utilisez l’extension Azure Logic Apps (Standard) dans Visual Studio Code. Ce modèle tarifaire exige que les applications logiques utilisent un plan d’hébergement et un niveau tarifaire, ce qui diffère du plan Consommation en ce sens que la capacité de réserve et les ressources dédiées vous sont facturées, que vous les utilisiez ou non.
Lorsque vous créez ou déployez des applications logiques avec le type de ressource Application logique (Standard) et que vous sélectionnez une région Azure pour le déploiement, vous sélectionnez également un plan d’hébergement standard de workflow. Toutefois, si vous sélectionnez une ressource App Service Environment v3 existante comme emplacement de votre déploiement, vous devez alors sélectionner un plan App Service.
Important
Les plans et ressources suivants ne sont plus disponibles ni pris en charge avec la version publique du type de ressource Application logique (Standard) dans les régions Azure : plan Functions Premium, App Service Environment v1 et App Service Environment v2. À l’exception d’ASEv3, le plan App Service n’est ni disponible ni pris en charge.
Le tableau suivant résume la façon dont le modèle Standard gère la mesure et la facturation des composants suivants lorsqu’il est utilisé avec une application logique et un flux de travail dans Azure Logic Apps monolocataire :
| Composant | Métriques et facturation |
|---|---|
| Processeur virtuel et mémoire | Le modèle Standard nécessite que votre application logique utilise le plan d’hébergement Flux de travail Standard et un niveau tarifaire, lequel détermine les niveaux de ressources et les tarifs qui s’appliquent à la capacité de calcul et de mémoire. Pour plus d’informations, consultez Niveaux tarifaires dans le modèle Standard. |
| Opérations de déclenchement et d’action | Le modèle Standard comprend un nombre illimité d’opérations intégrées gratuites que votre flux de travail peut exécuter. Si votre flux de travail utilise des opérations de connecteur managé, la mesure s’applique à chaque appel, tandis que la facturation suit la même tarification de connecteur Standard ou Entreprise que le plan Consommation. Pour plus d’informations, consultez la section Opérations de déclenchement et d’action dans le modèle Standard. |
| Opérations de stockage | Le contrôle s’applique à toutes les opérations de stockage exécutées par Azure Logic Apps. Par exemple, les opérations de stockage s’exécutent lorsque le service enregistre les entrées et les sorties à partir de l’historique des exécutions de votre flux de travail. La facturation suit le niveau tarifaire choisi. Pour plus d’informations, consultez Opérations de stockage. |
| Comptes d’intégration | Si vous créez un compte d’intégration à utiliser par votre application logique, la mesure est basée sur le type de compte d’intégration que vous créez. La facturation suit la tarification Compte d’intégration. Pour plus d’informations, consultez Comptes d’intégration. |
Niveaux tarifaires dans le modèle Standard
Le niveau tarifaire que vous choisissez pour mesurer et facturer votre ressource Application logique (Standard) comprend des quantités spécifiques de calcul dans les ressources de processeur virtuel et de mémoire. Si vous sélectionnez une instance App Service Environment v3 comme emplacement de déploiement, et un plan App Service, en particulier un niveau tarifaire de plan de service Isolé V2, vous êtes facturé pour les instances utilisées par le plan App Service et pour l’exécution de vos workflows d’application logique. Aucuns autres frais ne s’appliquent. Pour plus d’informations, consultez Plan App Service – Niveaux tarifaires du plan de service Isolé V2.
Si vous sélectionnez un plan d’hébergement standard de workflow, vous pouvez choisir parmi les niveaux suivants :
| Niveau tarifaire | Processeur virtuel | Mémoire (Go) |
|---|---|---|
| WS1 | 1 | 3,5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Important
L’exemple suivant est fourni à titre d’illustration uniquement et présente des estimations types pour illustrer le fonctionnement général d’un niveau tarifaire. Pour connaître la tarification spécifique des processeurs virtuels et de la mémoire en fonction des régions où Azure Logic Apps est disponible, consultez le plan Standard pour une région particulière sur la page de tarification d’Azure Logic Apps.
Supposons que dans une région d’exemple, les ressources suivantes ont ces tarifs horaires :
| Ressource | Tarif horaire (exemple de région) |
|---|---|
| Processeurs virtuels | 0,192 USD par processeur virtuel |
| Mémoire | 0,0137 USD par Go |
Le calcul suivant fournit une estimation du tarif mensuel :
<tarif-mensuel> = 730 heures (par mois) * [(<nombre-processeur-virtuel> * <tarif-horaire-processeur-virtuel>) + (<nombre-Go-mémoire> * <tarif-horaire-Go-mémoire>)]
Sur la base des informations précédentes, le tableau suivant présente les tarifs mensuels estimés pour chaque niveau tarifaire et les ressources de ce niveau tarifaire :
| Niveau tarifaire | Processeur virtuel | Mémoire (Go) | Tarif mensuel (exemple de région) |
|---|---|---|---|
| WS1 | 1 | 3,5 | 175,16 USD |
| WS2 | 2 | 7 | 350,33 USD |
| WS3 | 4 | 14 | 700,65 USD |
Opérations de déclenchement et d’action dans le modèle Standard
À l’exception des opérations intégrées gratuites illimitées qu’un flux de travail peut exécuter, le modèle Standard mesure et facture une opération en fonction de chaque appel, que le flux de travail global s’exécute correctement, se termine ou soit même instancié. Une opération n’est généralement exécutée qu’une seule fois, à moins que les nouvelles tentatives ne soient activées. De même, une exécution effectue généralement un seul appel, sauf si l’opération prend en charge et active la segmentation ou la pagination pour obtenir de grandes quantités de données. Si la segmentation ou la pagination est activée, l’exécution d’une opération peut nécessiter plusieurs appels. Le modèle Standard mesure et facture une opération par appel, et non par exécution.
Supposons, par exemple, qu’un flux de travail commence par un déclencheur d’interrogation qui obtient des enregistrements en effectuant régulièrement des appels sortants vers un point de terminaison. L’appel sortant est mesuré et facturé, que le déclencheur se déclenche ou non, ou qu’il soit ignoré. L’état du déclencheur contrôle la création et l’exécution ou non de l’instance de flux de travail. Supposons à présent que l’opération prend également en charge et a activé la segmentation ou la pagination. Si l’opération doit effectuer 10 appels pour finir d’obtenir toutes les données, l’opération est mesurée et facturée par appel.
Le tableau suivant résume la façon dont le modèle Standard gère la mesure et la facturation des types d’opérations lorsqu’il est utilisé avec une application logique et un flux de travail dans Azure Logic Apps monolocataire :
| Type d'opération | Description | Métriques et facturation |
|---|---|---|
| Intégré | Ces opérations s’exécutent directement et en mode natif avec le runtime Azure Logic Apps. Dans le concepteur, ces opérations sont disponibles dans la galerie de connecteurs sous Runtime>In-App. Par exemple, le déclencheur HTTP et le déclencheur Requête sont des déclencheurs intégrés. L’action HTTP et l’action Réponse sont des actions intégrées. Les autres opérations intégrées comprennent les actions de contrôle du flux de travail, telles que les boucles et les conditions, les opérations de données, les opérations de traitement par lot, etc. |
Le modèle Standard comprend un nombre illimité d’opérations intégrées gratuites. Remarque : Certaines opérations de connecteur managé sont également disponibles en tant qu’opérations intégrées. Bien que les opérations intégrées soient gratuites, le modèle Standard continue de mesurer et de facturer les opérations de connecteur managé en utilisant la même tarification de connecteur Standard ou Entreprise que le modèle Consommation. |
| Connecteur managé | Ces opérations s’exécutent séparément dans Azure global partagé. Dans le concepteur, ces opérations sont disponibles dans la galerie de connecteurs sous Runtime>Partagé. | Le modèle Standard mesure et facture les opérations de connecteur managé selon la même tarification de connecteur Standard et Entreprise que le modèle Consommation. Remarque : Les opérations du connecteur Entreprise en préversion suivent la tarification du connecteur Consommation Standard. |
| Connecteur personnalisé | Actuellement, vous pouvez créer et utiliser uniquement des opérations de connecteur intégrées personnalisées dans les flux de travail d’applications logiques monolocataires. | Le modèle Standard comprend un nombre illimité d’opérations intégrées gratuites. Pour connaître les limites de débit et de délai d’attente, consultez Limites des connecteurs personnalisés dans Azure Logic Apps. |
Pour plus d’informations sur le fonctionnement du modèle Standard avec les opérations qui s’exécutent à l’intérieur d’autres opérations, comme les boucles, le traitement de plusieurs éléments (p. ex. : les tableaux) et les stratégies de nouvelles tentatives, consultez Comportement des autres opérations.
Environnement de service d’intégration (ISE)
Lorsque vous créez une application logique à l’aide du type de ressource Application logique (Consommation) et que vous la déployez dans un environnement de service d’intégration (ISE) dédié, l’application logique et son flux de travail suivent le plan Environnement de service d’intégration pour la tarification et la facturation. Ce modèle de tarification dépend du niveau ou du SKU de votre ISE et diffère du plan Consommation en ce sens que la capacité de réserve et les ressources dédiées vous sont facturées, que vous les utilisiez ou non.
Le tableau suivant résume la manière dont le modèle ISE gère la mesure et la facturation de la capacité de réserve et des autres ressources dédiées en fonction de votre niveau ou SKU ISE :
| Référence (SKU) de l’environnement de service d’intégration | Métriques et facturation |
|---|---|
| Premium | L’unité de base a une capacité fixe et est facturée à un tarif horaire pour le niveau tarifaire Premium. Si vous avez besoin d’un débit plus élevé, vous pouvez ajouter des unités d’échelle supplémentaires pendant ou après la création de votre ISE. Chaque unité d’échelle est facturée à un tarif horaire qui correspond à peu près à la moitié du tarif de l’unité de base. Pour plus d’informations sur la capacité et les limites, consultez Limites ISE dans Azure Logic Apps. |
| Développeur | L’unité de base a une capacité fixe et est facturée à un tarif horaire pour le niveau tarifaire Développeur. Toutefois, cette référence SKU n’a pas de contrat de niveau de service (SLA), de fonctionnalité de scale-up ou de redondance pendant le recyclage, ce qui signifie que vous pouvez rencontrer des retards ou des temps d’arrêt. Les mises à jour du back-end peuvent interrompre le service par intermittence. Important ! Veillez à utiliser cette référence SKU uniquement à des fins d’exploration, d’expérimentation, de développement ou de test, et non pour la production ou les tests de performances. Pour plus d’informations sur la capacité et les limites, consultez Limites ISE dans Azure Logic Apps. |
Le tableau suivant résume la façon dont le modèle ISE gère les composants suivants lorsqu’il est utilisé avec une application logique et un flux de travail dans un ISE :
| Composant | Description |
|---|---|
| Opérations de déclenchement et d’action | Le modèle ISE comprend des opérations intégrées gratuites de connecteur managé et de connecteur personnalisé que votre flux de travail peut exécuter, mais sous réserve des limites de l’ISE dans Azure Logic Apps et des limites du connecteur personnalisé dans Azure Logic Apps. Pour plus d’informations, consultez la section Opérations de déclenchement et d’action dans le modèle ISE. |
| Opérations de stockage | Le modèle ISE inclut la consommation du stockage libre, telle que la conservation des données. Pour plus d’informations, consultez Opérations de stockage. |
| Comptes d’intégration | Le modèle ISE comprend un seul niveau de compte d’intégration gratuit, selon le SKU ISE que vous avez sélectionné. Pour un coût supplémentaire, vous pouvez créer davantage de comptes d’intégration pour votre ISE à utiliser jusqu’à la limite totale de l’ISE. Pour plus d’informations, consultez Comptes d’intégration. |
Opérations de déclenchement et d’action dans le modèle ISE
Le tableau suivant résume la façon dont le modèle ISE gère les types d’opérations suivants lorsqu’il est utilisé avec une application logique et un flux de travail dans un ISE :
| Type d'opération | Description | Métriques et facturation |
|---|---|---|
| Intégré | Ces opérations s’exécutent directement et en mode natif avec le runtime Azure Logic Apps et dans le même ISE que le flux de travail de votre application logique. Dans le concepteur, vous pouvez trouver ces opérations sous l’étiquette Intégré, mais chaque opération affiche également l’étiquette CORE. Par exemple, le déclencheur HTTP et le déclencheur Requête sont des déclencheurs intégrés. L’action HTTP et l’action Réponse sont des actions intégrées. Les autres opérations intégrées comprennent les actions de contrôle du flux de travail, telles que les boucles et les conditions, les opérations de données, les opérations de traitement par lot, etc. |
Le modèle ISE inclut ces opérations gratuitement, mais elles sont soumises aux limites de l’ISE dans Azure Logic Apps. |
| Connecteur managé | Qu’il s’agisse de Standard ou d’Entreprise, les opérations de connecteur managé s’exécutent soit dans votre ISE, soit dans Azure multilocataire, selon que le connecteur ou l’opération affiche l’étiquette ISE. - Étiquette ISE : Ces opérations s’exécutent dans le même ISE que votre application logique et fonctionnent sans nécessiter la passerelle de données locale. Pas d’étiquette ISE : Ces opérations s’exécutent dans Azure multilocataire. |
Le modèle ISE inclut les opérations avec étiquette ISE et sans étiquette ISEgratuitement, mais elles sont soumises aux limites de l’ISE dans Azure Logic Apps. |
| Connecteur personnalisé | Dans le concepteur, vous pouvez trouver ces opérations sous l’étiquette Personnalisé. | Le modèle ISE inclut ces opérations gratuitement, mais elles sont soumises aux limites du connecteur personnalisé dans Azure Logic Apps. |
Pour plus d’informations sur le fonctionnement du modèle ISE avec les opérations qui s’exécutent à l’intérieur d’autres opérations, comme les boucles, le traitement de plusieurs éléments (p. ex. : les tableaux) et les stratégies de nouvelles tentatives, consultez Comportement des autres opérations.
Comportement des autres opérations
Le tableau suivant résume la façon dont les modèles Consommation, Standard et ISE traitent les opérations, comme les boucles, le traitement de plusieurs éléments (p. ex. : les tableaux) et les stratégies de nouvelles tentatives :
| Opération | Description | Consommation | standard | ISE |
|---|---|---|---|---|
| Actions de bouclage | Une action de boucle, telle que la boucle For each ou Until, peut inclure d’autres actions qui s’exécutent pendant chaque cycle de boucle. | À l’exception du nombre initial d’opérations intégrées incluses, l’action de boucle et chaque action dans la boucle sont mesurées à chaque fois que le cycle de la boucle s’exécute. Si une action traite des éléments d’une collection, telle qu’une liste ou un tableau, le nombre d’éléments est également utilisé dans le calcul de la mesure. Par exemple, supposons que vous ayez une boucle For each avec des actions qui traite une liste. Le service multiplie le nombre d’éléments de la liste par le nombre d’actions dans la boucle, puis ajoute l’action qui démarre la boucle. Le calcul pour une liste de 10 éléments est donc (10 * 1) + 1, ce qui donne 11 exécutions d’action. La tarification est basée sur les types d’opération suivants (intégré, Standard ou Entreprise). |
À l’exception des opérations intégrées incluses, il est identique au modèle Consommation. | Non mesuré ni facturé. |
| Stratégies de nouvelle tentative | Pour les opérations prises en charge, vous pouvez implémenter une gestion de base des exceptions et des erreurs en configurant une stratégie de nouvelles tentatives. | À l’exception du nombre initial d’opérations intégrées, l’exécution d’origine et chaque nouvelle tentative d’exécution sont mesurées. Par exemple, une action qui s’exécute avec 5 nouvelles tentatives est mesurée et facturée comme 6 exécutions. La tarification est basée sur les types d’opération suivants (intégré, Standard ou Entreprise). |
À l’exception des opérations intégrées incluses, il est identique au modèle Consommation. | Non mesuré ni facturé. |
Opérations de stockage
Azure Logic Apps utilise Stockage Azure pour toutes les transactions de stockage requises, comme l’utilisation de files d’attente pour la planification des opérations de déclenchement ou l’utilisation de tables et de blobs pour le stockage des états du workflow. En fonction des opérations de votre flux de travail, les coûts de stockage varient, car les différents déclencheurs, actions et charges utiles entraînent des opérations et des besoins de stockage différents. Le service enregistre et stocke également les entrées et les sorties de l’historique des exécutions de votre flux de travail, en fonction de la limite de rétention de l’historique des exécutions de la ressource d’application logique. Vous pouvez gérer cette limite de rétention au niveau de la ressource d’application logique, et non au niveau du flux de travail.
Le tableau suivant résume la façon dont les modèles Consommation, Standard et ISE gèrent la mesure et la facturation des opérations de stockage :
| Modèle | Description | Métriques et facturation |
|---|---|---|
| Consommation (multilocataire) | Les ressources de stockage et leur utilisation sont jointes à la ressource d’application logique. | La mesure et la facturation s’appliquent uniquement à la consommation de stockage liée à la conservation des données et suivent la tarification de la conservation des données pour le plan Consommation. |
| Standard (monolocataire) | Vous pouvez utiliser votre propre compte de stockage Azure, ce qui vous donne plus de contrôle et de flexibilité sur les données de votre flux de travail. | La mesure et la facturation suivent le modèle de tarification de Stockage Azure. Les coûts de stockage apparaissent séparément sur votre facture Azure. Conseil : Pour vous aider à mieux comprendre le nombre d’opérations de stockage qu’un flux de travail pourrait exécuter et leur coût, essayez d’utiliser la calculatrice de prix Stockage Logic Apps. Sélectionnez un exemple de flux de travail ou utilisez une définition de flux de travail existante. Le premier calcul estime le nombre d’opérations de stockage dans votre workflow. Vous pouvez ensuite utiliser ces nombres pour estimer les coûts potentiels en utilisant la calculatrice de prix Azure. Pour plus d’informations, consultez Estimer les besoins et coûts de stockage des workflows dans des applications Azure Logic Apps monolocataires. |
| Environnement de service d’intégration (ISE) | Les ressources de stockage et leur utilisation sont jointes à la ressource d’application logique. | Non mesuré ni facturé. |
Pour plus d’informations, consultez la documentation suivante :
- Afficher les métriques pour les exécutions et l’utilisation du stockage
- Limites dans Azure Logic Apps
Passerelle de données locale
La passerelle de données locale est une ressource Azure distincte que vous créez pour que les flux de travail de votre application logique puissent accéder aux données locales en utilisant des connecteurs spécifiques pris en charge par la passerelle. La ressource de la passerelle elle-même n’entraîne pas de frais, mais les opérations qui s’exécutent via la passerelle sont facturées en fonction de la tarification et du modèle de facturation utilisés par votre application logique.
Comptes d’intégration
Un compte d’intégration est une ressource Azure distincte que vous créez en tant que conteneur pour définir et stocker des artefacts interentreprises (business-to-business, B2B) tels que des partenaires commerciaux, des contrats, des schémas, des mappages, etc. Après avoir créé ce compte et défini ces artefacts, liez ce compte à votre application logique afin de pouvoir utiliser ces artefacts et diverses opérations B2B dans des flux de travail pour explorer, générer et tester des solutions d’intégration qui utilisent les capacités de traitement EDI et XML.
Le tableau suivant résume la façon dont les modèles Consommation, Standard et ISE gèrent la mesure et la facturation des comptes d’intégration :
| Modèle | Métriques et facturation |
|---|---|
| Consommation (multilocataire) | La mesure de l’utilisation et la facturation utilisent la tarification des comptes d’intégration, en fonction du niveau de service du compte que vous utilisez. |
| Standard (monolocataire) | La mesure de l’utilisation et la facturation utilisent la tarification des comptes d’intégration, en fonction du niveau de service du compte que vous utilisez. |
| ISE | Ce modèle comprend un seul compte d’intégration basé sur votre niveau tarifaire ISE. Pour un coût supplémentaire, vous pouvez créer davantage de comptes d’intégration pour votre ISE à utiliser jusqu’à la limite totale de l’ISE. |
Pour plus d’informations, consultez la documentation suivante :
Autres éléments non mesurés ou facturés
Dans tous les modèles de tarification, les éléments suivants ne sont pas mesurés ni facturés :
- Actions qui n’ont pas été exécutées, car le flux de travail s’est arrêté avant la fin
- Applications logiques ou flux de travail désactivés, car ils ne peuvent pas créer de nouvelles instances tant qu’ils sont inactifs.