Gebruiksmeter, facturering en prijzen voor Azure Logic Apps
Van toepassing op: Azure Logic Apps (verbruik + standaard)
Met Azure Logic Apps kunt u geautomatiseerde integratiewerkstromen maken en uitvoeren die in de cloud kunnen worden geschaald. In dit artikel wordt beschreven hoe meet-, facturerings- en prijsmodellen werken voor Azure Logic Apps en gerelateerde resources. Raadpleeg de volgende inhoud voor informatie zoals specifieke prijstarieven, kostenplanning of verschillende hostingomgevingen:
- Prijzen voor Azure Logic Apps
- Kosten voor Azure Logic Apps plannen en beheren
- Omgeving met één tenant versus multitenant en integratieservice
Verbruik (multitenant)
In Azure Logic Apps met meerdere tenants volgen een logische app en de bijbehorende werkstroom het verbruiksabonnement voor prijzen en facturering. U maakt dergelijke logische apps op verschillende manieren, bijvoorbeeld wanneer u het resourcetype Logische app (verbruik) kiest, de extensie Azure Logic Apps (verbruik) in Visual Studio Code gebruikt of wanneer u automatiseringstaken maakt.
De volgende tabel geeft een overzicht van de manier waarop het verbruiksmodel omgaat met meting en facturering voor de volgende onderdelen wanneer deze worden gebruikt met een logische app en een werkstroom in Azure Logic Apps met meerdere tenants:
| Onderdeel | Meting en facturering |
|---|---|
| Trigger- en actiebewerkingen | Het verbruiksmodel bevat een eerste aantal gratis ingebouwde bewerkingen, per Azure-abonnement, die door een werkstroom kunnen worden uitgevoerd. Boven dit aantal is de meting van toepassing op elke uitvoering en de facturering volgt de acties-prijzen voor het verbruiksabonnement. Voor andere bewerkingstypen, zoals beheerde connectors, volgt facturering de standard - of enterprise-connectorprijzen voor het verbruiksabonnement. Raadpleeg Trigger- en actiebewerkingen in het verbruiksmodel voor meer informatie. |
| Opslagbewerkingen | Meting is alleen van toepassing op opslagverbruik met betrekking tot gegevensretentie , zoals het opslaan van invoer en uitvoer uit de uitvoeringsgeschiedenis van uw werkstroom. Facturering volgt de prijzen voor gegevensretentie voor het verbruiksabonnement. Raadpleeg Opslagbewerkingen voor meer informatie. |
| Integratieaccounts | De meting is van toepassing op basis van het integratieaccounttype dat u maakt en gebruikt met uw logische app. Facturering volgt de prijzen van integratieaccounts, tenzij uw logische app wordt geïmplementeerd en gehost in een integratieserviceomgeving (ISE). Raadpleeg Integratieaccounts voor meer informatie. |
Trigger- en actiebewerkingen in het verbruiksmodel
Met uitzondering van het initiële aantal gratis ingebouwde bewerkingen, per Azure-abonnement, dat een werkstroom kan worden uitgevoerd, meet en factureert het verbruiksmodel een bewerking op basis van elke uitvoering, ongeacht of de algehele werkstroom wordt uitgevoerd, voltooid of zelfs geïnstantieerd. Een bewerking voert meestal één uitvoering uit , tenzij voor de bewerking nieuwe pogingen zijn ingeschakeld. Bij een uitvoering wordt meestal één aanroep uitgevoerd, tenzij de bewerking ondersteuning biedt voor segmentering of paginering om grote hoeveelheden gegevens op te halen. Als segmentering of paginering is ingeschakeld, moet een bewerking mogelijk meerdere aanroepen uitvoeren.
Het verbruiksmodel meet en factureert een bewerking per uitvoering, niet per aanroep. Stel dat een werkstroom begint met een polling-trigger waarmee records worden opgehaald door regelmatig uitgaande aanroepen naar een eindpunt te maken. De uitgaande aanroep wordt gemeten en gefactureerd als één uitvoering, ongeacht of de trigger wordt geactiveerd of overgeslagen, bijvoorbeeld wanneer een trigger een eindpunt controleert, maar geen gegevens of gebeurtenissen vindt. De triggerstatus bepaalt of het werkstroomexemplaren worden gemaakt en uitgevoerd. Stel nu dat de bewerking ook segmentering of paginering ondersteunt en heeft ingeschakeld. Als de bewerking 10 aanroepen moet uitvoeren om het ophalen van alle gegevens te voltooien, wordt de bewerking nog steeds gemeten en gefactureerd als één uitvoering, ondanks het maken van meerdere aanroepen.
Notitie
Triggers die een matrix retourneren, hebben standaard de instelling Splitsen aan die al is ingeschakeld. Deze instelling resulteert in een trigger-gebeurtenis, die u kunt bekijken in de triggergeschiedenis, en een werkstroomexemplaren voor elk matrixitem. Alle werkstroomexemplaren worden parallel uitgevoerd, zodat de matrixitems tegelijkertijd worden verwerkt. Facturering is van toepassing op alle triggergebeurtenissen, ongeacht of de triggerstatus Geslaagd of Overgeslagen is. Triggers zijn nog steeds factureerbaar, zelfs in scenario's waarin de triggers de werkstroom niet instantiëren en starten, maar de triggerstatus Geslaagd, Mislukt of Overgeslagen is.
De volgende tabel geeft een overzicht van de manier waarop het verbruiksmodel meet- en facturering voor deze bewerkingstypen verwerkt wanneer deze worden gebruikt met een logische app en werkstroom in Azure Logic Apps met meerdere tenants:
| Het type bewerking | Beschrijving | Meting en facturering |
|---|---|---|
| Ingebouwd | Deze bewerkingen worden rechtstreeks en systeemeigen uitgevoerd met de Azure Logic Apps-runtime. In de ontwerpfunctie vindt u deze bewerkingen onder het label Ingebouwd . De HTTP-trigger en aanvraagtrigger zijn bijvoorbeeld ingebouwde triggers. De HTTP-actie en de reactieactie zijn ingebouwde acties. Andere ingebouwde bewerkingen zijn acties voor werkstroombeheer, zoals lussen en voorwaarden, gegevensbewerkingen, batchbewerkingen en andere. |
Het verbruiksmodel bevat een eerste aantal gratis ingebouwde bewerkingen, per Azure-abonnement, die door een werkstroom kunnen worden uitgevoerd. Boven dit aantal volgen ingebouwde bewerkingsuitvoeringen de prijzen voor acties. Opmerking: sommige beheerde connectorbewerkingen zijn ook beschikbaar als ingebouwde bewerkingen, die zijn opgenomen in de eerste gratis bewerkingen. Boven de initieel gratis bewerkingen volgt de facturering de prijzen voor Acties, niet de prijzen van de Standard- of Enterprise-connector. |
| Beheerde connector | Deze bewerkingen worden afzonderlijk uitgevoerd in Azure. In de ontwerpfunctie vindt u deze bewerkingen onder het label Standard of Enterprise . | Deze bewerkingsuitvoeringen volgen de standard- of enterprise-connectorprijzen. Opmerking: preview-uitvoeringen van enterprise-connectorbewerkingen volgen de prijzen van de verbruiksstandaardconnector. |
| Aangepaste connector | Deze bewerkingen worden afzonderlijk uitgevoerd in Azure. In de ontwerpfunctie vindt u deze bewerkingen onder het label Aangepast . Raadpleeg Aangepaste connectorlimieten in Azure Logic Apps voor limieten voor het aantal connectors, doorvoer en time-outs. | Deze bewerkingsuitvoeringen volgen de prijzen van de Standard-connector. |
Raadpleeg Ander bewerkingsgedrag voor meer informatie over hoe het verbruiksmodel werkt met bewerkingen die worden uitgevoerd in andere bewerkingen, zoals lussen, het verwerken van meerdere items, zoals matrices en beleid voor opnieuw proberen.
Tips voor kostenramingen voor het verbruiksmodel
Bekijk deze tips om u te helpen bij het schatten van nauwkeurigere verbruikskosten:
Houd rekening met het mogelijke aantal berichten of gebeurtenissen dat op een bepaalde dag kan binnenkomen, in plaats van uw berekeningen alleen te baseren op het polling-interval.
Wanneer een gebeurtenis of bericht aan de triggercriteria voldoet, proberen veel triggers onmiddellijk andere wachtende gebeurtenissen of berichten te lezen die aan de criteria voldoen. Dit gedrag houdt in dat ook als u een langere polling-interval selecteert, de trigger wordt geactiveerd op basis van het aantal gebeurtenissen in de wacht of berichten die in aanmerking komen voor het starten van werkstromen. Triggers die dit gedrag volgen, zijn onder andere Azure Service Bus en Azure Event Hubs.
Stel dat u een trigger instelt waarmee elke dag een eindpunt wordt gecontroleerd. Wanneer de trigger het eindpunt controleert en er vijftien gebeurtenissen vindt die aan de criteria voldoen, wordt de trigger geactiveerd en wordt de corresponderende werkstroom vijftien keer uitgevoerd. De Logic Apps-service meet alle acties die deze 15 werkstromen uitvoeren, inclusief de triggeraanvragen.
Standard (één tenant)
In Azure Logic Apps met één tenant volgen een logische app en de bijbehorende werkstromen het Standaardplan voor prijzen en facturering. U maakt dergelijke logische apps op verschillende manieren, bijvoorbeeld wanneer u het resourcetype Logische app (Standaard) kiest of de Azure Logic Apps-extensie (Standard) in Visual Studio Code gebruikt. Dit prijsmodel vereist dat logische apps gebruikmaken van een hostingabonnement en een prijscategorie, die verschilt van het verbruiksabonnement omdat u wordt gefactureerd voor gereserveerde capaciteit en toegewezen resources, ongeacht of u deze gebruikt of niet.
Wanneer u logische apps maakt of implementeert met het resourcetype Logische app (Standard) en u een Azure-regio selecteert voor implementatie, selecteert u ook een Workflow Standard-hostingabonnement. Als u echter een bestaande App Service Environment v3-resource selecteert voor uw implementatielocatie, moet u vervolgens een App Service-abonnement selecteren.
Belangrijk
De volgende abonnementen en resources zijn niet meer beschikbaar of worden niet meer ondersteund met de openbare release van het resourcetype Logic App (Standard) in Azure-regio's: Functions Premium-abonnement, App Service Environment v1 en App Service Environment v2. Met uitzondering van ASEv3 is het App Service-abonnement niet beschikbaar en niet ondersteund.
De volgende tabel geeft een overzicht van de manier waarop het Standard-model meting en facturering voor de volgende onderdelen verwerkt wanneer deze worden gebruikt met een logische app en een werkstroom in Azure Logic Apps met één tenant:
| Onderdeel | Meting en facturering |
|---|---|
| Virtuele CPU (vCPU) en geheugen | Het Standard-model vereist dat uw logische app gebruikmaakt van het Workflow Standard-hostingabonnement en een prijscategorie, die de resourceniveaus en prijstarieven bepaalt die van toepassing zijn op de reken- en geheugencapaciteit. Raadpleeg Prijscategorieën in het Standard-model voor meer informatie. |
| Trigger- en actiebewerkingen | Het Standard-model bevat een onbeperkt aantal gratis ingebouwde bewerkingen die door uw werkstroom kunnen worden uitgevoerd. Als uw werkstroom gebruikmaakt van beheerde connectorbewerkingen, is de meting van toepassing op elke aanroep, terwijl de facturering dezelfde standard - of enterprise-connectorprijzen volgt als het verbruiksabonnement. Raadpleeg Trigger- en actiebewerkingen in het Standaardmodel voor meer informatie. |
| Opslagbewerkingen | De meting is van toepassing op alle opslagbewerkingen die worden uitgevoerd door Azure Logic Apps. Opslagbewerkingen worden bijvoorbeeld uitgevoerd wanneer de service invoer en uitvoer van de uitvoeringsgeschiedenis van uw werkstroom opslaat. Facturering volgt de door u gekozen prijscategorie. Raadpleeg Opslagbewerkingen voor meer informatie. |
| Integratieaccounts | Als u een integratieaccount maakt voor uw logische app, wordt de meting gebaseerd op het type integratieaccount dat u maakt. Facturering volgt de prijzen van het integratieaccount. Raadpleeg Integratieaccounts voor meer informatie. |
Prijscategorieën in het Standard-model
De prijscategorie die u kiest voor meting en facturering voor uw resource logische app (Standard) bevat specifieke hoeveelheden rekenkracht in virtuele CPU-resources (vCPU) en geheugenresources. Als u een App Service Environment v3 als de implementatielocatie en een App Service-abonnement selecteert, met name een prijscategorie geïsoleerd V2-serviceplan, worden er kosten in rekening gebracht voor de exemplaren die worden gebruikt door het App Service-abonnement en voor het uitvoeren van uw logische app-werkstromen. Er zijn geen andere kosten van toepassing. Zie prijscategorieën voor App Service-abonnement - Geïsoleerd V2-serviceplan voor meer informatie.
Als u een Workflow Standard-hostingabonnement selecteert, kunt u kiezen uit de volgende lagen:
| Prijscategorie | Virtuele CPU (vCPU) | Geheugen (GB) |
|---|---|---|
| WS1 | 1 | 3,5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Belangrijk
Het volgende voorbeeld is alleen ter illustratie en bevat voorbeeldschattingen om over het algemeen te laten zien hoe een prijscategorie werkt. Voor specifieke vCPU- en geheugenprijzen op basis van specifieke regio's waar Azure Logic Apps beschikbaar is, raadpleegt u het Standaardabonnement voor een geselecteerde regio op de pagina Met prijzen voor Azure Logic Apps.
Stel dat in een voorbeeldregio de volgende resources de volgende uurtarieven hebben:
| Resource | Uurtarief (voorbeeldregio) |
|---|---|
| vCPU | $ 0,192 per vCPU |
| Geheugen | $ 0,0137 per GB |
De volgende berekening biedt een geschat maandelijks tarief:
<maandelijks tarief> = 730 uur (per maand) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> * <hourly-rate-GB-memory>)]
Op basis van de voorgaande informatie toont de volgende tabel de geschatte maandelijkse tarieven voor elke prijscategorie en de resources in die prijscategorie:
| Prijscategorie | Virtuele CPU (vCPU) | Geheugen (GB) | Maandtarief (voorbeeldregio) |
|---|---|---|---|
| WS1 | 1 | 3,5 | $ 175,16 |
| WS2 | 2 | 7 | $ 350,33 |
| WS3 | 4 | 14 | $ 700,65 |
Trigger- en actiebewerkingen in het Standard-model
Met uitzondering van de onbeperkte gratis ingebouwde bewerkingen die een werkstroom kan uitvoeren, meet en factureert het Standard-model een bewerking op basis van elke aanroep, ongeacht of de algehele werkstroom met succes wordt uitgevoerd, voltooid of zelfs geïnstantieerd. Een bewerking voert meestal één uitvoering uit , tenzij voor de bewerking nieuwe pogingen zijn ingeschakeld. Bij een uitvoering wordt meestal één aanroep uitgevoerd, tenzij de bewerking ondersteuning biedt voor segmentering of paginering om grote hoeveelheden gegevens op te halen. Als segmentering of paginering is ingeschakeld, moet een bewerking mogelijk meerdere aanroepen uitvoeren. Het Standard-model meet en factureert een bewerking per aanroep, niet per uitvoering.
Stel dat een werkstroom begint met een polling-trigger waarmee records worden opgehaald door regelmatig uitgaande aanroepen naar een eindpunt te maken. De uitgaande oproep wordt gemeten en gefactureerd, ongeacht of de trigger wordt geactiveerd of overgeslagen. De triggerstatus bepaalt of het werkstroomexemplaren worden gemaakt en uitgevoerd. Stel nu dat de bewerking ook segmentering of paginering ondersteunt en heeft ingeschakeld. Als de bewerking 10 aanroepen moet uitvoeren om het ophalen van alle gegevens te voltooien, wordt de bewerking gemeten en per aanroep gefactureerd.
De volgende tabel geeft een overzicht van de manier waarop het Standard-model omgaat met meting en facturering voor bewerkingstypen wanneer deze worden gebruikt met een logische app en werkstroom in Azure Logic Apps met één tenant:
| Het type bewerking | Beschrijving | Meting en facturering |
|---|---|---|
| Ingebouwd | Deze bewerkingen worden rechtstreeks en systeemeigen uitgevoerd met de Azure Logic Apps-runtime. In de ontwerpfunctie vindt u deze bewerkingen in de connectorgalerie onder Runtime>In-App. De HTTP-trigger en aanvraagtrigger zijn bijvoorbeeld ingebouwde triggers. De HTTP-actie en de reactieactie zijn ingebouwde acties. Andere ingebouwde bewerkingen zijn acties voor werkstroombeheer, zoals lussen en voorwaarden, gegevensbewerkingen, batchbewerkingen en andere. |
Het Standard-model bevat onbeperkte gratis ingebouwde bewerkingen. Opmerking: sommige beheerde connectorbewerkingen zijn ook beschikbaar als ingebouwde bewerkingen. Hoewel ingebouwde bewerkingen gratis zijn, meet en factureert het Standard-model beheerde connectorbewerkingen met dezelfde standard - of Enterprise-connectorprijzen als het verbruiksmodel. |
| Beheerde connector | Deze bewerkingen worden afzonderlijk uitgevoerd in gedeelde globale Azure. In de ontwerpfunctie vindt u deze bewerkingen in de connectorgalerie onder Gedeelde runtime>. | Het Standard-model meet en factureert beheerde connectorbewerkingen op basis van dezelfde standard - en enterprise-connectorprijzen als het verbruiksmodel. Opmerking: Preview Enterprise-connectorbewerkingen volgen de prijzen van de Standard-connector voor verbruik. |
| Aangepaste connector | Op dit moment kunt u alleen aangepaste ingebouwde connectorbewerkingen maken en gebruiken in werkstromen voor logische apps met één tenant. | Het Standard-model bevat onbeperkte gratis ingebouwde bewerkingen. Zie Limieten voor aangepaste connectors in Azure Logic Apps voor limieten voor doorvoer en time-out. |
Raadpleeg Ander bewerkingsgedrag voor meer informatie over hoe het Standard-model werkt met bewerkingen die worden uitgevoerd binnen andere bewerkingen, zoals lussen, het verwerken van meerdere items, zoals matrices en beleid voor opnieuw proberen.
Integratieserviceomgeving (ISE)
Wanneer u een logische app maakt met behulp van het resourcetype Logische app (verbruik) en u implementeert in een toegewezen integratieserviceomgeving (ISE), volgen de logische app en de bijbehorende werkstroom het Integration Service Environment-plan voor prijzen en facturering. Dit prijsmodel is afhankelijk van uw ISE-niveau of SKU en verschilt van het verbruiksabonnement omdat u wordt gefactureerd voor gereserveerde capaciteit en toegewezen resources, ongeacht of u deze gebruikt of niet.
De volgende tabel geeft een overzicht van de manier waarop het ISE-model omgaat met meting en facturering voor capaciteit en andere toegewezen resources op basis van uw ISE-niveau of SKU:
| ISE-SKU | Meting en facturering |
|---|---|
| Premium | De basiseenheid heeft een vaste capaciteit en wordt gefactureerd tegen een uurtarief voor de Premium-SKU. Als u meer doorvoer nodig hebt, kunt u meer schaaleenheden toevoegen wanneer u uw ISE maakt of daarna. Elke schaaleenheid wordt gefactureerd tegen een uurtarief dat ongeveer de helft van het basiseenheidtarief is. Zie ISE-limieten in Azure Logic Apps voor informatie over capaciteit en limieten. |
| Developer | De basiseenheid heeft een vaste capaciteit en wordt gefactureerd tegen een uurtarief voor de Ontwikkelaars-SKU. Deze SKU heeft echter geen SLA (Service Level Agreement), omhoog schalen of redundantie tijdens het recyclen, wat betekent dat u mogelijk vertragingen of downtime ondervindt. Back-endupdates kunnen de service af en toe onderbreken. Belangrijk: zorg ervoor dat u deze SKU alleen gebruikt voor verkenning, experimenten, ontwikkeling en testen, niet voor productie- of prestatietests. Zie ISE-limieten in Azure Logic Apps voor informatie over capaciteit en limieten. |
De volgende tabel geeft een overzicht van de manier waarop het ISE-model de volgende onderdelen verwerkt wanneer deze worden gebruikt met een logische app en een werkstroom in een ISE:
| Onderdeel | Beschrijving |
|---|---|
| Trigger- en actiebewerkingen | Het ISE-model bevat gratis ingebouwde, beheerde connector- en aangepaste connectorbewerkingen die door uw werkstroom kunnen worden uitgevoerd, maar onderhevig aan de ISE-limieten in Azure Logic Apps en aangepaste connectorlimieten in Azure Logic Apps. Raadpleeg Trigger- en actiebewerkingen in het ISE-model voor meer informatie. |
| Opslagbewerkingen | Het ISE-model omvat gratis opslagverbruik, zoals gegevensretentie. Raadpleeg Opslagbewerkingen voor meer informatie. |
| Integratieaccounts | Het ISE-model bevat één gratis integratieaccountlaag, op basis van de geselecteerde ISE-SKU. Tegen extra kosten kunt u meer integratieaccounts voor uw ISE maken om te gebruiken tot de totale ISE-limiet. Raadpleeg Integratieaccounts voor meer informatie. |
Trigger- en actiebewerkingen in het ISE-model
De volgende tabel geeft een overzicht van de manier waarop het ISE-model de volgende bewerkingstypen verwerkt wanneer deze worden gebruikt met een logische app en werkstroom in een ISE:
| Het type bewerking | Beschrijving | Meting en facturering |
|---|---|---|
| Ingebouwd | Deze bewerkingen worden rechtstreeks en systeemeigen uitgevoerd met de Azure Logic Apps-runtime en in dezelfde ISE als de werkstroom van uw logische app. In de ontwerpfunctie vindt u deze bewerkingen onder het label Ingebouwd , maar bij elke bewerking wordt ook het CORE-label weergegeven. De HTTP-trigger en aanvraagtrigger zijn bijvoorbeeld ingebouwde triggers. De HTTP-actie en de reactieactie zijn ingebouwde acties. Andere ingebouwde bewerkingen zijn acties voor werkstroombeheer, zoals lussen en voorwaarden, gegevensbewerkingen, batchbewerkingen en andere. |
Het ISE-model bevat deze bewerkingen gratis, maar zijn onderhevig aan de ISE-limieten in Azure Logic Apps. |
| Beheerde connector | Of het nu standard of enterprise is, beheerde connectorbewerkingen worden uitgevoerd in uw ISE of Azure met meerdere tenants, afhankelijk van het feit of de connector of bewerking het ISE-label weergeeft. - ISE-label : deze bewerkingen worden uitgevoerd in dezelfde ISE als uw logische app en werken zonder dat de on-premises gegevensgateway is vereist. - Geen ISE-label : deze bewerkingen worden uitgevoerd in Azure met meerdere tenants. |
Het ISE-model bevat zowel ISE - als geen ise-gelabelde bewerkingen gratis, maar zijn onderhevig aan de ISE-limieten in Azure Logic Apps. |
| Aangepaste connector | In de ontwerpfunctie vindt u deze bewerkingen onder het label Aangepast . | Het ISE-model bevat deze bewerkingen gratis, maar zijn onderhevig aan aangepaste connectorlimieten in Azure Logic Apps. |
Raadpleeg Ander bewerkingsgedrag voor meer informatie over hoe het ISE-model werkt met bewerkingen die worden uitgevoerd in andere bewerkingen, zoals lussen, meerdere items zoals matrices verwerken en beleid voor opnieuw proberen.
Ander bewerkingsgedrag
De volgende tabel geeft een overzicht van de manier waarop de modellen Verbruik, Standaard en ISE bewerkingen verwerken die worden uitgevoerd binnen andere bewerkingen, zoals lussen, meerdere items zoals matrices verwerken en beleidsregels voor opnieuw proberen:
| Bewerking | Beschrijving | Verbruik | Standard | ISE |
|---|---|---|---|---|
| Lusacties | Een lusactie, zoals de lus Voor elke of Tot , kan andere acties bevatten die tijdens elke luscyclus worden uitgevoerd. | Met uitzondering van het initiële aantal opgenomen ingebouwde bewerkingen, worden de lusactie en elke actie in de lus gemeten telkens wanneer de luscyclus wordt uitgevoerd. Als een actie items in een verzameling verwerkt, zoals een lijst of matrix, wordt het aantal items ook gebruikt in de berekening van de meting. Stel dat u een voor elke lus hebt met acties waarmee een lijst wordt verwerkt. De service vermenigvuldigt het aantal lijstitems met het aantal acties in de lus en voegt de actie toe waarmee de lus wordt gestart. De berekening voor een lijst met tien items is dus (10 * 1) + 1, wat resulteert in 11 actie-uitvoeringen. Prijzen zijn gebaseerd op het feit of de bewerkingstypen ingebouwd, Standard of Enterprise zijn. |
Met uitzondering van de opgenomen ingebouwde bewerkingen, hetzelfde als het verbruiksmodel. | Er wordt geen datalimiet in rekening gebracht. |
| Beleid voor opnieuw proberen | Voor ondersteunde bewerkingen kunt u eenvoudige uitzonderings- en foutafhandeling implementeren door een beleid voor opnieuw proberen in te stellen. | Met uitzondering van het initiële aantal ingebouwde bewerkingen, wordt de oorspronkelijke uitvoering plus elke opnieuw geprobeerde uitvoering gemeten. Een actie die bijvoorbeeld wordt uitgevoerd met 5 nieuwe pogingen, wordt gemeten en gefactureerd als 6 uitvoeringen. Prijzen zijn gebaseerd op het feit of de bewerkingstypen ingebouwd, Standard of Enterprise zijn. |
Met uitzondering van de ingebouwde opgenomen bewerkingen, hetzelfde als het verbruiksmodel. | Er wordt geen datalimiet in rekening gebracht. |
Opslagbewerkingen
Azure Logic Apps maakt gebruik van Azure Storage voor alle vereiste opslagtransacties, zoals het gebruik van wachtrijen voor het plannen van triggerbewerkingen of het gebruik van tabellen en blobs voor het opslaan van werkstroomstatussen. Op basis van de bewerkingen in uw werkstroom variëren de opslagkosten omdat verschillende triggers, acties en nettoladingen leiden tot verschillende opslagbewerkingen en -behoeften. De service slaat ook invoer en uitvoer van de uitvoeringsgeschiedenis van uw werkstroom op, op basis van de bewaarlimiet voor de uitvoeringsgeschiedenis van de logische app-resource. U kunt deze retentielimiet beheren op het niveau van de logische app-resource, niet op werkstroomniveau.
De volgende tabel geeft een overzicht van de manier waarop het verbruiks-, Standard- en ISE-model de meting en facturering voor opslagbewerkingen verwerken:
| Model | Beschrijving | Meting en facturering |
|---|---|---|
| Verbruik (multitenant) | Opslagresources en -gebruik zijn gekoppeld aan de resource van de logische app. | Meting en facturering zijn alleen van toepassing op opslagverbruik met betrekking tot gegevensretentie en volgen de prijzen voor gegevensretentie voor het verbruiksabonnement. |
| Standard (één tenant) | U kunt uw eigen Azure-opslagaccount gebruiken, waardoor u meer controle en flexibiliteit hebt over de gegevens van uw werkstroom. | Meting en facturering volgen het Azure Storage-prijsmodel. Opslagkosten worden afzonderlijk weergegeven op uw Azure-factuur. Tip: gebruik de Logic Apps Storage-calculator om meer inzicht te krijgen in het aantal opslagbewerkingen dat een werkstroom kan uitvoeren en de kosten ervan. Selecteer een voorbeeldwerkstroom of gebruik een bestaande werkstroomdefinitie. De eerste berekening maakt een schatting van het aantal opslagbewerkingen in uw werkstroom. U kunt deze getallen vervolgens gebruiken om een schatting te maken van mogelijke kosten met behulp van de Azure-prijscalculator. Zie Geschatte opslagbehoeften en -kosten voor werkstromen in Azure Logic Apps met één tenant voor meer informatie. |
| Integratieserviceomgeving (ISE) | Opslagresources en -gebruik zijn gekoppeld aan de resource van de logische app. | Er wordt geen datalimiet in rekening gebracht. |
Raadpleeg de volgende documentatie voor meer informatie:
On-premises gegevensgateway
De on-premises gegevensgateway is een afzonderlijke Azure-resource die u maakt, zodat uw logische app-werkstromen toegang hebben tot on-premises gegevens met behulp van specifieke gateway-ondersteunde connectors. Voor de gatewayresource zelf worden geen kosten in rekening gebracht, maar voor bewerkingen die via de gateway worden uitgevoerd, worden kosten in rekening gebracht op basis van het prijs- en factureringsmodel dat door uw logische app wordt gebruikt.
Integratieaccounts
Een integratieaccount is een afzonderlijke Azure-resource die u maakt als een container voor het definiëren en opslaan van B2B-artefacten (business-to-business), zoals handelspartners, overeenkomsten, schema's, kaarten, enzovoort. Nadat u dit account hebt gemaakt en deze artefacten hebt gedefinieerd, koppelt u dit account aan uw logische app, zodat u deze artefacten en verschillende B2B-bewerkingen in werkstromen kunt gebruiken om integratieoplossingen te verkennen, bouwen en testen die gebruikmaken van EDI- en XML-verwerkingsmogelijkheden .
De volgende tabel bevat een overzicht van de manier waarop het verbruiks-, Standard- en ISE-model metering en facturering voor integratieaccounts verwerken:
| Model | Meting en facturering |
|---|---|
| Verbruik (multitenant) | Meting en facturering maken gebruik van de prijzen voor integratieaccounts, op basis van de accountlaag die u gebruikt. |
| Standard (één tenant) | Meting en facturering maken gebruik van de prijzen voor integratieaccounts, op basis van de accountlaag die u gebruikt. |
| ISE | Dit model bevat één integratieaccount, op basis van uw ISE-SKU. Tegen extra kosten kunt u meer integratieaccounts voor uw ISE maken om te gebruiken tot de totale ISE-limiet. |
Raadpleeg de volgende documentatie voor meer informatie:
Andere items zonder datalimiet of gefactureerd
Voor alle prijsmodellen worden de volgende items niet naar gebruik gebracht of gefactureerd:
- Acties die niet zijn uitgevoerd omdat de werkstroom is gestopt voordat deze is voltooid
- Logische apps of werkstromen uitgeschakeld omdat ze geen nieuwe exemplaren kunnen maken terwijl ze inactief zijn.