Modeller för användningsmätning, fakturering och prissättning för Azure Logic Apps

  • Artikel
  • 16 minuter för att läsa

Azure Logic Apps hjälper dig att skapa och köra automatiserade integreringsarbetsflöden som kan skalas i molnet. Den här artikeln beskriver hur modeller för mätning, fakturering och prissättning fungerar för Azure Logic Apps och relaterade resurser. Information om till exempel specifika priser, kostnadsplanering eller olika värdmiljöer finns i följande innehåll:

Förbrukning (flera innehavare)

I en Azure Logic Apps klientorganisation följer en logikapp och dess arbetsflöde förbrukningsplanen för priser och fakturering. Du skapar sådana logikappar på olika sätt, till exempel när du väljer resurstypen Logikapp (förbrukning), använder tillägget Azure Logic Apps (förbrukning) i Visual Studio Code eller när du skapar automatiseringsuppgifter.

I följande tabell sammanfattas hur förbrukningsmodellen hanterar mätning och fakturering för följande komponenter när den används med en logikapp och ett arbetsflöde i Azure Logic Apps:

Komponent Mätning och fakturering
Utlösar- och åtgärdsåtgärder Förbrukningsmodellen innehåller ett inledande antal kostnadsfria inbyggda åtgärder per Azure-prenumeration som ett arbetsflöde kan köra. Över det här antalet gäller mätning för varje körning, och faktureringen följer priserna för åtgärder för förbrukningsplanen. För andra åtgärdstyper, till exempel hanterade anslutningsappar, följer faktureringen standard- eller Enterprise-anslutningsprogrampriset för förbrukningsplanen. Mer information finns i Utlösare och åtgärdsåtgärder i förbrukningsmodellen.
Storage åtgärder Mätning gäller endast för datalagringsrelaterad lagringsförbrukning, till exempel att spara indata och utdata från arbetsflödets körningshistorik. Faktureringen följer prissättningen för datalagring för förbrukningsplanen. Mer information finns i Storage åtgärder.
Integrationskonton Mätningen gäller baserat på den typ av integrationskonto som du skapar och använder med logikappen. Faktureringen följer prissättningen för integrationskontot såvida inte logikappen distribueras och finns i en integrationstjänstmiljö (ISE). Mer information finns i Integrationskonton.

Utlösar- och åtgärdsåtgärder i förbrukningsmodellen

Förutom det inledande antalet kostnadsfria inbyggda åtgärdskörningar per Azure-prenumeration som ett arbetsflöde kan köra mäter och fakturerar förbrukningsmodellen en åtgärd baserat på varje körning, oavsett om det övergripande arbetsflödet har körts, slutförts eller till och med instansieras. En åtgärd gör vanligtvis en enda körning om inte återförsök har aktiverats för åtgärden. I sin tur gör en körning vanligtvis ett enda anrop om inte åtgärden stöder och möjliggör segmenteringeller sidnumrering för att hämta stora mängder data . Om segmentering eller sidnumrering är aktiverat kan en åtgärdskörning behöva göra flera anrop. Förbrukningsmodellen mäter och fakturerar en åtgärd per körning, inte per anrop.

Anta till exempel att ett arbetsflöde börjar med en avsökningsutlösare som hämtar poster genom att regelbundet göra utgående anrop till en slutpunkt. Det utgående anropet mäts och faktureras som en enskild körning, oavsett om utlösaren utlöses eller hoppas över, till exempel när en utlösare kontrollerar en slutpunkt men inte hittar några data eller händelser. Utlösartillståndet styr om arbetsflödesinstansen skapas och körs. Anta nu att åtgärden också stöder och har aktiverat segmentering eller sidnumrering. Om åtgärden måste göra 10 anrop för att slutföra att hämta alla data, mäts åtgärden fortfarande och faktureras som en enda körning , trots att den gör flera anrop.

I följande tabell sammanfattas hur förbrukningsmodellen hanterar mätning och fakturering för dessa åtgärdstyper när den används med en logikapp och ett arbetsflöde i Azure Logic Apps:

Åtgärdstyp Description Mätning och fakturering
Inbyggd De här åtgärderna körs direkt och inbyggt Azure Logic Apps körningskörningen. I designern hittar du de här åtgärderna under etiketten Inbyggd.

