Misurazione dell'utilizzo, fatturazione e prezzi per App per la logica di Azure
Si applica a: App per la logica di Azure (consumo + Standard)
App per la logica di Azure consente di creare ed eseguire flussi di lavoro di integrazione automatizzati che possono essere ridimensionati nel cloud. Questo articolo descrive come funzionano i modelli di misurazione, fatturazione e prezzi per App per la logica di Azure e le risorse correlate. Per informazioni quali tariffe tariffarie specifiche, pianificazione dei costi o ambienti di hosting diversi, esaminare il contenuto seguente:
- Tariffe tariffarie per app per la logica di Azure
- Pianificare e gestire i costi per app per la logica di Azure
- Ambiente del servizio di integrazione e confronto tra tenant singolo e multi-tenant
Consumo (multi-tenant)
In App per la logica multi-tenant, un'app per la logica e il relativo flusso di lavoro seguono il piano di consumo per i prezzi e la fatturazione. Si creano app per la logica in diversi modi, ad esempio quando si sceglie il tipo di risorsa App per la logica (consumo), usare l'estensione App per la logica di Azure (consumo) in Visual Studio Code o quando si creano attività di automazione.
La tabella seguente riepiloga il modo in cui il modello di consumo gestisce la misurazione e la fatturazione per i componenti seguenti quando viene usata con un'app per la logica e un flusso di lavoro in App per la logica di Azure multi-tenant:
| Componente | Misurazione e fatturazione. |
|---|---|
| Operazioni di trigger e azione | Il modello Consumo include un numero iniziale di operazioni predefinite gratuite, per sottoscrizione di Azure, che un flusso di lavoro può essere eseguito. Al di sopra di questo numero, il contatore si applica a ogni esecuzione e la fatturazione segue i prezzi delle azioni per il piano di consumo. Per altri tipi di operazione, ad esempio connettori gestiti, la fatturazione segue i prezzi del connettore Standard o Enterprise per il piano di consumo. Per altre informazioni, vedere Operazioni di attivazione e azione nel modello Di consumo. |
| Operazioni di archiviazione | La misurazione si applica solo al consumo di archiviazione correlato alla conservazione dei dati , ad esempio il salvataggio di input e output dalla cronologia di esecuzione del flusso di lavoro. La fatturazione segue i prezzi di conservazione dei dati per il piano di consumo. Per altre informazioni, vedere Operazioni di archiviazione. |
| Account di integrazione | La misurazione si applica in base al tipo di account di integrazione creato e usato con l'app per la logica. La fatturazione segue i prezzi dell'account di integrazione a meno che l'app per la logica non venga distribuita e ospitata in un ambiente del servizio di integrazione (ISE). Per altre informazioni, vedere Account di integrazione. |
Operazioni di attivazione e azione nel modello Di consumo
Ad eccezione del numero iniziale di esecuzioni di operazioni predefinite gratuite, per sottoscrizione di Azure, che un flusso di lavoro può essere eseguito, i contatori del modello di consumo e fattura un'operazione in base a ogni esecuzione, indipendentemente dal fatto che il flusso di lavoro complessivo venga eseguito correttamente, venga completata o sia anche creata un'istanza. Un'operazione in genere esegue un'unica esecuzione a meno che l'operazione non disponga di tentativi abilitati. A sua volta, un'esecuzione esegue in genere una singola chiamata a meno che l'operazione supporti e non consenta la suddivisione in blocchi o la paginazione per ottenere grandi quantità di dati. Se è abilitata la suddivisione in blocchi o la paginazione, un'esecuzione dell'operazione potrebbe dover effettuare più chiamate.
Il contatore del modello consumo e fattura un'operazione per ogni esecuzione, non per chiamata. Si supponga, ad esempio, che un flusso di lavoro inizi con un trigger di polling che ottiene i record eseguendo regolarmente chiamate in uscita a un endpoint. La chiamata in uscita viene misurata e fatturata come singola esecuzione, indipendentemente dal fatto che il trigger venga generato o ignorato, ad esempio quando un trigger controlla un endpoint ma non trova dati o eventi. Lo stato del trigger controlla se l'istanza del flusso di lavoro viene creata ed eseguita. Si supponga ora che l'operazione supporti anche e abbia abilitato la suddivisione in blocchi o la paginazione. Se l'operazione deve effettuare 10 chiamate per completare l'acquisizione di tutti i dati, l'operazione viene ancora misurata e fatturata come singola esecuzione, nonostante l'esecuzione di più chiamate.
Nota
Per impostazione predefinita, i trigger che restituiscono una matrice hanno un'impostazione Split On già abilitata. Questa impostazione genera un evento trigger, che è possibile esaminare nella cronologia dei trigger e un'istanza del flusso di lavoro per ogni elemento di matrice. Tutte le istanze del flusso di lavoro vengono eseguite in parallelo in modo che gli elementi della matrice vengano elaborati contemporaneamente. La fatturazione si applica a tutti gli eventi di trigger se lo stato del trigger è Riuscito o Ignorato. I trigger sono ancora fatturabili anche negli scenari in cui i trigger non creano un'istanza e avviano il flusso di lavoro, ma lo stato del trigger è Riuscito, Non riuscito o Ignorato.
La tabella seguente riepiloga il modo in cui il modello di consumo gestisce la misurazione e la fatturazione per questi tipi di operazione quando viene usata con un'app per la logica e un flusso di lavoro in App per la logica di Azure multi-tenant:
| Tipo di operazione | Descrizione | Misurazione e fatturazione. |
|---|---|---|
| Predefinito | Queste operazioni vengono eseguite direttamente e in modo nativo con il runtime di App per la logica di Azure. Nella finestra di progettazione è possibile trovare queste operazioni nell'etichetta predefinita . Ad esempio, il trigger HTTP e il trigger Request sono trigger predefiniti. L'azione HTTP e l'azione Response sono azioni predefinite. Altre operazioni predefinite includono azioni di controllo del flusso di lavoro, ad esempio cicli e condizioni, operazioni di dati, operazioni batch e altri. |
Il modello Consumo include un numero iniziale di operazioni predefinite gratuite, per sottoscrizione di Azure, che un flusso di lavoro può essere eseguito. Sopra questo numero, le esecuzioni predefinite dell'operazione seguono i prezzi delle azioni. Nota: alcune operazioni del connettore gestito sono disponibili anche come operazioni predefinite, incluse nelle operazioni gratuite iniziali. Sopra le operazioni inizialmente gratuite, la fatturazione segue i prezzi delle azioni, non i prezzi del connettore Standard o Enterprise. |
| Connettore gestito | Queste operazioni vengono eseguite separatamente in Azure. Nella finestra di progettazione è possibile trovare queste operazioni nell'etichetta Standard o Enterprise . | Queste esecuzioni di operazioni seguono i prezzi del connettore Standard o Enterprise. Nota: anteprima delle esecuzioni delle operazioni del connettore Enterprise seguono i prezzi del connettore Consumo Standard. |
| Connettore personalizzato | Queste operazioni vengono eseguite separatamente in Azure. Nella finestra di progettazione è possibile trovare queste operazioni sotto l'etichetta personalizzata . Per limitare il numero di connettori, velocità effettiva e timeout, esaminare i limiti del connettore personalizzato in App per la logica di Azure. | Queste esecuzioni di operazioni seguono i prezzi del connettore Standard. |
Per altre informazioni sul funzionamento del modello Di consumo con operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborano più elementi, ad esempio matrici e criteri di ripetizione dei tentativi, esaminare Altro comportamento dell'operazione.
Suggerimenti per la stima dei costi per il modello Di consumo
Per aiutare a stimare costi di consumo più accurati, vedere questi suggerimenti:
Considerare il numero possibile di messaggi o eventi che potrebbero arrivare in qualsiasi determinato giorno, anziché basare i calcoli solo sull'intervallo di polling.
Quando un evento o un messaggio soddisfa i criteri di trigger, molti trigger tentano immediatamente di leggere eventuali altri eventi o messaggi in attesa che soddisfano i criteri. Questo comportamento significa che anche quando si seleziona un intervallo di polling più lungo, il trigger viene attivato in base al numero di eventi in attesa o di messaggi che soddisfano le condizioni per l'avvio dei flussi di lavoro. I trigger che seguono questo comportamento includono bus di servizio di Azure e Hub eventi di Azure.
Si supponga, ad esempio, di configurare un trigger che controlla ogni giorno un endpoint. Quando il trigger controlla l'endpoint e trova 15 eventi che soddisfano i criteri, il trigger viene attivato ed esegue il flusso di lavoro corrispondente 15 volte. Il servizio App per la logica metri tutte le azioni eseguite da tali 15 flussi di lavoro, incluse le richieste di trigger.
Standard (singolo tenant)
In App per la logica a tenant singolo, un'app per la logica e i relativi flussi di lavoro seguono il piano Standard per i prezzi e la fatturazione. Si creano app per la logica in diversi modi, ad esempio quando si sceglie il tipo di risorsa App per la logica (Standard) o si usa l'estensione App per la logica di Azure (Standard) in Visual Studio Code. Questo modello tariffario richiede che le app per la logica usino un piano di hosting e un piano tariffario, che differisce dal piano di consumo in cui viene fatturata la capacità riservata e le risorse dedicate, indipendentemente dal fatto che vengano usate.
Quando si creano o distribuiscono app per la logica con il tipo di risorsa App per la logica (Standard) e si seleziona qualsiasi area di Azure per la distribuzione, si seleziona anche un piano di hosting Standard del flusso di lavoro. Tuttavia, se si seleziona una risorsa ambiente del servizio app v3 esistente per il percorso di distribuzione, è necessario selezionare un piano di servizio app.
Importante
I piani e le risorse seguenti non sono più disponibili o supportati con la versione pubblica del tipo di risorsa App per la logica (Standard) nelle aree di Azure: Piano Premium funzioni, ambiente del servizio app v1 e ambiente del servizio app v2. Ad eccezione di ASEv3, il piano di servizio app non è disponibile e non supportato.
La tabella seguente riepiloga il modo in cui il modello Standard gestisce la misurazione e la fatturazione per i componenti seguenti quando viene usata con un'app per la logica e un flusso di lavoro in App per la logica di Azure a tenant singolo:
| Componente | Misurazione e fatturazione. |
|---|---|
| CPU virtuale (vCPU) e memoria | Il modello Standard richiede che l'app per la logica usi il piano di hosting Workflow Standard e un piano tariffario, che determina i livelli di risorse e le tariffe tariffarie applicabili alla capacità di calcolo e memoria. Per altre informazioni, vedere Piani tariffari nel modello Standard. |
| Operazioni di trigger e azione | Il modello Standard include un numero illimitato di operazioni predefinite gratuite che il flusso di lavoro può eseguire. Se il flusso di lavoro usa qualsiasi operazione del connettore gestito, la misurazione si applica a ogni chiamata, mentre la fatturazione segue gli stessi prezzi standard o Enterprise del connettore Enterprise del piano di consumo. Per altre informazioni, vedere Operazioni di attivazione e azione nel modello Standard. |
| Operazioni di archiviazione | La misurazione si applica a tutte le operazioni di archiviazione eseguite da App per la logica di Azure. Ad esempio, le operazioni di archiviazione vengono eseguite quando il servizio salva input e output dalla cronologia di esecuzione del flusso di lavoro. La fatturazione segue il piano tariffario scelto. Per altre informazioni, vedere Operazioni di archiviazione. |
| Account di integrazione | Se si crea un account di integrazione per l'app per la logica da usare, la misurazione è basata sul tipo di account di integrazione creato. La fatturazione segue i prezzi dell'account di integrazione. Per altre informazioni, vedere Account di integrazione. |
Piani tariffari nel modello Standard
Il piano tariffario scelto per la misurazione e la fatturazione per la risorsa app per la logica (Standard) include quantità specifiche di calcolo nelle risorse di CPU virtuale (vCPU) e memoria. Se si seleziona un ambiente del servizio app v3 come percorso di distribuzione e un piano servizio app, in particolare un piano tariffario Isolated V2, vengono addebitati i costi per le istanze usate dal piano di servizio app e per l'esecuzione dei flussi di lavoro dell'app per la logica. Non sono previsti altri addebiti. Per altre informazioni, vedere piani tariffari servizio app Piano di servizio isolato V2.
Se si seleziona un piano di hosting Standard del flusso di lavoro, è possibile scegliere tra i livelli seguenti:
| Piano tariffario | CPU virtuale (vCPU) | Memoria (GB) |
|---|---|---|
| WS1 | 1 | 3,5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Importante
L'esempio seguente è relativo solo all'illustrazione e fornisce stime di esempio per illustrare in genere il funzionamento di un piano tariffario. Per prezzi specifici di vCPU e memoria in base a aree specifiche in cui è disponibile App per la logica di Azure, esaminare il piano Standard per un'area selezionata nella pagina dei prezzi di App per la logica di Azure.
Si supponga che in un'area di esempio le risorse seguenti abbiano queste tariffe orarie:
| Risorsa | Tariffa oraria (area di esempio) |
|---|---|
| vCPU | $0,192 per vCPU |
| Memoria | $ 0,0137 per GB |
Il calcolo seguente fornisce una tariffa mensile stimata:
<tariffa> mensile = 730 ore (al mese) * [(<number-vCPU> * <hourly-rate-vCPU>) + (<number-GB-memory> * <hourly-rate-GB-memory>)]
In base alle informazioni precedenti, la tabella seguente mostra le tariffe mensili stimate per ogni piano tariffario e le risorse nel piano tariffario:
| Piano tariffario | CPU virtuale (vCPU) | Memoria (GB) | Tariffa mensile (area di esempio) |
|---|---|---|---|
| WS1 | 1 | 3,5 | $ 175,16 |
| WS2 | 2 | 7 | $ 350,33 |
| WS3 | 4 | 14 | $ 700,65 |
Operazioni di attivazione e azione nel modello Standard
Ad eccezione delle operazioni predefinite gratuite illimitate che un flusso di lavoro può essere eseguito, il contatore del modello Standard e fattura un'operazione in base a ogni chiamata, indipendentemente dal fatto che il flusso di lavoro complessivo venga eseguito correttamente, venga completato o venga anche creata un'istanza. Un'operazione esegue in genere una singola esecuzione , a meno che l'operazione non disponga di tentativi abilitati. A sua volta, un'esecuzione esegue in genere una singola chiamata a meno che l'operazione non supporti e non consenta la suddivisione in blocchi o la paginazione per ottenere grandi quantità di dati. Se la suddivisione in blocchi o la paginazione è abilitata, l'esecuzione di un'operazione potrebbe dover effettuare più chiamate. Il contatore del modello Standard e fattura un'operazione per ogni chiamata, non per esecuzione.
Si supponga, ad esempio, che un flusso di lavoro inizi con un trigger di polling che ottiene i record effettuando regolarmente chiamate in uscita a un endpoint. La chiamata in uscita viene misurata e fatturata, indipendentemente dal fatto che il trigger venga attivato o ignorato. Lo stato del trigger controlla se l'istanza del flusso di lavoro viene creata ed eseguita. Si supponga ora che l'operazione supporti anche e abbia abilitato la suddivisione in blocchi o la paginazione. Se l'operazione deve effettuare 10 chiamate per completare il recupero di tutti i dati, l'operazione viene misurata e fatturata per ogni chiamata.
La tabella seguente riepiloga il modo in cui il modello Standard gestisce la misurazione e la fatturazione per i tipi di operazione quando vengono usati con un'app per la logica e un flusso di lavoro in App per la logica di Azure a tenant singolo:
| Tipo di operazione | Descrizione | Misurazione e fatturazione. |
|---|---|---|
| Predefinito | Queste operazioni vengono eseguite direttamente e in modo nativo con il runtime di App per la logica di Azure. Nella finestra di progettazione è possibile trovare queste operazioni nella raccolta connettori in Runtime>In-App. Ad esempio, il trigger HTTP e il trigger di richiesta sono trigger predefiniti. L'azione HTTP e l'azione Risposta sono azioni predefinite. Altre operazioni predefinite includono azioni di controllo del flusso di lavoro, ad esempio cicli e condizioni, operazioni di dati, operazioni batch e altre. |
Il modello Standard include operazioni predefinite gratuite illimitate. Nota: alcune operazioni del connettore gestito sono disponibili anche come operazioni predefinite. Anche se le operazioni predefinite sono gratuite, il modello Standard misura ancora e fattura le operazioni del connettore gestito usando gli stessi prezzi standard o Enterprise connector del modello a consumo. |
| Connettore gestito | Queste operazioni vengono eseguite separatamente in Azure globale condiviso. Nella finestra di progettazione è possibile trovare queste operazioni nella raccolta connettori in Runtime>Condiviso. | I contatori del modello Standard e fatturano le operazioni del connettore gestito in base agli stessi prezzi standard ed Enterprise Connector del modello a consumo. Nota: le operazioni preview Enterprise Connector seguono i prezzi del connettore Consumption Standard. |
| Connettore personalizzato | Attualmente, è possibile creare e usare solo operazioni del connettore predefinite personalizzate nei flussi di lavoro dell'app per la logica basata su tenant singolo. | Il modello Standard include operazioni predefinite gratuite illimitate. Per i limiti relativi alla velocità effettiva e al timeout, vedere Limiti del connettore personalizzato in App per la logica di Azure. |
Per altre informazioni sul funzionamento del modello Standard con operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborare più elementi, ad esempio matrici e criteri di ripetizione dei tentativi, vedere Altro comportamento dell'operazione.
Ambiente del servizio di integrazione
Quando si crea un'app per la logica usando il tipo di risorsa App per la logica (consumo) e si esegue la distribuzione in un ambiente del servizio di integrazione dedicato (ISE), l'app per la logica e il relativo flusso di lavoro seguono il piano di ambiente del servizio di integrazione per i prezzi e la fatturazione. Questo modello di determinazione prezzi dipende dal livello o dallo SKU ISE e differisce dal piano a consumo in quanto vengono fatturati per la capacità riservata e le risorse dedicate indipendentemente dal fatto che vengano usate o meno.
La tabella seguente riepiloga il modo in cui il modello ISE gestisce la misurazione e la fatturazione per la capacità e altre risorse dedicate in base al livello o allo SKU ISE:
| SKU ISE | Misurazione e fatturazione. |
|---|---|
| Premium | L'unità di base ha capacità fissa e viene fatturata a una tariffa oraria per lo SKU Premium. Se è necessaria una maggiore velocità effettiva, è possibile aggiungere altre unità di scala quando si crea l'ISE o successivamente. Ogni unità di scala viene fatturata a una tariffa oraria che è circa la metà della tariffa unità di base. Per informazioni sulla capacità e sui limiti, vedere Limiti ISE in App per la logica di Azure. |
| Developer | L'unità di base ha capacità fissa e viene fatturata a una tariffa oraria per lo SKU developer. Tuttavia, questo SKU non ha contratti di servizio, funzionalità di aumento delle prestazioni o ridondanza durante il riciclo, il che significa che potrebbero verificarsi ritardi o tempi di inattività. Gli aggiornamenti back-end potrebbero interrompere in modo intermittente il servizio. Importante: assicurarsi di usare questo SKU solo per l'esplorazione, gli esperimenti, lo sviluppo e il test, non per i test di produzione o delle prestazioni. Per informazioni sulla capacità e sui limiti, vedere Limiti ISE in App per la logica di Azure. |
La tabella seguente riepiloga il modo in cui il modello ISE gestisce i componenti seguenti quando vengono usati con un'app per la logica e un flusso di lavoro in un ISE:
| Componente | Descrizione |
|---|---|
| Operazioni di attivazione e azione | Il modello ISE include operazioni predefinite, connettore gestito e connettore personalizzato gratuite che il flusso di lavoro può essere eseguito, ma soggetto ai limiti ISE in App per la logica di Azure e ai limiti del connettore personalizzato in App per la logica di Azure. Per altre informazioni, vedere Operazioni di attivazione e azione nel modello ISE. |
| Operazioni di archiviazione | Il modello ISE include un consumo di archiviazione gratuito, ad esempio la conservazione dei dati. Per altre informazioni, vedere Operazioni di archiviazione. |
| Account di integrazione | Il modello ISE include un singolo livello di account di integrazione gratuito, in base allo SKU ISE selezionato. Per un costo aggiuntivo, è possibile creare più account di integrazione per l'ISE per l'uso fino al limite totale di ISE. Per altre informazioni, vedere Account di integrazione. |
Operazioni di attivazione e azione nel modello ISE
La tabella seguente riepiloga il modo in cui il modello ISE gestisce i tipi di operazione seguenti quando vengono usati con un'app per la logica e un flusso di lavoro in un ISE:
| Tipo di operazione | Descrizione | Misurazione e fatturazione. |
|---|---|---|
| Predefinito | Queste operazioni vengono eseguite direttamente e in modo nativo con il runtime di App per la logica di Azure e nello stesso ISE del flusso di lavoro dell'app per la logica. Nella finestra di progettazione è possibile trovare queste operazioni sotto l'etichetta predefinita , ma ogni operazione visualizza anche l'etichetta CORE . Ad esempio, il trigger HTTP e il trigger di richiesta sono trigger predefiniti. L'azione HTTP e l'azione Risposta sono azioni predefinite. Altre operazioni predefinite includono azioni di controllo del flusso di lavoro, ad esempio cicli e condizioni, operazioni di dati, operazioni batch e altre. |
Il modello ISE include queste operazioni gratuitamente, ma sono soggette ai limiti ISE in App per la logica di Azure. |
| Connettore gestito | Sia che si tratti di Standard o Enterprise, le operazioni del connettore gestito vengono eseguite in Azure ISE o multi-tenant, a seconda che il connettore o l'operazione visualizzi l'etichetta ISE . - Etichetta ISE : queste operazioni vengono eseguite nello stesso ISE dell'app per la logica e funzionano senza richiedere il gateway dati locale. - Nessuna etichetta ISE : queste operazioni vengono eseguite in Azure multi-tenant. |
Il modello ISE include sia ISE che nessuna operazione con etichetta ISEgratuitamente, ma sono soggetti ai limiti ISE in App per la logica di Azure. |
| Connettore personalizzato | Nella finestra di progettazione è possibile trovare queste operazioni sotto l'etichetta Personalizzata . | Il modello ISE include queste operazioni gratuitamente, ma sono soggette a limiti del connettore personalizzati in App per la logica di Azure. |
Per altre informazioni sul funzionamento del modello ISE con operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborare più elementi, ad esempio matrici e criteri di ripetizione dei tentativi, vedere Altro comportamento dell'operazione.
Altro comportamento dell'operazione
La tabella seguente riepiloga il modo in cui i modelli Consumption, Standard e ISE gestiscono le operazioni eseguite all'interno di altre operazioni, ad esempio cicli, elaborano più elementi, ad esempio matrici e criteri di ripetizione dei tentativi:
| Operazione | Descrizione | Consumo | Standard | ISE |
|---|---|---|---|---|
| Azioni ciclo | Un'azione ciclo, ad esempio il ciclo For each o Until , può includere altre azioni eseguite durante ogni ciclo di ciclo. | Ad eccezione del numero iniziale di operazioni predefinite incluse, l'azione del ciclo e ogni azione nel ciclo vengono misurate ogni volta che viene eseguito il ciclo del ciclo. Se un'azione elabora elementi in una raccolta, ad esempio un elenco o una matrice, viene utilizzato anche il numero di elementi nel calcolo della misurazione. Si supponga, ad esempio, di avere un ciclo For each con azioni che elaborano un elenco. Il servizio moltiplica il numero di elementi dell'elenco rispetto al numero di azioni nel ciclo e aggiunge l'azione che avvia il ciclo. Pertanto, il calcolo per un elenco di 10 elementi è (10 * 1) + 1, che comporta 11 esecuzioni di azioni. I prezzi si basano sul fatto che i tipi di operazione siano predefiniti, Standard o Enterprise. |
Ad eccezione delle operazioni predefinite incluse, come il modello a consumo. | Non a consumo o fatturati. |
| Criteri di ripetizione dei tentativi | Nelle operazioni supportate è possibile implementare la gestione di base delle eccezioni e degli errori configurando un criterio di ripetizione dei tentativi. | Ad eccezione del numero iniziale di operazioni predefinite, l'esecuzione originale più ogni nuovo tentativo di esecuzione viene misurata. Ad esempio, un'azione eseguita con 5 tentativi viene misurata e fatturata come 6 esecuzioni. I prezzi si basano sul fatto che i tipi di operazione siano predefiniti, Standard o Enterprise. |
Ad eccezione delle operazioni incluse predefinite, come il modello a consumo. | Non a consumo o fatturati. |
Operazioni di archiviazione
App per la logica di Azure usa Archiviazione di Azure per tutte le transazioni di archiviazione necessarie, ad esempio l'uso di code per la pianificazione delle operazioni di trigger o l'uso di tabelle e BLOB per l'archiviazione degli stati del flusso di lavoro. In base alle operazioni nel flusso di lavoro, i costi di archiviazione variano perché trigger, azioni e payload diversi comportano diverse operazioni e esigenze di archiviazione. Il servizio salva e archivia anche gli input e gli output dalla cronologia di esecuzione del flusso di lavoro, in base al limite di conservazione della cronologia di esecuzione della risorsa dell'app per la logica. È possibile gestire questo limite di conservazione a livello di risorsa dell'app per la logica, non a livello di flusso di lavoro.
La tabella seguente riepiloga il modo in cui i modelli Consumption, Standard e ISE gestiscono la misurazione e la fatturazione per le operazioni di archiviazione:
| Modellare | Descrizione | Misurazione e fatturazione. |
|---|---|---|
| Consumo (multi-tenant) | Le risorse di archiviazione e l'utilizzo sono collegati alla risorsa dell'app per la logica. | La misurazione e la fatturazione si applicano solo al consumo di archiviazione correlato alla conservazione dei dati e seguire i prezzi di conservazione dei dati per il piano a consumo. |
| Standard (tenant singolo) | È possibile usare il proprio account di archiviazione di Azure, che offre maggiore controllo e flessibilità sui dati del flusso di lavoro. | La misurazione e la fatturazione seguono il modello di prezzi di Archiviazione di Azure. I costi di archiviazione vengono visualizzati separatamente nella fattura di fatturazione di Azure. Suggerimento: per comprendere meglio il numero di operazioni di archiviazione che un flusso di lavoro potrebbe eseguire e il relativo costo, provare a usare il calcolatore di Archiviazione per le app per la logica. Selezionare un flusso di lavoro di esempio o usare una definizione del flusso di lavoro esistente. Il primo calcolo stima il numero di operazioni di archiviazione nel flusso di lavoro. È quindi possibile usare questi numeri per stimare i costi possibili usando il calcolatore prezzi di Azure. Per altre informazioni, vedere Stimare le esigenze e i costi di archiviazione per i flussi di lavoro in App per la logica di Azure a tenant singolo. |
| Ambiente del servizio di integrazione | Le risorse di archiviazione e l'utilizzo sono collegati alla risorsa dell'app per la logica. | Non a consumo o fatturati. |
Per altre informazioni, vedere la documentazione seguente:
- Visualizzare le metriche per le esecuzioni e l'utilizzo dell'archiviazione
- Limiti in App per la logica di Azure
Gateway dati locale
Il gateway dati locale è una risorsa di Azure separata creata in modo che i flussi di lavoro dell'app per la logica possano accedere ai dati locali usando connettori specifici supportati dal gateway. La risorsa gateway stessa non comporta addebiti, ma le operazioni eseguite tramite il gateway comportano addebiti, in base al modello di determinazione prezzi e fatturazione usato dall'app per la logica.
Account di integrazione
Un account di integrazione è una risorsa di Azure separata creata come contenitore per definire e archiviare artefatti business-to-business (B2B), ad esempio partner commerciali, contratti, schemi, mappe e così via. Dopo aver creato questo account e aver definito questi artefatti, collegare questo account all'app per la logica in modo che sia possibile usare questi artefatti e varie operazioni B2B nei flussi di lavoro per esplorare, compilare e testare soluzioni di integrazione che usano le funzionalità di elaborazione EDI e XML .
La tabella seguente riepiloga il modo in cui i modelli Consumption, Standard e ISE gestiscono la misurazione e la fatturazione per gli account di integrazione:
| Modellare | Misurazione e fatturazione. |
|---|---|
| Consumo (multi-tenant) | La misurazione e la fatturazione usano i prezzi dell'account di integrazione, in base al livello account usato. |
| Standard (tenant singolo) | La misurazione e la fatturazione usano i prezzi dell'account di integrazione, in base al livello account usato. |
| ISE | Questo modello include un singolo account di integrazione, basato sullo SKU ISE. Per un costo aggiuntivo, è possibile creare più account di integrazione per l'ISE per l'uso fino al limite totale di ISE. |
Per altre informazioni, vedere la documentazione seguente:
- Creare e gestire account di integrazione
- Limiti degli account di integrazione in App per la logica di Azure
Altri articoli non a consumo o fatturati
In tutti i modelli di determinazione prezzi, gli elementi seguenti non vengono a consumo o fatturati:
- Azioni non eseguite perché il flusso di lavoro è stato arrestato prima del completamento
- App per la logica o flussi di lavoro disabilitati perché non possono creare nuove istanze mentre sono inattive.