Sdílet prostřednictvím

Měření využití, fakturace a ceny pro Azure Logic Apps

  • Článek

Platí pro: Azure Logic Apps (Consumption + Standard)

Azure Logic Apps pomáhá vytvářet a spouštět automatizované integrační pracovní postupy, které se můžou škálovat v cloudu. Tento článek popisuje, jak fungují modely měření, fakturace a cen pro Azure Logic Apps a související prostředky. Informace, jako jsou konkrétní cenové sazby, plánování nákladů nebo různá hostitelské prostředí, najdete v následujícím obsahu:

Spotřeba (více tenantů)

V Azure Logic Apps s více tenanty se aplikace logiky a její pracovní postup řídí plánem Consumption pro ceny a fakturaci. Takové aplikace logiky vytvoříte různými způsoby, například když zvolíte typ prostředku Aplikace logiky (Consumption ), použijete rozšíření Azure Logic Apps (Consumption) v editoru Visual Studio Code nebo při vytváření úloh automatizace.

Následující tabulka shrnuje, jak model Consumption zpracovává měření a fakturaci následujících komponent při použití s aplikací logiky a pracovním postupem v Azure Logic Apps s více tenanty:

Komponenta Měření a fakturace
Operace triggeru a akce Model Consumption zahrnuje počáteční počet bezplatných integrovaných operací pro každé předplatné Azure, které může pracovní postup spustit. Nad tímto číslem se měření vztahuje na každé spuštění a fakturace se řídí cenami akcí pro plán Consumption. U jiných typů operací, jako jsou spravované konektory, se fakturace řídí cenami standardního nebo podnikového konektoru pro plán Consumption. Další informace najdete v tématu Operace triggeru a akce v modelu Consumption.
Operace úložiště Měření se vztahuje pouze na spotřebu úložiště související s uchováváním dat, jako je ukládání vstupů a výstupů z historie spuštění pracovního postupu. Fakturace se řídí cenami uchovávání dat pro plán Consumption. Další informace najdete v tématu Operace úložiště.
Účty pro integraci Měření se vztahuje na základě typu účtu integrace, který vytvoříte a použijete s aplikací logiky. Fakturace se řídí cenami účtu integrace, pokud není vaše aplikace logiky nasazená a hostovaná v prostředí integrační služby (ISE). Další informace najdete v účtech integrace.

Operace aktivace a akce v modelu Consumption

S výjimkou počátečního počtu bezplatných předdefinovaných spuštění operací v rámci předplatného Azure, které může pracovní postup spustit, měřiče modelu Consumption a fakturuje operaci na základě každého spuštění, ať už se celkový pracovní postup úspěšně spustí, dokončí nebo dokonce vytvoří instanci. Operace obvykle provádí jedno spuštění , pokud operace nemá povolené pokusy o opakování. Provádění obvykle provádí jedno volání, pokud operace nepodporuje a neumožňuje vytváření bloků dat nebo stránkování. Pokud je povolené vytváření bloků dat nebo stránkování, může být spuštění operace nutné provést více volání.

Model Consumption měřiče a fakturuje operaci na spuštění, nikoli na volání. Předpokládejme například, že pracovní postup začíná triggerem dotazování, který získává záznamy pravidelným odchozím voláním do koncového bodu. Odchozí volání se měří a účtuje se jako jedno spuštění, ať už se trigger aktivuje nebo přeskočí, například když trigger zkontroluje koncový bod, ale nenajde žádná data nebo události. Stav triggeru určuje, zda je instance pracovního postupu vytvořena a spuštěna. Předpokládejme, že operace také podporuje a má povolené vytváření bloků dat nebo stránkování. Pokud operace musí provést 10 volání, aby se dokončilo získání všech dat, je operace stále měřena a fakturována jako jedno spuštění, i když provádí více volání.

Poznámka:

Ve výchozím nastavení triggery, které vracejí pole, mají již povolené nastavení Rozdělit na . Výsledkem tohoto nastavení je událost triggeru, kterou můžete zkontrolovat v historii triggerů a instanci pracovního postupu pro každou položku pole. Všechny instance pracovního postupu běží paralelně, aby se položky pole zpracovávaly současně. Fakturace se vztahuje na všechny události triggeru bez ohledu na to, jestli je stav triggeru úspěšný nebo vynechán. Triggery jsou stále fakturovatelné i ve scénářích, kdy triggery nespustí a spustí pracovní postup, ale stav triggeru je úspěšný, neúspěšný nebo vynechán.