HTTP-utlösaren och begärandeutlösaren är till exempel inbyggda utlösare. HTTP-åtgärden och svarsåtgärden är inbyggda åtgärder. Andra inbyggda åtgärder är åtgärder för arbetsflödeskontroll, till exempel loopar och villkor, dataåtgärder, batchåtgärder med mera.

 Förbrukningsmodellen innehåller ett inledande antal kostnadsfria inbyggda åtgärder, per Azure-prenumeration, som ett arbetsflöde kan köra. Ovanför det här antalet följer inbyggda åtgärdskörningar priser för åtgärder.

Obs! Vissa åtgärder för hanterade anslutningsappar är också tillgängliga som inbyggda åtgärder, som ingår i de första kostnadsfria åtgärderna. Ovanför de första kostnadsfria åtgärderna följer faktureringen priser för åtgärder,inte standard- eller Enterprise-anslutningarna.
Hanterad anslutningsapp De här åtgärderna körs separat i Azure. Du hittar de här åtgärderna under etiketten Standard eller Enterprise i designern. De här åtgärdskörningarna följer standard- eller Enterprise-anslutningarnas priser.

Obs! Förhandsgranskning av körningar av enterprise-anslutningsappar följer du prissättningen för förbrukningsstandardanslutningsappen.
Anpassad anslutningsapp De här åtgärderna körs separat i Azure. Du hittar de här åtgärderna under etiketten Anpassad i designern. Information om hur många anslutningsappar, dataflöde och tidsgränser som gäller finns i Anpassade anslutningsgränser i Azure Logic Apps. Dessa åtgärdskörningar följer standardanslutningspriset.

Mer information om hur förbrukningsmodellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbetar flera objekt, till exempel matriser och återförsöksprinciper, finns i Övrigt åtgärdsbeteende.

Tips för kostnadsuppskattning för förbrukningsmodellen

Om du vill hjälpa dig att beräkna mer exakta förbrukningskostnader kan du läsa följande tips:

  • Överväg det möjliga antalet meddelanden eller händelser som kan komma under en viss dag, i stället för att endast basera dina beräkningar på avsökningsintervallet.

  • När en händelse eller ett meddelande uppfyller utlösarkriterierna försöker många utlösare omedelbart läsa andra väntande händelser eller meddelanden som uppfyller villkoren. Det här beteendet innebär att utlösaren utlöses baserat på antalet väntande händelser eller meddelanden som är kvalificerade för att starta arbetsflöden även när du väljer ett längre avsökningsintervall. Utlösare som följer det här beteendet inkluderar Azure Service Bus och Azure Event Hub.

    Anta till exempel att du ställer in en utlösare som kontrollerar en slutpunkt varje dag. När utlösaren kontrollerar slutpunkten och hittar 15 händelser som uppfyller kriterierna utlöses utlösaren och kör motsvarande arbetsflöde 15 gånger. Tjänsten Logic Apps alla åtgärder som dessa 15 arbetsflöden utför, inklusive utlösarbegäranden.

Standard (en enda klient)

I en Azure Logic Apps följer en logikapp och dess arbetsflöden standardplanen för prissättning och fakturering. Du skapar sådana logikappar på olika sätt, till exempel när du väljer resurstypen Logikapp (Standard) eller använder Azure Logic Apps-tillägget (Standard) i Visual Studio Code. Den här prismodellen kräver att logikappar använder en värdplan och en prisnivå, som skiljer sig från förbrukningsplanen eftersom du debiteras för reserverad kapacitet och dedikerade resurser oavsett om du använder dem eller inte.

När du skapar eller distribuerar logikappar med resurstypen Logikapp (Standard) kan du använda värdplanen arbetsflödesstandard i alla Azure-regioner. Du kan också välja en befintlig App Service-miljön v3-resurs som distributionsplats, men du kan bara använda App Service plan med det här alternativet. Om du väljer det här alternativet debiteras du för de instanser som används av App Service plan och för att köra dina logikapparbetsflöden. Inga andra avgifter tillkommer.

Viktigt

Följande planer och resurser är inte längre tillgängliga eller stöds med den offentliga versionen av resurstypen Logikapp (standard) i Azure-regioner: Functions Premium-plan, App Service-miljön v1 och App Service-miljön v2. Förutom ASEv3 är App Service plan inte tillgänglig och stöds inte.

