Användningsmätning, fakturering och priser för Azure Logic Apps
Gäller för: Azure Logic Apps (Förbrukning + Standard)
Med Azure Logic Apps kan du skapa och köra automatiserade integrationsarbetsflöden som kan skalas i molnet. Den här artikeln beskriver hur mätnings-, fakturerings- och prismodeller 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:
- Prisnivåer för Azure Logic Apps
- Planera och hantera kostnader för Azure Logic Apps
- Miljö för en klientorganisation jämfört med flera klientorganisationer och integrationstjänst
Förbrukning (flera klientorganisationer)
I Azure Logic Apps för flera klientorganisationer 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 med flera klientorganisationer:
| 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 talet gäller mätning för varje körning, och faktureringen följer prissättningen Åtgärder för förbrukningsplanen. För andra åtgärdstyper, till exempel hanterade anslutningsappar, följer faktureringen standard- eller enterprise-anslutningsprogrammets priser för förbrukningsplanen. Mer information finns i Utlösare och åtgärdsåtgärder i förbrukningsmodellen. |
| Lagringsåtgärder | Mätning gäller endast för lagringsrelaterad lagringsförbrukning som att spara indata och utdata från arbetsflödets körningshistorik. Faktureringen följer datakvarhållningspriset för förbrukningsplanen. Mer information finns i Lagringsåtgärder. |
| Integrationskonton | Mätningen gäller baserat på den integrationskontotyp som du skapar och använder med logikappen. Faktureringen följer prissättningen för integrationskontot såvida inte logikappen distribueras och hanteras i en integrationstjänstmiljö (ISE). Mer information finns i Integration-konton. |
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 förbrukningsmodellen och fakturerar en åtgärd baserat på varje körning, oavsett om det övergripande arbetsflödet körs, slutförs eller till och med instansieras. En åtgärd utfö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 aktiverar segmentering eller 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 enda 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 hämtar alla data, mäts åtgärden fortfarande och faktureras som en enda körning, trots att flera anrop görs.
Anteckning
Som standard har utlösare som returnerar en matris en delningsinställning som redan är aktiverad. Den här inställningen resulterar i en utlösarhändelse som du kan granska i utlösarhistoriken och en arbetsflödesinstans för varje matrisobjekt. Alla arbetsflödesinstanser körs parallellt så att matrisobjekten bearbetas samtidigt. Fakturering gäller för alla utlösarhändelser oavsett om utlösartillståndet är Lyckades eller Hoppades över. Utlösare kan fortfarande faktureras även i scenarier där utlösarna inte instansierar och startar arbetsflödet, men utlösartillståndet är Lyckades, Misslyckades eller Hoppades över.
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 med flera klientorganisationer:
| Åtgärdstyp | Beskrivning | Mätning och fakturering |
|---|---|---|
| Inbyggd | Dessa åtgärder körs direkt och internt med Azure Logic Apps-körningen. I designern hittar du dessa åtgärder under den inbyggda etiketten. HTTP-utlösaren och utlösaren Förfrågning ä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. Utöver det här antalet följer inbyggda åtgärdskörningar prissättningen å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. Utöver de initialt kostnadsfria åtgärderna följer faktureringen prissättningen Åtgärder, inte prissättningen för Standard- eller Enterprise-anslutningsappen. |
| Hanterad anslutningsapp | Dessa åtgärder körs separat i Azure. I designern hittar du dessa åtgärder under etiketten Standard eller Enterprise . | Dessa åtgärdskörningar följer prissättningen för Standard- eller Enterprise-anslutningsappen. Obs! Förhandsgranskning av körning av enterprise-anslutningsappar följer du prissättningen för förbrukningsstandardanslutningsappen. |
| Anpassad anslutningsapp | Dessa åtgärder körs separat i Azure. I designern hittar du dessa åtgärder under etiketten Anpassad . Om du vill ha begränsningar för antalet anslutningsappar, dataflöde och tidsgränser läser du Gränser för anpassade anslutningsappar i Azure Logic Apps. | De här åtgärdskörningarna följer standardanslutningspriset. |
Mer information om hur förbrukningsmodellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbeta flera objekt, till exempel matriser och återförsöksprinciper, finns i Andra åtgärdsbeteenden.
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 att tas emot en viss dag, i stället för att basera dina beräkningar på endast 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 kriterierna. Det här beteendet innebär att även när du väljer ett längre avsökningsintervall utlöses utlösaren baserat på antalet väntande händelser eller meddelanden som är kvalificerade för att starta arbetsflöden. Utlösare som följer det här beteendet omfattar Azure Service Bus och Azure Event Hubs.
Anta till exempel att du konfigurerar 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. Logic Apps-tjänsten mäter alla åtgärder som dessa 15 arbetsflöden utför, inklusive utlösarbegäranden.
Standard (enskild klientorganisation)
I Azure Logic Apps med en enda klient 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 Tillägget Azure Logic Apps (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 genom att 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), och du väljer valfri Azure-region för distribution, väljer du även en arbetsflödesstandardvärdplan. Men om du väljer en befintlig App Service-miljön v3-resurs för distributionsplatsen måste du välja en App Service plan.
Viktigt
Följande planer och resurser är inte längre tillgängliga eller stöds inte med den offentliga versionen av logikappens (Standard) resurstyp i Azure-regioner: Functions Premium-plan, App Service-miljön v1 och App Service-miljön v2. Förutom med ASEv3 är App Service-planen inte tillgänglig och stöds inte.
I följande tabell sammanfattas hur standardmodellen 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 med en enda klientorganisation:
| Komponent | Mätning och fakturering |
|---|---|
| Virtuell PROCESSOR (vCPU) och minne | Standardmodellen kräver att logikappen använder arbetsflödesstandardens värdplan och en prisnivå, som avgör vilka resursnivåer och prisnivåer som gäller för beräknings- och minneskapacitet. Mer information finns i Prisnivåer i Standard-modellen. |
| 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 åtgärder för hanterade anslutningsappar gäller mätning för varje anrop, medan faktureringen följer samma standard - eller Enterprise-anslutningsprogram som förbrukningsplanen. Mer information finns i Utlösare och åtgärdsåtgärder i standardmodellen. |
| Lagringsåtgärder | Mätning gäller för alla lagringsåtgärder som körs av Azure Logic Apps. Lagringsåtgärder körs till exempel när tjänsten sparar indata och utdata från arbetsflödets körningshistorik. Faktureringen följer den valda prisnivån. Mer information finns i Lagringså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 Integration-konton. |
Prisnivåer i standardmodellen
Den prisnivå som du väljer för avläsning och fakturering för din Logic App-resurs (Standard) innehåller specifika mängder beräkning i virtuella processorresurser (vCPU) och minnesresurser. Om du väljer en App Service-miljön v3 som distributionsplats och en App Service plan, särskilt prisnivån Isolerad V2-tjänstplan, debiteras du för de instanser som används av App Service-planen och för att köra logikappens arbetsflöden. Inga andra avgifter tillkommer. Mer information finns i prisnivåerna App Service Plan – Isolerad V2-tjänstplan.
Om du väljer en arbetsflödesstandardvärdplan kan du välja mellan följande nivåer:
| Prisnivå | Virtuell PROCESSOR (vCPU) | Minne (GB) |
|---|---|---|
| WS1 | 1 | 3.5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Viktigt
Följande exempel är endast för illustration och innehåller exempeluppskattningar för att i allmänhet visa hur en prisnivå fungerar. Om du vill ha specifika priser för vCPU och minne baserat på specifika regioner där Azure Logic Apps är tillgängligt läser du standardplanen för en vald region på prissidan för Azure Logic Apps.
Anta att följande resurser har följande timpriser i en exempelregion:
| Resurs | Timtaxa (exempelregion) |
|---|---|
| Virtuell processor | $0.192 per vCPU |
| Minne | 0,0137 USD per GB |
Följande beräkning ger en uppskattad månadstakt:
<månadstaxa> = 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 PROCESSOR (vCPU) | Minne (GB) | Månadstaxa (exempelregion) |
|---|---|---|---|
| WS1 | 1 | 3.5 | $175.16 |
| WS2 | 2 | 7 | $350.33 |
| WS3 | 4 | 14 | $700.65 |
Utlösar- och åtgärdsåtgärder i standardmodellen
Förutom 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 till och med instansieras. En åtgärd utfö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 aktiverar segmentering eller 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. 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 samtalet mäts och faktureras, oavsett om utlösaren utlöses eller hoppas över. 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 hämtar 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 Azure Logic Apps med en enda klientorganisation:
| Åtgärdstyp | Beskrivning | Mätning och fakturering |
|---|---|---|
| Inbyggd | Dessa åtgärder körs direkt och internt med Azure Logic Apps-körningen. I designern hittar du dessa åtgärder i anslutningsgalleriet under Runtime>In-App. HTTP-utlösaren och utlösaren Förfrågning ä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 standardmodellen fortfarande och fakturerar hanterade anslutningsåtgärder med samma standard - eller Enterprise-anslutningsprogram som förbrukningsmodellen. |
| Hanterad anslutningsapp | Dessa åtgärder körs separat i delade globala Azure. I designern hittar du dessa åtgärder i anslutningsgalleriet under Körning>delad. | Standardmodellen mäter och fakturerar åtgärder för hanterade anslutningsappar baserat på samma standard- och enterprise-anslutningsprogram som förbrukningsmodellen. Obs! Åtgärder för förhandsversion av Enterprise-anslutningsappar följer prissättningen för förbrukningsstandardanslutningsappen. |
| Anpassad anslutningsapp | För närvarande kan du skapa och endast använda anpassade inbyggda anslutningsåtgärder i arbetsflöden för en klientbaserad logikapp. | Standardmodellen innehåller obegränsade kostnadsfria inbyggda åtgärder. Begränsningar för dataflöde och tidsgränser finns i Anpassade anslutningsgränser i Azure Logic Apps. |
Mer information om hur standardmodellen fungerar med åtgärder som körs i andra åtgärder, till exempel loopar, bearbeta flera objekt, till exempel matriser och återförsöksprinciper, finns i Andra åtgärdsbeteenden.
Integration Service Environment (ISE)
När du skapar en logikapp med resurstypen Logikapp (förbrukning) och distribuerar till en dedikerad integrationstjänstmiljö (ISE) följer logikappen och dess arbetsflöde integrationstjänstmiljö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 eftersom 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 debiteras per timme för Premium-SKU:n. Om du behöver mer dataflöde kan du lägga till fler skalningsenheter när du skapar din ISE eller efteråt. Varje skalningsenhet debiteras med en timtaxa som är ungefär hälften av basenhetshastigheten. Information om kapacitet och begränsningar finns i ISE-gränser i Azure Logic Apps. |
| Utvecklare | Basenheten har fast kapacitet och debiteras per timme för utvecklar-SKU:n. Den här SKU:n har dock inget serviceavtal (SLA), uppskalningskapacitet eller redundans under återvinningen, vilket innebär att du kan uppleva förseningar eller driftstopp. Serverdelsuppdateringar 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 anslutningsgränser i Azure Logic Apps. Mer information finns i Utlösare och åtgärdsåtgärder i ISE-modellen. |
| Lagringsåtgärder | ISE-modellen innehåller kostnadsfri lagringsförbrukning, till exempel datakvarhållning. Mer information finns i Lagringsåtgärder. |
| Integrationskonton | ISE-modellen innehåller en enda kostnadsfri integreringskontonivå, baserat på din valda ISE SKU. För en extra kostnad kan du skapa fler integrationskonton som din ISE kan använda upp till den totala ISE-gränsen. Mer information finns i Integration-konton. |
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 | Beskrivning | Mätning och fakturering |
|---|---|---|
| Inbyggd | Dessa åtgärder körs direkt och internt med Azure Logic Apps-körningen och i samma ISE som logikappens arbetsflöde. I designern hittar du dessa åtgärder under den inbyggda etiketten, men varje åtgärd visar även CORE-etiketten. HTTP-utlösaren och utlösaren Förfrågning ä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 kostnadsfritt, men omfattas av ISE-gränserna i Azure Logic Apps. |
| Hanterad anslutningsapp | Oavsett om det gäller Standard eller Enterprise körs hanterade anslutningsåtgärder i antingen DIN ISE eller Azure med flera klientorganisationer, baserat på om anslutningsappen eller åtgärden visar ISE-etiketten . - ISE-etikett : Dessa åtgärder körs i samma ISE som din logikapp och fungerar utan att kräva den lokala datagatewayen. – Ingen ISE-etikett : Dessa åtgärder körs i Azure med flera klientorganisationer. |
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 | I designern hittar du dessa åtgärder under etiketten Anpassad . | ISE-modellen innehåller dessa åtgärder kostnadsfritt, 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, bearbeta flera objekt, till exempel matriser och återförsöksprinciper, finns i Andra åtgärdsbeteenden.
Annat åtgärdsbeteende
I följande tabell sammanfattas hur modellerna Consumption, Standard och ISE hanterar åtgärder som körs i andra åtgärder, till exempel loopar, bearbeta flera objekt, till exempel matriser och återförsöksprinciper:
| Åtgärd | Beskrivning | Förbrukning | Standard | ISE |
|---|---|---|---|---|
| Loopåtgärder | En loopåtgärd, till exempel loopen För varje eller Till , 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. Beräkningen för en lista med 10 objekt är alltså (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 inbyggda åtgärderna, samma som förbrukningsmodellen. | Inte mätad eller fakturerad. |
| Återförsöksprinciper | Vid åtgärder som stöds kan du implementera grundläggande undantags- och felhantering genom att konfigurera en återförsöksprincip. | Förutom det ursprungliga antalet inbyggda åtgärder mäts den ursprungliga körningen plus varje återförsökskörning. En åtgärd som till exempel körs med 5 återförsök mäts och faktureras som 6 körningar. Prissättningen baseras på om åtgärdstyperna är inbyggda, Standard eller Enterprise. |
Förutom de inbyggda åtgärderna, samma som förbrukningsmodellen. | Inte mätad eller fakturerad. |
Lagringsåtgärder
Azure Logic Apps använder Azure Storage för alla nödvändiga lagringstransaktioner, till exempel att använda köer för att schemalägga utlösaråtgärder eller använda tabeller och blobar för att lagra arbetsflödestillstå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 modellerna Consumption, Standard och ISE hanterar mätning och fakturering för lagringsåtgärder:
| Modell | Beskrivning | Mätning och fakturering |
|---|---|---|
| Förbrukning (flera klientorganisationer) | Lagringsresurser och -användning är kopplade till logikappresursen. | Mätning och fakturering gäller endast för datakvarhållningsrelaterad lagringsförbrukning och följer datakvarhållningspriset för förbrukningsplanen. |
| Standard (enskild klientorganisation) | 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 prismodellen för Azure Storage. Lagringskostnaderna visas separat på din Azure-faktureringsfaktura. Tips: Om du vill hjälpa dig att bättre förstå 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 Beräkna lagringsbehov och kostnader för arbetsflöden i Azure Logic Apps med en enda klientorganisation. |
| Integration Service Environment (ISE) | Lagringsresurser och -användning är kopplade till logikappresursen. | Inte mätad eller fakturerad. |
Mer information finns i följande dokumentation:
Lokal datagateway
Den lokala datagatewayen är en separat Azure-resurs som du skapar så att logikappens arbetsflöden kan komma åt lokala data med hjälp av specifika anslutningsappar som stöds av gatewayen. Själva gatewayresursen debiteras inte, men åtgärder som körs via gatewayen debiteras baserat på den pris- 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 artefakter från företag till företag (B2B), 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 modellerna Consumption, Standard och ISE hanterar mätning och fakturering för integrationskonton:
| Modell | Mätning och fakturering |
|---|---|
| Förbrukning (flera klientorganisationer) | Mätning och fakturering använder prissättningen för integrationskontot baserat på den kontonivå som du använder. |
| Standard (enskild klientorganisation) | Mätning och fakturering använder prissättningen för integrationskontot 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 kostnad kan du skapa fler integrationskonton som din ISE kan använda upp till den totala ISE-gränsen. |
Mer information finns i följande dokumentation:
Andra objekt som inte är bevakade eller fakturerade
I alla prismodeller mäts eller faktureras inte följande objekt:
- Åtgärder som inte kördes eftersom arbetsflödet stoppades innan det slutfördes
- Inaktiverade logikappar eller arbetsflöden eftersom de inte kan skapa nya instanser när de är inaktiva.