Následující tabulka shrnuje, jak model Consumption zpracovává měření a fakturaci těchto typů operací při použití s aplikací logiky a pracovním postupem v Azure Logic Apps s více tenanty:

Typ operace Popis Měření a fakturace
Integrované Tyto operace běží přímo a nativně s modulem runtime Azure Logic Apps. V návrháři najdete tyto operace pod předdefinovaný popisek.

Například trigger HTTP a trigger požadavku jsou integrované triggery. Akce HTTP a akce Odpovědi jsou integrované akce. Mezi další integrované operace patří akce řízení pracovního postupu, jako jsou smyčky a podmínky, operace s daty, dávkové operace a další.

 Model Consumption zahrnuje počáteční počet bezplatných integrovaných operací pro každé předplatné Azure, které může pracovní postup spustit. Nad tímto číslem se předdefinované spuštění operací řídí cenami akcí.

Poznámka: Některé operace spravovaného konektoru jsou k dispozici také jako integrované operace, které jsou součástí počátečních bezplatných operací. Nad počátečními bezplatnými operacemi se fakturace řídí cenami akcí, nikoli cen konektoru Standard nebo Enterprise.
Spravovaný konektor Tyto operace běží samostatně v Azure. V návrháři najdete tyto operace pod popiskem Standard nebo Enterprise . Provádění těchto operací se řídí cenami konektoru Standard nebo Enterprise.

Poznámka: Spouštění operací konektoru Enterprise ve verzi Preview se řídí cenami konektoru Consumption Standard.
Vlastní konektor Tyto operace běží samostatně v Azure. V návrháři najdete tyto operace pod popiskem Vlastní . V případě omezení počtu konektorů, propustnosti a časového limitu zkontrolujte limity vlastních konektorů v Azure Logic Apps. Provádění těchto operací se řídí cenami standardního konektoru.

Další informace o tom, jak model Consumption funguje s operacemi, které běží uvnitř jiných operací, jako jsou smyčky, zpracování více položek, jako jsou pole, a zásady opakování, zkontrolujte chování jiné operace.

Tipy pro odhad nákladů pro model Consumption

Pokud chcete pomoct s odhadem přesnějších nákladů na spotřebu, projděte si tyto tipy:

  • Zvažte možný počet zpráv nebo událostí, které by mohly přijít v libovolný den, a ne založit výpočty pouze na intervalu dotazování.

  • Když událost nebo zpráva splňují kritéria triggeru, mnoho triggerů se okamžitě pokusí přečíst všechny další čekající události nebo zprávy, které splňují kritéria. Toto chování znamená, že i když vyberete delší interval dotazování, trigger se aktivuje na základě počtu čekajících událostí nebo zpráv, které jsou způsobilé pro spouštění pracovních postupů. Mezi triggery, které se řídí tímto chováním, patří Azure Service Bus a Azure Event Hubs.

    Předpokládejme například, že jste nastavili trigger, který každý den kontroluje koncový bod. Když trigger zkontroluje koncový bod a najde 15 událostí, které splňují kritéria, trigger se aktivuje a spustí odpovídající pracovní postup 15krát. Služba Logic Apps monitoruje všechny akce, které tyto 15 pracovních postupů provádějí, včetně požadavků triggeru.

Standard (s jedním tenantem)

V Azure Logic Apps s jedním tenantem se aplikace logiky a její pracovní postupy řídí standardním plánempro ceny a fakturaci. Tyto aplikace logiky vytvoříte různými způsoby, například když zvolíte typ prostředku Aplikace logiky (Standard) nebo použijete rozšíření Azure Logic Apps (Standard) v editoru Visual Studio Code. Tento cenový model vyžaduje, aby aplikace logiky používaly plán hostování a cenovou úroveň, která se liší od plánu Consumption v tom, že se vám účtuje rezervovaná kapacita a vyhrazené prostředky bez ohledu na to, jestli je používáte.

Když vytváříte nebo nasazujete aplikace logiky s typem prostředku Aplikace logiky (Standard) a pro nasazení vyberete libovolnou oblast Azure, vyberete také plán hostování standardu pracovního postupu. Pokud ale pro umístění nasazení vyberete existující prostředek služby App Service Environment v3 , musíte vybrat plán služby App Service.

Důležité

Následující plány a prostředky už nejsou dostupné ani podporované ve veřejné verzi typu prostředku aplikace logiky (Standard) v oblastech Azure: Plán Služby Premium, App Service Environment v1 a App Service Environment v2. S výjimkou ASEv3 není plán služby App Service dostupný a nepodporuje se.