I följande tabell sammanfattas hur Standard-modellen hanterar mätning och fakturering för följande komponenter när den används med en logikapp och ett arbetsflöde i en enda klientorganisation Azure Logic Apps:

Komponent Mätning och fakturering
Virtuell CPU (vCPU) och minne Standardmodellen kräver att logikappen använder värdplanen arbetsflödesstandard och en prisnivå som avgör vilka resursnivåer och priser som gäller för beräknings- och minneskapacitet. Mer information finns i Prisnivåer i standardmodellen.
Utlösar- och åtgärdsåtgärder Standardmodellen innehåller ett obegränsat antal kostnadsfria inbyggda åtgärder som arbetsflödet kan köra.

Om arbetsflödet använder hanterade anslutningsåtgärder gäller mätning för dessa åtgärder för varje anrop, medan faktureringen följer samma standard- eller Enterprise-anslutningsprogrampriser som förbrukningsplanen. Mer information finns i Utlösare och åtgärdsåtgärder i standardmodellen.
Storage åtgärder Mätning gäller för alla lagringsåtgärder som körs av Azure Logic Apps. Lagringsåtgärder kan till exempel köras när tjänsten sparar indata och utdata från arbetsflödets körningshistorik. Faktureringen följer din valda prisnivå. Mer information finns i Storage åtgärder.
Integrationskonton Om du skapar ett integrationskonto som logikappen ska använda baseras mätningen på den integrationskontotyp som du skapar. Faktureringen följer prissättningen för integrationskontot. Mer information finns i Integrationskonton.

Prisnivåer i standardmodellen

Den prisnivå som du väljer för mätning och fakturering av logikappen innehåller specifika mängder beräkning i virtuella CPU-resurser (vCPU) och minnesresurser. För närvarande är endast arbetsflödesstandardvärdplanen tillgänglig för resurstypen Logic App (Standard) och erbjuder följande prisnivåer:

Prisnivå Virtuell CPU (vCPU) Minne (GB)
WS1 1 3.5
WS2 2 7
WS3 4 14

Viktigt

Följande exempel är endast för illustration och ger exempeluppskattningar som vanligtvis visar hur en prisnivå fungerar. För specifika priser för vCPU och minne baserat på specifika regioner där Azure Logic Apps är tillgängligt kan du läsa standardplanen för en vald region Azure Logic Apps sidan med priser.

Anta att följande resurser i en exempelregion har dessa timpriser:

Resurs Timpris (exempelregion)
Virtuell processor 0,192 USD per vCPU
Minne 0,0137 USD per GB

Följande beräkning ger ett beräknat månatligt pris:

<monthly-rate> = 730 timmar (per månad) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> * <hourly-rate-GB-memory>)]

Baserat på föregående information visar följande tabell de uppskattade månadspriserna för varje prisnivå och resurserna på den prisnivån:

Prisnivå Virtuell CPU (vCPU) Minne (GB) Månadspris (exempelregion)
WS1 1 3.5 175,16 USD
WS2 2 7 350,33 USD
WS3 4 14 700,65 USD

Utlösar- och åtgärdsåtgärder i standardmodellen

Förutom de obegränsade kostnadsfria inbyggda åtgärder som ett arbetsflöde kan köra mäter och fakturerar Standard-modellen en åtgärd baserat på varje anrop, oavsett om det övergripande arbetsflödet körs, slutförs eller ens instansieras. En åtgärd gör vanligtvis en enda körning om inte återförsök har aktiverats för åtgärden. I sin tur gör en körning vanligtvis ett enda anrop om inte åtgärden stöder och gör att segmenteringeller sidnumrering kan hämta stora mängder data . Om segmentering eller sidnumrering är aktiverat kan en åtgärdskörning behöva göra flera anrop. Standardmodellen mäter och fakturerar en åtgärd per anrop, inte per körning.

Anta till exempel att ett arbetsflöde börjar med en avsökningsutlösare som hämtar poster genom att regelbundet göra utgående anrop till en slutpunkt. Det utgående anropet mäts och faktureras, oavsett om utlösaren utlöses eller hoppas över. Utlösartillståndet styr huruvida arbetsflödesinstansen skapas och körs. Anta nu att åtgärden också stöder och har aktiverat segmentering eller sidnumrering. Om åtgärden måste göra 10 anrop för att slutföra att hämta alla data mäts åtgärden och faktureras per anrop.

