Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: Azure Logic Apps (Verbrauch + Standard)
Azure Logic Apps unterstützt Sie dabei, automatisierte Integrationsworkflows zu erstellen und auszuführen, die in der Cloud abskaliert werden können. In diesem Artikel werden Modelle für Verwendungsmessung, Abrechnung und Preise für Azure Logic Apps und die zugehörigen Ressourcen beschrieben. Informationen zu bestimmten Preisen, Kostenplanung oder verschiedenen Hostingumgebungen finden Sie in den folgenden Artikeln:
- Preise für Azure Logic Apps
- Planen und Verwalten von Kosten für Azure Logic Apps
- Einzelmandanten im Vergleich zu mehreren Mandanten
Verbrauch (Mehrere Mandanten)
In Azure Logic Apps mit mehreren Mandanten wird für eine Logik-App und ihren Workflow der Verbrauchsplan für Preise und Abrechnung verwendet. Sie erstellen solche Logik-Apps auf unterschiedliche Weisen, z. B. wenn Sie den Ressourcentyp Logik-App (Verbrauch) auswählen, die Erweiterung Azure Logic Apps (Verbrauch) in Visual Studio Code verwenden oder Automatisierungsaufgaben verwenden.
In der folgenden Tabelle wird zusammengefasst, wie das Verbrauchsmodell die Verbrauchsmessung und Abrechnung für die folgenden Komponenten verarbeitet, wenn es mit einer Logik-App und einem Workflow in Azure Logic Apps mit mehreren Mandanten verwendet wird:
Komponente | Messung und Abrechnung |
---|---|
Trigger- und Aktionsvorgänge | Das Verbrauchsmodell enthält eine anfängliche Anzahl von kostenlosen integrierten Vorgängen pro Azure-Abonnement, die ein Workflow ausführen kann. Über diesem Wert gilt für jede Ausführung die Verbrauchsmessung, und die Abrechnung erfolgt nach den Aktionspreisen für den Verbrauchsplan. Für andere Vorgangstypen wie verwaltete Connectors erfolgt die Abrechnung nach den Preisen für Standard- oder Unternehmensconnectors des Verbrauchsplans. Weitere Informationen finden Sie unter Trigger- und Aktionsvorgänge im Verbrauchsmodell. |
Speichervorgänge | Die Verbrauchsmessung gilt nur für den Speicherverbrauch im Zusammenhang mit der Datenaufbewahrung, z. B. das Speichern von Ein- und Ausgaben aus dem Ausführungsverlauf Ihres Workflows. Die Abrechnung erfolgt entsprechend den Preisen für die Datenaufbewahrung des Verbrauchsplans. Weitere Informationen finden Sie unter Speichervorgänge. |
Integrationskonten | Die Verbrauchsmessung wird basierend auf dem Integrationskontotyp angewendet, den Sie mit Ihrer Logik-App erstellen und verwenden. Die Abrechnung erfolgt gemäß den Preisen für Integrationskonten. Weitere Informationen finden Sie unter Integrationskonten. |
Trigger- und Aktionsvorgänge im Verbrauchsmodell
Mit Ausnahme der anfänglichen Anzahl kostenloser integrierter Vorgangsausführungen pro Azure-Abonnement, die ein Workflow ausführen kann, wird ein Vorgang im Verbrauchsmodell auf Grundlage jeder Ausführung gemessen und abgerechnet. Dies ist unabhängig davon, ob der gesamte Workflow erfolgreich ausgeführt, abgeschlossen oder sogar instanziiert wird. Ein Vorgang wird in der Regel einmal ausgeführt, es sei denn, für den Vorgang wurden Wiederholungsversuche aktiviert. Umgekehrt wird bei einer Ausführung in der Regel nur ein einzelner Aufruf ausgeführt, es sei denn, der Vorgang unterstützt und ermöglicht die Blockerstellung oder Paginierung, um große Datenmengen abzurufen. Wenn Blockerstellung oder Paginierung aktiviert ist, verfügt eine Vorgangsausführung möglicherweise über mehrere Aufrufe.
Mit dem Verbrauchsmodell wird ein Vorgang pro Ausführung und nicht pro Aufruf gemessen und abgerechnet. Angenommen, ein Workflow beginnt mit einem Abfragetrigger, der Datensätze abruft, indem regelmäßig ausgehende Aufrufe an einen Endpunkt durchgeführt werden. Der ausgehende Aufruf wird gemessen und als einzelne Ausführung abgerechnet, unabhängig davon, ob der Trigger ausgelöst oder übersprungen wird, z. B. wenn ein Trigger einen Endpunkt überprüft, aber keine Daten oder Ereignisse findet. Der Triggerzustand steuert, ob die Workflowinstanz erstellt und ausgeführt wird. Nehmen wir nun an, dass der Vorgang außerdem die Blockerstellung oder Paginierung unterstützt und diese aktiviert ist. Wenn der Vorgang 10 Aufrufe ausführen muss, um alle Daten abzurufen, wird der Vorgang trotz mehrerer Aufrufe weiterhin als eine einzelne Ausführung gemessen und abgerechnet.
Hinweis
Standardmäßig besitzen Auslöser, die ein Array zurückgeben, eine Einstellung Teilen bei, die bereits aktiviert ist. Diese Einstellung führt zu einem Triggerereignis, das Sie im Triggerverlauf überprüfen können, und zu einer Workflowinstanz für jedes Arrayelement. Alle Workflowinstanzen werden parallel ausgeführt, sodass die Arrayelemente gleichzeitig verarbeitet werden. Die Abrechnung gilt für alle Triggerereignisse, unabhängig davon, ob der Triggerstatus Erfolgreich oder Übersprungen lautet. Trigger sind auch in Szenarien abrechenbar, in denen die Trigger den Workflow nicht instanziieren und starten, aber der Triggerstatus Erfolgreich, Fehler oder Übersprungen lautet.
In der folgenden Tabelle wird zusammengefasst, wie das Verbrauchsmodell die Verbrauchsmessung und Abrechnung für diese Vorgangstypen verarbeitet, wenn es mit einer Logik-App und einem Workflow in Azure Logic Apps mit mehreren Mandanten verwendet wird:
Vorgangsart | BESCHREIBUNG | Messung und Abrechnung |
---|---|---|
Integriert | Diese Vorgänge werden direkt und nativ mit der Azure Logic Apps-Runtime ausgeführt. Im Designer finden Sie diese Vorgänge unter der Bezeichnung Integriert. Beispielsweise sind die Trigger „HTTP“ und „Anforderung“ integrierte Trigger. Die Aktionen „HTTP“ und „Antwort“ sind hingegen integrierte Aktionen. Andere integrierte Vorgänge umfassen Workflowsteuerungsaktionen wie Schleifen und Bedingungen, Datenvorgänge, Batchvorgänge usw. |
Das Verbrauchsmodell enthält eine anfängliche Anzahl von kostenlosen integrierten Vorgängen pro Azure-Abonnement, die ein Workflow ausführen kann. Oberhalb dieser Anzahl gelten für Ausführungen von integrierten Vorgängen die Preise für Aktionen. Hinweis: Einige Vorgänge für verwaltete Connectors sind auch als integrierte Vorgänge verfügbar, die in den ersten kostenlosen Vorgängen enthalten sind. Über die anfänglichen kostenlosen Vorgänge hinaus erfolgt die Abrechnung nach den Preisen für Aktionen, nicht nach den Preisen für Standard- oder Unternehmensconnectors. |
Verwalteter Connector | Diese Vorgänge werden separat in Azure ausgeführt. Im Designer finden Sie diese Vorgänge unter der Bezeichnung Standard oder Unternehmen. | Für diese Ausführungen von Vorgängen gelten die Preise für Standard- oder Unternehmensconnectors. Hinweis: Für die Vorgangsausführungen von Vorschau-Unternehmensconnectors gelten die Preise nach Verbrauch für Standardconnectors. |
Benutzerdefinierter Connector | Diese Vorgänge werden separat in Azure ausgeführt. Im Designer finden Sie diese Vorgänge unter der Bezeichnung Benutzerdefiniert. Informationen zu Grenzwerten für die Anzahl von Connectors, Durchsatz und Timeout finden Sie unter Grenzwerte für einen benutzerdefinierten Connector in Azure Logic Apps. | Für diese Ausführungen von Vorgängen gelten die Preise für Standardconnectors. |
Weitere Informationen zur Funktionsweise des Verbrauchsmodells mit Vorgängen, die in anderen Vorgängen wie Schleifen ausgeführt werden oder mehrere Elemente wie Arrays verarbeiten, sowie Wiederholungsrichtlinien finden Sie unter Verhalten bei anderen Vorgängen.
Tipps zur Kostenschätzung für das Verbrauchsmodell
Diese Tipps helfen Ihnen beim Schätzen genauerer Nutzungskosten:
Berücksichtigen Sie die mögliche Anzahl von Nachrichten oder Ereignissen, die an einem beliebigen Tag eingehen, statt Ihre Berechnungen nur auf das Abrufintervall zu stützen.
Wenn ein Ereignis oder eine Nachricht die Auslösekriterien erfüllt, versuchen viele Trigger sofort, alle anderen wartenden Ereignisse oder Nachrichten, die die Kriterien erfüllen, zu lesen. Dieses Verhalten bedeutet, dass auch bei Auswahl eines längeren Abrufintervalls der Trigger aufgrund der Anzahl der wartenden Ereignisse oder Nachrichten, die für das Starten von Workflows qualifiziert sind, ausgelöst wird. Zu den Triggern, die diesem Verhalten folgen, zählen Azure Service Bus und Azure Event Hubs.
Angenommen, Sie haben einen Trigger eingerichtet, der täglich einen Endpunkt überprüft. Wenn der Trigger den Endpunkt überprüft und 15 Ereignisse findet, die die Kriterien erfüllen, wird der Trigger ausgelöst und führt den entsprechenden Workflow 15 mal aus. Der Dienst Azure Logic Apps misst alle Aktionen, die diese 15 Workflows ausführen, einschließlich der Triggeranforderungen.
Standard (ein Mandant)
In Azure Logic Apps mit einem Mandanten wird für eine Logik-App und ihren Workflow der Standardplan für Preise und Abrechnung verwendet. Sie erstellen solche Logik-Apps auf unterschiedliche Weisen, z. B. wenn Sie den Ressourcentyp Logik-App (Standard) auswählen oder die Erweiterung Azure Logic Apps (Standard) in Visual Studio Code verwenden. Für dieses Preismodell müssen Logik-Apps einen Hostingplan und einen Tarif verwenden. Dies unterscheidet sich vom Verbrauchsplan insofern, dass Ihnen reservierte Kapazitäten und dedizierte Ressourcen in Rechnung gestellt werden, unabhängig davon, ob Sie sie verwenden.
Wenn Sie eine Logik-App mit dem Ressourcentyp Logik-App (Standard) erstellen, wählen Sie eine Hostingoption aus, z. B. Workflow-Serviceplan, App Service Environment V3 oder Hybrid.
Wichtig
Wenn Sie App Service Environment V3 auswählen, müssen Sie auch einen App Service Plan auswählen. Der App Service-Plan ist verfügbar und wird nur mit App Service-Umgebung v3 (ASE v3) unterstützt.
Die folgenden Pläne und Ressourcen sind mit der öffentlichen Freigabe von Standard Logic App Workflows in Azure Logic Apps mit einem Mandanten nicht mehr verfügbar oder werden nicht mehr unterstützt: Functions Premium Plan, App Service-Umgebung v1 und App Service-Umgebung v2.
In der folgenden Tabelle wird zusammengefasst, wie das Standardmodell die Verbrauchsmessung und Abrechnung für die folgenden Komponenten verarbeitet, wenn es mit einer Logik-App und einem Workflow in Azure Logic Apps mit einem Mandanten verwendet wird:
Komponente | Messung und Abrechnung |
---|---|
Virtuelle CPU (vCPU) und Arbeitsspeicher | Für die Hostingoptionen Workflow Service Plan und App Service Environment V3 wählen Sie auch ein Preisniveau aus, das die Ressourcenstufen und Preissätze bestimmt, die für die Berechnungs- und Arbeitsspeicherkapazität gelten. Weitere Informationen finden Sie unter Preisniveaus im Standardmodell. Informationen zur Hybridbereitstellung finden Sie unter Standard (Hybridbereitstellung). |
Trigger- und Aktionsvorgänge | Das Standardmodell umfasst eine unbegrenzte Anzahl kostenloser integrierter Vorgänge, die Ihr Workflow ausführen kann. Wenn Ihr Workflow Vorgänge für verwaltete Connectors verwendet, gilt die Messung für jeden Aufruf, während für die Abrechnung dieselben Preise für Standard- oder Unternehmensconnectors wie im Verbrauchsplan gelten. Weitere Informationen finden Sie unter Trigger- und Aktionsvorgänge im Standardmodell. |
Speichervorgänge | Die Messung gilt für alle Speichervorgänge, die von Azure Logic Apps ausgeführt werden. Speichervorgänge werden beispielsweise ausgeführt, wenn der Dienst Eingaben und Ausgaben aus dem Ausführungsverlauf des Workflows speichert. Die Abrechnung erfolgt nach dem von Ihnen gewählten Tarif. Weitere Informationen finden Sie unter Speichervorgänge. |
Integrationskonten | Wenn Sie ein Integrationskonto für Ihre Logik-App erstellen, basiert die Messung auf dem Typ des erstellten Integrationskontos. Die Abrechnung erfolgt gemäß den Preisen für Integrationskonten. Weitere Informationen finden Sie unter Integrationskonten. |
Tarife im Standardmodell
Der Tarif, den Sie für die Messung und Abrechnung Ihrer Logik-App (Standard)-Ressource auswählen, umfasst bestimmte Computemengen in virtuellen CPU (vCPU)- und Arbeitsspeicherressourcen. Wenn Sie App Service Environment V3 als Hostingoption und einen App-Serviceplan auswählen, insbesondere ein Preisniveau für isolierten V2-Serviceplan, werden Sie für die Instanzen berechnet, die vom App Service Plan verwendet werden, und für die Ausführung Ihrer Logik-App-Workflows. Es fallen keine weiteren Gebühren an. Weitere Informationen finden Sie unter App Service Plan – Tarife für isolierte V2-Dienstpläne.
Wenn Sie einen Workflow-Standard-Hostingplan auswählen, können Sie zwischen den folgenden Ebenen wählen:
Tarif | Virtuelle CPU (vCPU) | Arbeitsspeicher (GB) |
---|---|---|
WS1 | 1 | 3,5 |
WS2 | 2 | 7 |
WS3 | 4 | 14 |
Wichtig
Das folgende Beispiel dient nur zur Veranschaulichung und enthält Beispielschätzungen, um die Funktionsweise eines Tarifs allgemein zu zeigen. Informationen zu spezifischen vCPU- und Arbeitsspeicherpreisen basierend auf bestimmten Regionen, in denen Azure Logic Apps verfügbar ist, finden Sie im Standardplan für eine ausgewählte Region auf der Seite mit Azure Logic Apps-Preisinformationen.
Angenommen, in einer Beispielregion gelten für die folgenden Ressourcen diese Stundensätze:
Ressource | Stundensatz (Beispielregion) |
---|---|
vCPU | 0,192 USD pro vCPU |
Arbeitsspeicher | 0,0137 USD pro GB |
Die folgende Berechnung liefert eine geschätzte monatliche Rate:
< Monatliche Rate> = 730 Stunden (pro Monat) * [(<Anzahl_vCPU> * <Stundensatz_vCPU>) + (<Menge_GB_Arbeitsspeicher> * <Stundensatz_GB_Arbeitsspeicher>)]
Auf Grundlage der obigen Informationen zeigt die folgende Tabelle die geschätzten Monatsraten für die einzelnen Tarife und die darin enthaltenen Ressourcen:
Tarif | Virtuelle CPU (vCPU) | Arbeitsspeicher (GB) | Monatliche Rate (Beispielregion) |
---|---|---|---|
WS1 | 1 | 3,5 | 175,16 USD |
WS2 | 2 | 7 | 350,33 USD |
WS3 | 4 | 14 | 700,65 USD |
Trigger- und Aktionsvorgänge im Standardmodell
Mit Ausnahme der unbegrenzten kostenlosen integrierten Vorgangsausführungen, die ein Workflow ausführen kann, misst und berechnet das Standardmodell einen Vorgang auf Grundlage jedes Aufrufs, unabhängig davon, ob der gesamte Workflow erfolgreich ausgeführt, abgeschlossen oder sogar instanziiert wird. Ein Vorgang wird in der Regel einmal ausgeführt, es sei denn, für den Vorgang wurden Wiederholungsversuche aktiviert. Umgekehrt wird bei einer Ausführung in der Regel nur ein einzelner Aufruf ausgeführt, es sei denn, der Vorgang unterstützt und ermöglicht die Blockerstellung oder Paginierung, um große Datenmengen abzurufen. Wenn Blockerstellung oder Paginierung aktiviert ist, verfügt eine Vorgangsausführung möglicherweise über mehrere Aufrufe. Mit dem Standardmodell wird ein Vorgang pro Aufruf und nicht pro Ausführung gemessen und abgerechnet.
Angenommen, ein Workflow beginnt mit einem Abfragetrigger, der Datensätze abruft, indem regelmäßig ausgehende Aufrufe an einen Endpunkt durchgeführt werden. Der ausgehende Aufruf wird gemessen und abgerechnet, unabhängig davon, ob der Trigger ausgelöst oder übersprungen wird. Der Triggerzustand steuert, ob die Workflowinstanz erstellt und ausgeführt wird. Nehmen wir nun an, dass der Vorgang außerdem die Blockerstellung oder Paginierung unterstützt und diese aktiviert ist. Wenn der Vorgang 10 Aufrufe ausführen muss, um alle Daten abzurufen, wird der Vorgang pro Aufruf gemessen und abgerechnet.
In der folgenden Tabelle wird zusammengefasst, wie das Standardmodell die Verbrauchsmessung und Abrechnung für Vorgangstypen verarbeitet, wenn es mit einer Logik-App und einem Workflow in Azure Logic Apps mit einem Mandanten verwendet wird:
Vorgangsart | BESCHREIBUNG | Messung und Abrechnung |
---|---|---|
Integriert | Diese Vorgänge werden direkt und nativ mit der Azure Logic Apps-Runtime ausgeführt. Im Designer finden Sie diese Vorgänge im Verbinderkatalog unter "Integriert". Beispielsweise sind die Trigger „HTTP“ und „Anforderung“ integrierte Trigger. Die Aktionen „HTTP“ und „Antwort“ sind hingegen integrierte Aktionen. Andere integrierte Vorgänge umfassen Workflowsteuerungsaktionen wie Schleifen und Bedingungen, Datenvorgänge, Batchvorgänge usw. |
Das Standardmodell umfasst unbegrenzte kostenlose integrierte Vorgänge. Hinweis: Einige Vorgänge für verwaltete Connectors sind auch als integrierte Vorgänge verfügbar. Obwohl integrierte Vorgänge kostenlos sind, werden Vorgänge mit verwalteten Connectors im Standardmodell gemessen und abgerechnet. Dafür werden dieselben Preise für Standard- oder Unternehmensconnectors verwendet wie im Verbrauchsmodell. |
Verwalteter Connector | Diese Vorgänge werden in geteiltem globalem Azure separat ausgeführt. Im Designer finden Sie diese Vorgänge im Connectorkatalog unter Runtime>Geteilt. | Im Standardmodell werden Vorgänge mit verwalteten Connectors gemäß denselben Preisen für Standard- oder Unternehmensconnectors wie im Verbrauchsmodell gemessen und abgerechnet. Hinweis: Für Unternehmensconnector-Vorgänge gelten die Preise nach Verbrauch für Standardconnectors. |
Benutzerdefinierter Connector | Derzeit können Sie nur benutzerdefinierte integrierte Connectorvorgänge in Logik-App-Workflows mit einem Mandanten erstellen und verwenden. | Das Standardmodell umfasst unbegrenzte kostenlose integrierte Vorgänge. Informationen zu Grenzwerten für Durchsatz und Timeout finden Sie unter Grenzwerte für einen benutzerdefinierten Connector in Azure Logic Apps. |
Weitere Informationen zur Funktionsweise des Standardmodells mit Vorgängen, die in anderen Vorgängen wie Schleifen ausgeführt werden oder mehrere Elemente wie Arrays verarbeiten, sowie Wiederholungsrichtlinien finden Sie unter Verhalten bei anderen Vorgängen.
Standard – Hybridbereitstellung
Diese Hostingoption verwendet ein Abrechnungsmodell, bei dem Sie nur für das, was Sie benötigen, bezahlen und Ressourcen für dynamische Workloads skalieren können, ohne eine Spitzenauslastung kaufen zu müssen. Sie sind für die folgenden Elemente verantwortlich:
Ihre Azure Arc-fähige Kubernetes-Infrastruktur
Ihre SQL Server-Lizenz
Abrechnungsgebühren für die vCPU-Nutzung zur Unterstützung von Standardlogik-App-Workloads
Weitere Informationen hierzu finden Sie in den folgenden Abschnitten:
Abrechnungsgebühren für alle verwalteten (freigegebenen) Connectorvorgänge, z. B. Microsoft Teams oder Microsoft Office 365, in Ihren Logik-App-Workflows.
Diese Vorgangsausführungen folgen den Standardpreisen.
vCPU-Verwendungsberechnung
Die vCPU-Verwendung für Ihre Standardlogik-App wirkt sich auf Ihre Abrechnungsgebühren aus. Eine vCPU bezieht sich auf die Anzahl der CPU-Kerne, aber dieses Verhältnis ist nicht notwendigerweise 1:1. Mit der folgenden Formel wird die vCPU-Verwendung für Ihre Logik-App berechnet:
vCPU-Verwendung = (Anzahl der zugewiesenen vCPUs) x (Anzahl der Replikate)
Wert | BESCHREIBUNG |
---|---|
Anzahl der zugewiesenen vCPUs | Standardmäßig wird Ihrer Logik-App eine Standardanzahl von vCPUs zugewiesen. Sie können diese vCPU-Zuordnung jederzeit ändern , nachdem Sie ihre Logik-App-Ressource erstellt haben. Hinweis: Alle vCPUs, die Sie Ihrer Logik-App zuweisen, stammen aus Replikat-vCPUs , sodass Ihr Zuordnungsbereich zwischen 0,25 und 2 Kernen liegt. Weitere Informationen finden Sie in der nächsten Zeile. |
Anzahl der Replikate | Ein Replikat ist eine neue Instanz einer Logik-App-Ressourcenrevision oder -version, die bereitgestellt wird, wenn ein Workflowtriggerereignis auftritt. Diese Anzahl von Replikaten kann aufgrund der Skalierungsanforderungen Ihrer App zu einem bestimmten Zeitpunkt variieren. Sie können die minimale und maximale Anzahl von Replikaten ändern , die für jede Version oder Revision erforderlich sein können, um Ihre Skalierungsanforderungen zu erfüllen. Hinweis: Jedes Replikat ist auf zwei vCPUs beschränkt. Alle vCPUs, die Sie Ihrer Logik-App zuweisen, stammen aus Replikat-vCPUs, sodass ihr Zuordnungsbereich 0,25 bis 2 Kerne beträgt. |
Berechnung der Abrechnungsgebühr
Mit der folgenden Formel wird die Abrechnungsgebühr pro Stunde berechnet, die auf der vCPU-Nutzung und dem $USD-Satz pro Stunde im Abschnitt "Preise für das Hybridbereitstellungsmodell für Logik-Apps" basiert, während Ihre Logik-App aktiviert ist:
Gebühr pro Stunde = (vCPU-Nutzung) x (Rate pro Stunde)
Die folgende Tabelle zeigt z. B. nur einige Beispielberechnungen für Abrechnungsgebühren:
Anzahl der zugewiesenen vCPUs | Anzahl der Replikate | vCPU-Verwendung | $USD Rate pro Stunde | Gebühr pro Stunde |
---|---|---|---|---|
1 | 1 | (1 x 1) = 1 | $0,22 | (1 x 0,22 $) = 0,22 $ |
0,5 | 2 | (0,5 x 2) = 1 | $0,22 | (1 x 0,22 $) = 0,22 $ |
0,5 | 1 | (0,5 x 1) = 0,5 | $0,22 | (0,5 x $0,22) = $0,11 |
Verhalten bei anderen Vorgängen
Die folgende Tabelle zeigt die Funktionsweise des Verbrauchsmodells und Standardmodells mit Vorgängen, die in anderen Vorgängen wie Schleifen ausgeführt werden oder mehrere Elemente wie Arrays verarbeiten, und Wiederholungsrichtlinien:
Vorgang | BESCHREIBUNG | Nutzung | Norm |
---|---|---|---|
Schleifenaktionen | Eine Schleifenaktion, z. B. eine For each- oder Until-Schleife, kann andere Aktionen enthalten, die während jedes Schleifendurchlaufs ausgeführt werden. | Mit Ausnahme der anfänglichen Anzahl der integrierten Vorgänge werden die Schleifenaktion und jede Aktion in der Schleife bei jedem Schleifendurchlauf gemessen. Wenn eine Aktion Elemente in einer Sammlung verarbeitet, z. B. eine Liste oder ein Array, wird die Anzahl der Elemente ebenfalls bei der Messung berücksichtigt. Angenommen, Sie verfügen über eine For each-Schleife mit Aktionen, die eine Liste verarbeiten. Der Dienst multipliziert die Anzahl von Listenelementen mit der Anzahl von Aktionen in der Schleife. Anschließend wird die Aktion hinzugefügt, mit der die Schleife gestartet wird. Daher lautet die Berechnung für eine Liste mit zehn Elementen (10 * 1) + 1, sodass sich 11 Aktionsausführungen ergeben. Die Preise basieren darauf, ob der Vorgangstyp „Integriert“, „Standard“ oder „Unternehmen“ lautet. |
Mit Ausnahme der eingeschlossenen integrierten Vorgänge wie im Verbrauchsmodell. |
Wiederholungsrichtlinien | Bei unterstützten Vorgängen können Sie eine grundlegende Ausnahme- und Fehlerbehandlung implementieren, indem Sie eine Wiederholungsrichtlinie einrichten. | Mit Ausnahme der anfänglichen Anzahl integrierter Vorgänge werden die ursprüngliche Ausführung plus jede wiederholte Ausführung gemessen. Beispielsweise werden für eine Aktion, die mit fünf Wiederholungen ausgeführt wird, sechs Ausführungen gemessen und berechnet. Die Preise basieren darauf, ob der Vorgangstyp „Integriert“, „Standard“ oder „Unternehmen“ lautet. |
Mit Ausnahme der eingeschlossenen integrierten Vorgänge wie im Verbrauchsmodell. |
Speichervorgänge
Azure Logic Apps verwendet Azure Storage für alle erforderlichen Speichertransaktionen, z. B. die Verwendung von Warteschlangen zum Planen von Triggervorgängen oder die Verwendung von Tabellen und Blobs zum Speichern von Workflowzuständen. Basierend auf den Vorgängen in Ihrem Workflow variieren die Speicherkosten, da verschiedene Trigger, Aktionen und Nutzlasten zu unterschiedlichen Speichervorgängen und -anforderungen führen. Der Dienst speichert außerdem Eingaben und Ausgaben aus dem Ausführungsverlauf Ihres Workflows. Dabei gilt der Grenzwert für die Aufbewahrung des Ausführungsverlaufs für die Logik-App-Ressource. Sie können diesen Aufbewahrungsgrenzwert auf Logik-App-Ressourcenebene und nicht auf Workflowebene verwalten.
In der folgenden Tabelle wird zusammengefasst, wie Messung und Abrechnung für Speichervorgänge im Verbrauchs- und Standardmodell verarbeitet werden:
Modell | BESCHREIBUNG | Messung und Abrechnung |
---|---|---|
Verbrauch (Mehrere Mandanten) | Speicherressourcen und -nutzung werden an die Logik-App-Ressource angefügt. | Messung und Abrechnung beziehen sich nur auf den Speicherverbrauch im Zusammenhang mit der Datenaufbewahrung. Es gelten die Preise für die Datenaufbewahrung für den Verbrauchsplan. |
Standard (ein Mandant) | Sie können Ihr eigenes Azure-Speicherkonto verwenden. Dies bietet Ihnen mehr Kontrolle und Flexibilität bei den Daten Ihres Workflows. | Messung und Abrechnung erfolgen nach dem Azure Storage-Preismodell. Speicherkosten werden in Ihrer Azure-Rechnung separat aufgeführt. Tipp: Um eine Vorstellung von der Anzahl der Speichervorgänge, die ein Workflow ausführen könnte, und deren Kosten zu erhalten, verwenden Sie den Logic Apps-Speicherrechner. Sie können entweder einen Beispielworkflow auswählen oder eine vorhandene Workflowdefinition verwenden. Die erste Berechnung schätzt die Anzahl der Speichervorgänge in Ihrem Workflow. Sie können diese Zahlen dann verwenden, um mögliche Kosten mithilfe des Azure-Preisrechners zu schätzen. Weitere Informationen finden Sie in den folgenden Ressourcen: - Abschätzen der Speicheranforderungen und -kosten für Workflows in Azure Logic Apps für nur einen Mandanten - Anzeigen von Metriken für Ausführungen und Speichernutzung - Grenzwerte in Azure Logic Apps |
Lokales Datengateway
Das lokale Datengateway ist eine gesonderte Azure-Ressource, die Sie erstellen, damit Ihre Logik-App-Workflows über bestimmte vom Gateway unterstützte Connectors auf lokale Daten zugreifen können. Für die Gatewayressource selbst fallen keine Gebühren an, aber für Vorgänge, die über das Gateway ausgeführt werden. Hierfür gelten die Preise und das Abrechnungsmodell, die von Ihrer Logik-App verwendet werden.
Integrationskonten
Ein Integrationskonto ist eine separate Azure-Ressource, die Sie als Container erstellen, um B2B-Artefakte (Business-to-Business) wie Handelspartner, Vereinbarungen, Schemas, Zuordnungen usw. zu definieren und zu speichern. Nachdem Sie dieses Konto erstellt und diese Artefakte definiert haben, verknüpfen Sie das Konto mit Ihrer Logik-App, damit Sie die Artefakte und verschiedene B2B-Vorgänge in Workflows verwenden können. So können Sie Integrationslösungen untersuchen, erstellen und testen, die EDI- und XML-Verarbeitungsfunktionen verwenden.
In der folgenden Tabelle wird zusammengefasst, wie Messung und Abrechnung für Integrationskonten im Verbrauchs- und Standardmodell verarbeitet werden:
Modell | Messung und Abrechnung |
---|---|
Verbrauch (Mehrere Mandanten) | Für Messung und Abrechnung werden die Preise für Integrationskonten auf Grundlage der von Ihnen verwendeten Kontoebene genutzt. |
Standard (ein Mandant) | Für Messung und Abrechnung werden die Preise für Integrationskonten auf Grundlage der von Ihnen verwendeten Kontoebene genutzt. |
Weitere Informationen finden Sie in der folgenden Dokumentation:
- Erstellen und Verwalten von Integrationskonten
- Grenzwerte für Integrationskonten in Azure Logic Apps
Andere Elemente, die nicht gemessen oder abgerechnet werden
In allen Preismodellen werden die folgenden Elemente nicht gemessen oder abgerechnet:
- Aktionen, die nicht ausgeführt wurden, weil der Workflow vor Abschluss beendet wurde
- Deaktivierte Logik-Apps oder Workflows, da für sie keine neuen Instanzen erstellt werden können, wenn sie inaktiv sind