Následující tabulka shrnuje, jak model Standard zpracovává měření a fakturaci pro následující komponenty při použití s aplikací logiky a pracovním postupem v Azure Logic Apps s jedním tenantem:

Komponenta Měření a fakturace
Virtuální procesor (vCPU) a paměť Model Standard vyžaduje , aby vaše aplikace logiky používala plán hostování Workflow Standard a cenovou úroveň, která určuje úrovně prostředků a cenové sazby, které se vztahují na výpočetní kapacitu a kapacitu paměti. Další informace najdete v části Cenové úrovně v modelu Standard.
Operace triggeru a akce Model Standard zahrnuje neomezený počet bezplatných předdefinovaných operací, které váš pracovní postup může spustit.

Pokud váš pracovní postup používá nějaké operace spravovaného konektoru, měření platí pro každé volání, zatímco fakturace se řídí stejnými cenami konektoru Standard nebo Enterprise jako plán Consumption. Další informace najdete v tématu Operace triggeru a akce v modelu Standard.
Operace úložiště Měření platí pro všechny operace úložiště spuštěné službou Azure Logic Apps. Například operace úložiště se spustí, když služba ukládá vstupy a výstupy z historie spuštění pracovního postupu. Fakturace se řídí zvolenou cenovou úrovní. Další informace najdete v tématu Operace úložiště.
Účty pro integraci Pokud pro aplikaci logiky vytvoříte účet integrace, který se má použít, měření vychází z typu účtu integrace, který vytvoříte. Fakturace se řídí cenami účtu integrace. Další informace najdete v účtech integrace.

Cenové úrovně v modelu Standard

Cenová úroveň, kterou zvolíte pro měření a fakturaci prostředku aplikace logiky (Standard), zahrnuje konkrétní množství výpočetních prostředků ve virtuálním procesoru (vCPU) a prostředcích paměti. Pokud jako umístění nasazení vyberete službu App Service Environment v3 a plán služby App Service, konkrétně cenovou úroveň plánu izolované služby V2, budou se vám účtovat instance používané plánem služby App Service a pro spouštění pracovních postupů aplikace logiky. Žádné další poplatky se neúčtují. Další informace naleznete v tématu Plán služby App Service – Izolované cenové úrovně plánu služby V2.

Pokud vyberete plán hostování Workflow Standard , můžete si vybrat z následujících úrovní:

Cenová úroveň Virtuální procesor (vCPU) Paměť (GB)
WS1 0 3.5
WS2 2 7
WS3 4 14

Důležité

Následující příklad je určen pouze pro ilustraci a poskytuje ukázkové odhady, které obecně ukazují, jak cenová úroveň funguje. Konkrétní ceny virtuálních procesorů a paměti na základě konkrétních oblastí, ve kterých je služba Azure Logic Apps dostupná, si projděte plán Standard pro vybranou oblast na stránce s cenami Azure Logic Apps.

Předpokládejme, že v ukázkové oblasti mají následující prostředky tyto hodinové sazby:

Prostředek Hodinová sazba (ukázková oblast)
Virtuální procesory 0,192 USD za vCPU
Paměť 0,0137 USD za GB

Následující výpočet poskytuje odhadovanou měsíční sazbu:

<měsíční sazba = 730 hodin (za měsíc) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> * <hourly-rate-GB-memory>)]>

Na základě předchozích informací uvádí následující tabulka odhadované měsíční sazby pro každou cenovou úroveň a prostředky v této cenové úrovni:

Cenová úroveň Virtuální procesor (vCPU) Paměť (GB) Měsíční sazba (příklad oblasti)
WS1 0 3.5 175,16 Kč
WS2 2 7 350,33 Kč
WS3 4 14 700,65 Kč

Operace aktivace a akce ve standardním modelu

S výjimkou neomezených bezplatných integrovaných operací, které může pracovní postup spustit, měřiče standardního modelu a fakturuje operaci na základě každého volání, ať už se celý pracovní postup úspěšně spustí, dokončí nebo dokonce vytvoří instance. Operace obvykle provádí jedno spuštění , pokud operace nemá povolené pokusy o opakování. Provádění obvykle provádí jedno volání, pokud operace nepodporuje a neumožňuje vytváření bloků dat nebo stránkování. Pokud je povolené vytváření bloků dat nebo stránkování, může být spuštění operace nutné provést více volání. Standardní model měřiče a fakturuje operaci na volání, nikoli na spuštění.