I följande tabell sammanfattas hur standardmodellen hanterar mätning och fakturering för åtgärdstyper när den används med en logikapp och ett arbetsflöde i en Azure Logic Apps:

Åtgärdstyp Description Mätning och fakturering
Inbyggd Dessa åtgärder körs direkt och inbyggt med Azure Logic Apps-körningen. I designern hittar du de här åtgärderna under etiketten Inbyggd.

HTTP-utlösaren och begärandeutlösaren är till exempel inbyggda utlösare. HTTP-åtgärden och svarsåtgärden är inbyggda åtgärder. Andra inbyggda åtgärder är åtgärder för arbetsflödeskontroll, till exempel loopar och villkor, dataåtgärder, batchåtgärder med mera.

 Standardmodellen innehåller obegränsade kostnadsfria inbyggda åtgärder.

Obs! Vissa åtgärder för hanterade anslutningsappar är också tillgängliga som inbyggda åtgärder. Även om inbyggda åtgärder är kostnadsfria mäter och fakturerar standardmodellen fortfarande hanterade anslutningsåtgärder med samma standard- eller Enterprise-anslutning som förbrukningsmodellen.
Hanterad anslutningsapp De här åtgärderna körs separat i Azure. I designern hittar du de här åtgärderna under den kombinerade Azure-etiketten. Standardmodellen mäter och fakturerar hanterade anslutningsåtgärder baserat på samma standard- och Enterprise-anslutning som förbrukningsmodellen.

Obs! Förhandsgranskning av åtgärder för Enterprise-anslutning följer du prissättningen för förbrukningsstandardanslutningsappen.
Anpassad anslutningsapp För närvarande kan du bara skapa och använda anpassade inbyggda anslutningsåtgärder i arbetsflöden för logikappar baserade på en klientorganisation. Standardmodellen innehåller obegränsade kostnadsfria inbyggda åtgärder. Information om gränser för dataflöde och tidsgränser finns i Begränsningar för anpassade anslutningsappar i Azure Logic Apps.

Mer information om hur standardmodellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbetar flera objekt, till exempel matriser och återförsöksprinciper, finns i Övrigt åtgärdsbeteende.

Integration Service Environment (ISE)

När du skapar en logikapp med hjälp av resurstypen Logikapp (förbrukning) och distribuerar till en dedikerad integrationstjänstmiljö (ISE),följer logikappen och dess arbetsflöde Integration Service Environment-planen för prissättning och fakturering. Den här prismodellen beror på din ISE-nivå eller SKU och skiljer sig från förbrukningsplanen på så sätt att du debiteras för reserverad kapacitet och dedikerade resurser oavsett om du använder dem eller inte.

I följande tabell sammanfattas hur ISE-modellen hanterar mätning och fakturering för kapacitet och andra dedikerade resurser baserat på DIN ISE-nivå eller SKU:

ISE SKU Mätning och fakturering
Premium Basenheten har fast kapacitet och faktureras till ett timpris för den Premium SKU:n. Om du behöver mer dataflöde kan du lägga till fler skalningsenheter när du skapar ise-enheten eller efteråt. Varje skalningsenhet debiteras till ett timpris som är ungefär hälften av basenhetspriset.

Information om kapacitet och begränsningar finns i ISE-gränser i Azure Logic Apps.
Utvecklare Basenheten har fast kapacitet och debiteras till ett timpris för Developer-SKU:n. Denna SKU har dock inget serviceavtal (SLA), uppskalningskapacitet eller redundans under återanvändning, vilket innebär att det kan uppstå fördröjningar eller driftstopp. Backend-uppdateringar kan tillfälligt avbryta tjänsten.

Viktigt! Se till att du endast använder den här SKU:n för utforskning, experiment, utveckling och testning – inte för produktions- eller prestandatestning.

Information om kapacitet och begränsningar finns i ISE-gränser i Azure Logic Apps.

I följande tabell sammanfattas hur ISE-modellen hanterar följande komponenter när den används med en logikapp och ett arbetsflöde i en ISE:

Komponent Beskrivning
Utlösar- och åtgärdsåtgärder ISE-modellen innehåller kostnadsfria inbyggda, hanterade anslutningsappar och anpassade anslutningsåtgärder som arbetsflödet kan köra, men som omfattas av ISE-gränserna i Azure Logic Apps och anpassade anslutningsappar i Azure Logic Apps. Mer information finns i Utlösare och åtgärdsåtgärder i ISE-modellen.
Storage åtgärder ISE-modellen innehåller kostnadsfri lagringsförbrukning, till exempel datalagring. Mer information finns i Storage åtgärder.
Integrationskonton ISE-modellen innehåller en enda kostnadsfri integrationskontonivå, baserat på din valda ISE SKU. För en extra kostnadkan du skapa fler integrationskonton för din ISE för att använda upp till den totala ISE-gränsen. Mer information finns i Integrationskonton.

Utlösar- och åtgärdsåtgärder i ISE-modellen

I följande tabell sammanfattas hur ISE-modellen hanterar följande åtgärdstyper när den används med en logikapp och ett arbetsflöde i en ISE:

Åtgärdstyp Description Mätning och fakturering
Inbyggd Dessa åtgärder körs direkt och inbyggt med Azure Logic Apps och i samma ISE som logikappens arbetsflöde. I designern hittar du de här åtgärderna under den inbyggda etiketten, men varje åtgärd visar även CORE-etiketten.

HTTP-utlösaren och begärandeutlösaren är till exempel inbyggda utlösare. HTTP-åtgärden och svarsåtgärden är inbyggda åtgärder. Andra inbyggda åtgärder är åtgärder för arbetsflödeskontroll, till exempel loopar och villkor, dataåtgärder, batchåtgärder med mera.

 ISE-modellen innehåller dessa åtgärder utan kostnad, men omfattas av ISE-gränserna i Azure Logic Apps.
Hanterad anslutningsapp Oavsett om det är Standard eller Enterprise körs hanterade anslutningsåtgärder i ise- eller flerklients-Azure, baserat på om anslutningsappen eller åtgärden visar ISE-etiketten.

- ISE-etikett: De här åtgärderna körs i samma ISE som logikappen och fungerar utan att den lokala datagatewayen krävs.

– Ingen ISE-etikett: De här åtgärderna körs i Azure för flera innehavare.

 ISE-modellen innehåller både ISE och inga ISE-märkta åtgärder utan kostnad, men omfattas av ISE-gränserna i Azure Logic Apps.
Anpassad anslutningsapp Du hittar de här åtgärderna under etiketten Anpassad i designern. ISE-modellen innehåller dessa åtgärder utan kostnad, men omfattas av anpassade anslutningsgränser i Azure Logic Apps.

Mer information om hur ISE-modellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbetar flera objekt, till exempel matriser och återförsöksprinciper, finns i Övrigt åtgärdsbeteende.

Andra åtgärdsbeteenden

I följande tabell sammanfattas hur förbruknings-, standard- och ISE-modellerna hanterar åtgärder som körs i andra åtgärder, till exempel loopar, bearbetar flera objekt, till exempel matriser och återförsöksprinciper:

Åtgärd Description Förbrukning Standard ISE
Loopåtgärder En loopåtgärd, till exempel for each- eller Until-loopen, kan innehålla andra åtgärder som körs under varje loopcykel. Förutom det inledande antalet inkluderade inbyggda åtgärder mäts loopåtgärden och varje åtgärd i loopen varje gång loopcykeln körs. Om en åtgärd bearbetar objekt i en samling, till exempel en lista eller matris, används även antalet objekt i mätningsberäkningen.

Anta till exempel att du har en For each-loop med åtgärder som bearbetar en lista. Tjänsten multiplicerar antalet listobjekt mot antalet åtgärder i loopen och lägger till åtgärden som startar loopen. Så beräkningen för en lista med 10 objekt är (10 * 1) + 1, vilket resulterar i 11 åtgärdskörningar.

Prissättningen baseras på om åtgärdstyperna är inbyggda, Standard eller Enterprise.

 Förutom de inkluderade inbyggda åtgärderna, samma som förbrukningsmodellen. Inte debiterad eller debiterad.
Återförsöksprinciper För åtgärder som stöds kan du implementera grundläggande undantags- och felhantering genom att konfigurera en återförsöksprincip. Förutom det inledande antalet inbyggda åtgärder mäts den ursprungliga körningen plus varje återkörningskörning. Till exempel mäts en åtgärd som körs med 5 återförsök och faktureras som 6 körningar.