Předpokládejme například, že pracovní postup začíná triggerem dotazování, který získává záznamy pravidelným odchozím voláním do koncového bodu. Odchozí volání se měří a fakturuje, ať už se trigger aktivuje nebo přeskočí. Stav triggeru určuje, zda je instance pracovního postupu vytvořena a spuštěna. Předpokládejme, že operace také podporuje a má povolené vytváření bloků dat nebo stránkování. Pokud operace musí provést 10 volání, aby se dokončilo získávání všech dat, je operace měřena a fakturována za volání.

Následující tabulka shrnuje, jak model Standard zpracovává měření a fakturaci pro typy operací při použití s aplikací logiky a pracovním postupem v Azure Logic Apps s jedním tenantem:

Typ operace Popis Měření a fakturace
Integrované Tyto operace běží přímo a nativně s modulem runtime Azure Logic Apps. V návrháři najdete tyto operace v galerii konektorů v části Runtime>In-App.

Například trigger HTTP a trigger požadavku jsou integrované triggery. Akce HTTP a akce Odpovědi jsou integrované akce. Mezi další integrované operace patří akce řízení pracovního postupu, jako jsou smyčky a podmínky, operace s daty, dávkové operace a další.

 Model Standard zahrnuje neomezené bezplatné integrované operace.

Poznámka: Některé operace spravovaného konektoru jsou také k dispozici jako integrované operace. I když jsou integrované operace bezplatné, model Standard stále měří a účtuje operace spravovaných konektorů pomocí stejných cen konektorů Standard nebo Enterprise jako model Consumption.
Spravovaný konektor Tyto operace běží samostatně ve sdíleném globálním Azure. V návrháři najdete tyto operace v galerii konektorů v části Sdílené modul runtime>. Měřiče modelů Standard a fakturuje operace spravovaných konektorů na základě stejných cen konektorů Standard a Enterprise jako model Consumption.

Poznámka: Operace konektoru Preview Enterprise se řídí cenami konektoru Consumption Standard.
Vlastní konektor V současné době můžete vytvářet a používat pouze vlastní integrované operace konektoru v pracovních postupech aplikací logiky založené na jednom tenantovi. Model Standard zahrnuje neomezené bezplatné integrované operace. Pokud chcete omezení propustnosti a časového limitu, projděte si limity vlastních konektorů v Azure Logic Apps.

Další informace o tom, jak model Standard funguje s operacemi, které běží uvnitř jiných operací, jako jsou smyčky, zpracování více položek, jako jsou pole, a zásady opakování, zkontrolujte chování jiné operace.

Prostředí integrační služby (ISE)

Když vytvoříte aplikaci logiky pomocí typu prostředku Aplikace logiky (Consumption) a nasadíte ji do vyhrazeného prostředí integrační služby (ISE), aplikace logiky a její pracovní postup se řídí plánem prostředí integrační služby pro ceny a fakturaci. Tento cenový model závisí na vaší úrovni ISE nebo skladové poplatcích a liší se od plánu Consumption v tom, že se vám účtuje rezervovaná kapacita a vyhrazené prostředky bez ohledu na to, jestli je používáte.

Následující tabulka shrnuje, jak model ISE zpracovává měření a fakturaci kapacity a dalších vyhrazených prostředků na základě úrovně ise nebo skladové položky:

ISE SKU Měření a fakturace
Premium Základní jednotka má pevnou kapacitu a účtuje se hodinovou sazbou za skladovou položku Premium. Pokud potřebujete větší propustnost, můžete při vytváření ise nebo později přidat další jednotky škálování. Každá jednotka škálování se účtuje hodinovou sazbou, která je zhruba polovina základní jednotky.

Informace o kapacitě a omezeních najdete v tématu Omezení ISE v Azure Logic Apps.
Vývojář Základní jednotka má pevnou kapacitu a účtuje se hodinovou sazbou za skladovou položku pro vývojáře. Tato skladová položka ale nemá během recyklace žádnou smlouvu o úrovni služeb (SLA), schopnost vertikálního navýšení kapacity nebo redundanci, což znamená, že může docházet k prodlevám nebo výpadkům. Aktualizace back-endu můžou přerušovat službu přerušovaně.

Důležité: Ujistěte se, že tuto skladovou položku používáte jenom pro zkoumání, experimenty, vývoj a testování – ne pro produkční nebo výkonnostní testování.