Prissättningen baseras på om åtgärdstyperna är inbyggda, Standard eller Enterprise.

 Förutom de inbyggda åtgärderna som ingår, samma som förbrukningsmodellen. Inte debiterad eller debiterad.

Storage åtgärder

Azure Logic Apps använder Azure Storage för alla nödvändiga lagringstransaktioner, till exempel för att använda köer för schemaläggning av utlösaråtgärder eller för att använda tabeller och blobar för att lagra arbetsflödes tillstånd. Baserat på åtgärderna i arbetsflödet varierar lagringskostnaderna eftersom olika utlösare, åtgärder och nyttolaster resulterar i olika lagringsåtgärder och behov. Tjänsten sparar och lagrar även indata och utdata från arbetsflödets körningshistorik baserat på logikappresursens kvarhållningsgräns för körningshistorik. Du kan hantera den här kvarhållningsgränsen på logikappens resursnivå, inte på arbetsflödesnivå.

I följande tabell sammanfattas hur förbruknings-, standard- och ISE-modellerna hanterar mätning och fakturering för lagringsåtgärder:

Modell Description Mätning och fakturering
Förbrukning (flera innehavare) Storage resurser och användning är kopplade till logikappresursen. Mätning och fakturering gäller endast för datalagringsrelaterad lagringsförbrukning och följer priserna för datalagring för förbrukningsplanen.
Standard (en enda klient) Du kan använda ditt eget Azure Storage-konto,vilket ger dig mer kontroll och flexibilitet över arbetsflödets data. Mätning och fakturering följer Azure Storage prismodellen. Storage visas separat på din Azure-faktureringsfaktura.

Tips: Om du vill få en bättre förståelse för antalet lagringsåtgärder som ett arbetsflöde kan köra och deras kostnader kan du prova att använda Logic Apps Storage kalkylatorn. Välj antingen ett exempelarbetsflöde eller använd en befintlig arbetsflödesdefinition. Den första beräkningen beräknar antalet lagringsåtgärder i arbetsflödet. Du kan sedan använda dessa siffror för att beräkna möjliga kostnader med hjälp av priskalkylatorn för Azure. Mer information finns i Estimate storage needs and costs for workflows in single-tenant Azure Logic Apps.
Integration Service Environment (ISE) Storage resurser och användning är kopplade till logikappresursen. Inte debiterad eller debiterad.

Mer information finns i följande dokumentation:

Lokal datagateway

Den lokala datagatewayen är en separat Azure-resurs som du skapar så att dina logikapparbetsflöden kan komma åt lokala data med hjälp av specifika anslutningsappar som stöds av gatewayen. Själva gatewayresursen medför inga avgifter, men åtgärder som körs via gatewayen medför avgifter, baserat på den prissättning och faktureringsmodell som används av logikappen.

Integrationskonton

Ett integrationskonto är en separat Azure-resurs som du skapar som en container för att definiera och lagra B2B-artefakter (business-to-business), till exempel handelspartner, avtal, scheman, kartor och så vidare. När du har skapat det här kontot och definierat dessa artefakter länkar du det här kontot till logikappen så att du kan använda dessa artefakter och olika B2B-åtgärder i arbetsflöden för att utforska, skapa och testa integreringslösningar som använder EDI- och XML-bearbetningsfunktioner.

I följande tabell sammanfattas hur förbruknings-, standard- och ISE-modellerna hanterar mätning och fakturering för integrationskonton:

Modell Mätning och fakturering
Förbrukning (flera innehavare) Mätning och fakturering använder integrationskontots prissättning,baserat på den kontonivå som du använder.
Standard (en enda klient) Mätning och fakturering använder integrationskontots prissättning,baserat på den kontonivå som du använder.
ISE Den här modellen innehåller ett enda integrationskonto, baserat på din ISE SKU. För en extra kostnadkan du skapa fler integrationskonton för din ISE för att använda upp till den totala ISE-gränsen.

Mer information finns i följande dokumentation:

Andra objekt mäts inte eller faktureras inte

I alla prissättningsmodeller mäts eller faktureras inte följande objekt:

  • Åtgärder som inte har körts eftersom arbetsflödet stoppades innan det slutförde
  • Logikappar eller arbetsflöden har inaktiverats eftersom de inte kan skapa nya instanser när de är inaktiva.

Nästa steg