Informace o kapacitě a omezeních najdete v tématu Omezení ISE v Azure Logic Apps.

Následující tabulka shrnuje, jak model ISE zpracovává následující komponenty při použití s aplikací logiky a pracovním postupem v prostředí ISE:

Komponenta Popis
Operace triggeru a akce Model ISE zahrnuje bezplatné integrované, spravované konektory a vlastní operace konektoru, které váš pracovní postup může spouštět, ale podléhá omezením isE v Azure Logic Apps a omezením vlastních konektorů v Azure Logic Apps. Další informace najdete v modelu ISE v operacích triggeru a akcí.
Operace úložiště Model ISE zahrnuje bezplatnou spotřebu úložiště, jako je uchovávání dat. Další informace najdete v tématu Operace úložiště.
Účty pro integraci Model ISE obsahuje jednu úroveň bezplatného účtu integrace na základě vybrané skladové položky ISE. Za příplatek můžete pro isE vytvořit další účty integrace, které budou používat až do celkového limitu ise. Další informace najdete v účtech integrace.

Operace aktivace a akcí v modelu ISE

Následující tabulka shrnuje, jak model ISE zpracovává následující typy operací při použití s aplikací logiky a pracovním postupem v prostředí ISE:

Typ operace Popis Měření a fakturace
Integrované Tyto operace běží přímo a nativně s modulem runtime Azure Logic Apps a ve stejném prostředí ISE jako pracovní postup vaší aplikace logiky. V návrháři můžete tyto operace najít pod předdefinovaným popiskem, ale každá operace také zobrazuje popisek CORE .

Například trigger HTTP a trigger požadavku jsou integrované triggery. Akce HTTP a akce Odpovědi jsou integrované akce. Mezi další integrované operace patří akce řízení pracovního postupu, jako jsou smyčky a podmínky, operace s daty, dávkové operace a další.

 Model ISE zahrnuje tyto operace zdarma, ale podléhá omezením ISE v Azure Logic Apps.
Spravovaný konektor Bez ohledu na to, jestli operace spravovaného konektoru běží ve službě ISE nebo v Azure s více tenanty na základě toho, jestli konektor nebo operace zobrazují popisek ISE.

- Popisek ISE : Tyto operace běží ve stejném prostředí ISE jako vaše aplikace logiky a fungují bez nutnosti místní brány dat.

– Žádný popisek ISE : Tyto operace běží v Azure s více tenanty.

 Model ISE zahrnuje operace ISE i bez označení ISE zdarma, ale podléhají omezením ISE v Azure Logic Apps.
Vlastní konektor V návrháři najdete tyto operace pod popiskem Vlastní . Model ISE zahrnuje tyto operace zdarma, ale podléhají omezením vlastních konektorů v Azure Logic Apps.

Další informace o tom, jak model ISE funguje s operacemi, které běží uvnitř jiných operací, jako jsou smyčky, zpracování více položek, jako jsou pole, a zásady opakování, zkontrolujte chování jiné operace.

Jiné chování operace

Následující tabulka shrnuje, jak modely Consumption, Standard a ISE zpracovávají operace, které se spouští uvnitř jiných operací, jako jsou smyčky, zpracovávají více položek, jako jsou pole, a zásady opakování:

Operation Popis Využití Standard ISE
Akce smyčky Akce smyčky, jako je například smyčka For each nebo Until , může zahrnovat další akce, které se spouští během každého cyklu smyčky. S výjimkou počátečního počtu integrovaných operací se akce smyčky a každá akce ve smyčce měří při každém spuštění cyklu smyčky. Pokud akce zpracuje všechny položky v kolekci, například seznam nebo pole, počet položek se použije také při výpočtu měření.

Předpokládejme například, že máte pro každou smyčku smyčku s akcemi, které zpracovávají seznam. Služba vynásobí počet položek seznamu s počtem akcí ve smyčce a přidá akci, která smyčku spustí. Výpočet seznamu 10 položek je tedy (10 × 1) + 1, což vede k provedení 11 akcí.

Ceny jsou založené na tom, jestli jsou typy operací integrované, standardní nebo podnikové.

 S výjimkou zahrnutých integrovaných operací, stejně jako model Consumption. Neměřené ani fakturované.
Zásady opakování Při podporovaných operacích můžete implementovat základní zpracování výjimek a chyb nastavením zásady opakování. S výjimkou počátečního počtu předdefinovaných operací se měří původní spuštění plus každé opakované spuštění. Například akce, která se provede s 5 opakováními, se měří a účtuje se jako 6 spuštění.

Ceny jsou založené na tom, jestli jsou typy operací integrované, standardní nebo podnikové.

 S výjimkou integrovaných zahrnutých operací, stejně jako model Consumption. Neměřené ani fakturované.

Operace úložiště

Azure Logic Apps používá Azure Storage pro všechny požadované transakce úložiště, jako je například použití front pro plánování operací aktivačních událostí nebo použití tabulek a objektů blob pro ukládání stavů pracovního postupu. V závislosti na operacích v pracovním postupu se náklady na úložiště liší, protože různé triggery, akce a datové části vedou k různým operacím a potřebám úložiště. Služba také ukládá a ukládá vstupy a výstupy z historie spuštění pracovního postupu na základě limitu uchovávání historie spuštění prostředku aplikace logiky. Tento limit uchovávání můžete spravovat na úrovni prostředků aplikace logiky, nikoli na úrovni pracovního postupu.

Následující tabulka shrnuje, jak modely Consumption, Standard a ISE zpracovávají měření a fakturaci operací úložiště:

Model Popis Měření a fakturace
Spotřeba (více tenantů) Prostředky úložiště a využití jsou připojené k prostředku aplikace logiky. Měření a fakturace se vztahují pouze na spotřebu úložiště související s uchováváním dat a postupujte podle cen uchovávání dat pro plán Consumption.
Standard (s jedním tenantem) Můžete použít vlastní účet úložiště Azure, který vám dává větší kontrolu a flexibilitu nad daty pracovního postupu. Měření a fakturace se řídí cenovým modelem služby Azure Storage. Náklady na úložiště se zobrazují samostatně na faktuře za fakturaci Azure.

Tip: Pokud chcete lépe porozumět počtu operací úložiště, které může pracovní postup spustit a jejich náklady, zkuste použít kalkulačku služby Logic Apps Storage. Vyberte ukázkový pracovní postup nebo použijte existující definici pracovního postupu. První výpočet odhaduje počet operací úložiště v pracovním postupu. Tato čísla pak můžete použít k odhadu možných nákladů pomocí cenové kalkulačky Azure. Další informace najdete v tématu Odhad potřeb úložiště a nákladů na pracovní postupy v Azure Logic Apps s jedním tenantem.
Prostředí integrační služby (ISE) Prostředky úložiště a využití jsou připojené k prostředku aplikace logiky. Neměřené ani fakturované.

Další informace najdete v následující dokumentaci:

Místní brána dat

Místní brána dat je samostatný prostředek Azure, který vytvoříte, aby pracovní postupy aplikací logiky mohly přistupovat k místním datům pomocí konkrétních konektorů podporovaných bránou. Samotný prostředek brány neúčtuje poplatky, ale operace, které procházejí bránou, se účtují poplatky na základě cen a fakturačního modelu používaného vaší aplikací logiky.

Účty pro integraci

Účet integrace je samostatný prostředek Azure, který vytvoříte jako kontejner pro definování a ukládání artefaktů B2B (Business-to-Business), jako jsou obchodní partneři, smlouvy, schémata, mapy atd. Po vytvoření tohoto účtu a definování těchto artefaktů propojte tento účet s aplikací logiky, abyste mohli tyto artefakty a různé operace B2B v pracovních postupech použít k prozkoumání, sestavování a testování řešení integrace, která používají možnosti zpracování EDI a XML.

Následující tabulka shrnuje, jak modely Consumption, Standard a ISE zpracovávají monitorování a fakturaci účtů integrace:

Model Měření a fakturace
Spotřeba (více tenantů) Měření a fakturace využívají ceny účtu integrace na základě úrovně účtu, kterou používáte.
Standard (s jedním tenantem) Měření a fakturace využívají ceny účtu integrace na základě úrovně účtu, kterou používáte.
ISE Tento model zahrnuje jeden účet integrace na základě skladové položky ISE. Za příplatek můžete pro isE vytvořit další účty integrace, které budou používat až do celkového limitu ise.

Další informace najdete v následující dokumentaci:

Jiné položky, které nejsou měřené nebo fakturované

U všech cenových modelů se následující položky neměří ani neúčtují:

  • Akce, které se nespustí, protože pracovní postup se zastavil před dokončením
  • Zakázané aplikace logiky nebo pracovní postupy, protože nemůžou vytvářet nové instance, když jsou neaktivní.

Další kroky