Teilen über

Unterschiede zwischen Standard-Logik-Apps mit Einzelmandant und Verbrauchs-Logik-Apps mit mehreren Mandanten

  • Artikel

Azure Logic Apps ist eine cloudbasierte Plattform zum Erstellen und Ausführen von automatisierten Logik-App-Workflows, um Ihre Apps, Daten, Dienste und Systeme zu integrieren. Mit dieser Plattform können Sie schnell hochgradig skalierbare Integrationslösungen für Unternehmens- und B2B-Szenarios (Business-to-Business) erstellen. Wenn Sie eine Logik-App-Ressource erstellen, wählen Sie entweder die Option Verbrauch oder Standard als Hostingoption aus. Eine Verbrauchslogik-App kann nur über einen Workflow verfügen, der in mehrinstanzenfähigen Azure Logic Apps ausgeführt wird. Eine Standard-Logik-App kann über einen oder mehrere Workflows verfügen, die in Azure Logic Apps mit einem Einzelmandanten oder einer App Service-Umgebung v3 (ASE v3) ausgeführt werden.

Bevor Sie auswählen, welche Logik-App-Ressource erstellt werden soll, lesen Sie den folgenden Leitfaden, um zu erfahren, wie sich die Workflowtypen für Logik-Apps unterscheiden. Sie können dann eine bessere Wahl treffen, welcher Logik-App-Workflow und welche Umgebung am besten zu Ihrem Szenario, Ihren Lösungsanforderungen und dem Ziel passt, an dem Sie Ihre Workflows bereitstellen und ausführen möchten.

Wenn Sie noch nicht mit Azure Logic Apps vertraut sind, lesen Sie Was ist Azure Logic Apps? und Was ist ein Logik-App-Workflow?.

Logik-App-Workflowtypen und -Umgebungen

In der folgenden Tabelle werden die Unterschiede zwischen einem Verbrauchs- und einem Standard-Logik-App-Workflow zusammengefasst. Außerdem erfahren Sie, wie sich die Einzelmandantenumgebung von der mehrinstanzenfähigen Umgebung zum Bereitstellen, Hosten und Ausführen Ihrer Workflows unterscheidet.

Hostingoption Vorteile Ressourcenfreigabe und -nutzung Preis- und Abrechnungsmodell Verwaltung von Grenzwerten
Verbrauch

Hostumgebung: Mehrere Mandanten in Azure Logic Apps		 – Einfacher Einstieg

- Nutzungsabhängige Abrechnung

– Vollständig verwaltet		 Eine Logik-App-Ressource kann nur einen Workflow haben.

Alle Logik-Apps in mehreren Microsoft Entra-Mandanten nutzen dieselben Ressourcen für die Verarbeitung (Compute), den Speicher, das Netzwerk usw.

Aus Redundanzgründen werden Daten in der gekoppelten Region repliziert. Für Hochverfügbarkeit ist georedundanter Speicher (GRS) aktiviert.		 Verbrauch (ausführungsbasierte Bezahlung) Azure Logic Apps verwaltet die Standardwerte für diese Grenzwerte, aber Sie können einige dieser Werte ändern, wenn diese Option für einen bestimmten Grenzwert vorhanden ist.
Standard (Workflowdienstplan)

Hostumgebung:
Azure Logic Apps-Instanz mit nur einem Mandanten

Hinweis: Falls in Ihrem Szenario Container erforderlich sind, erstellen Sie Logik-Apps mit nur einem Mandanten mithilfe von Logic Apps mit Azure Arc-Unterstützung. Weitere Informationen finden Sie unter Was ist Logic Apps mit Azure Arc-Unterstützung?.		 - Mehr integrierte Connectors, die auf der Runtime des Einzelmandanten gehostet werden, für einen höheren Durchsatz und niedrigere Kosten bei Erweiterung

– Mehr Steuerungs- und Optimierungsfunktionen für Laufzeit- und Leistungseinstellungen

– Integrierte Unterstützung für virtuelle Netzwerke und private Endpunkte

– Erstellen von eigenen integrierten Connectors		 Eine einzelne Logik-App-Ressource kann über mehrere zustandsbehaftete und zustandsfreie Workflows verfügen.

Workflows in einer einzelnen Logik-App und einem einzelnen Mandanten nutzen dieselben Ressourcen für die Verarbeitung (Compute), den Speicher, das Netzwerk usw.

Daten verbleiben in derselben Region, in der Sie die Logik-Apps bereitstellen.		 Standard, basierend auf einem Hostingplan mit einem ausgewählten Tarif

Wenn Sie zustandsbehaftete Workflows ausführen, die externen Speicher verwenden, nimmt die Azure Logic Apps-Runtime Speichertransaktionen entsprechend den Azure Storage-Preisen vor.		 Sie können die Standardwerte für viele Grenzwerte basierend auf den Anforderungen Ihres Szenarios ändern.

Wichtig: Einige Grenzwerte haben harte Obergrenzen. In Visual Studio Code werden die Änderungen, die Sie an den Standardgrenzwerten in den Konfigurationsdateien Ihrer Logik-App-Projekte vornehmen, nicht in der Designererfahrung angezeigt. Weitere Informationen finden Sie unter Bearbeiten von App- und Umgebungseinstellungen für Logik-Apps in einzelinstanzenfähigen Azure Logic Apps.
Standard (App Service-Umgebung v3)

Hostumgebung:
App Service-Umgebung v3 (ASEv3) – nur Windows-Pläne		 Gleiche Funktionen wie Einzelmandant sowie folgende Vorteile:

– Vollständige Isolierung Ihrer Logik-Apps

– Erstellen und Ausführen von mehr Logik-Apps als im Azure Logic Apps-Einzelmandanten

– Bezahlen nur für den ASE-App Service-Plan, unabhängig von der Anzahl der Logik-Apps, die Sie erstellen und ausführen

– Kann die automatische Skalierung oder manuelle Skalierung mit mehr VM-Instanzen oder einem anderen App Service-Plan ermöglichen

– Erben des Netzwerksetups von der ausgewählten ASEv3 Wenn Sie Workflows beispielsweise in einer internen ASE bereitstellen, können diese auf die Ressourcen in einem virtuellen Netzwerk zugreifen, das der ASE zugeordnet ist und über interne Zugriffspunkte verfügt.

Hinweis: Wenn der Zugriff von außerhalb einer internen ASE erfolgt, können Ausführungsverläufe für Workflows in dieser ASE nicht auf Aktionseingaben und -ausgaben zugreifen.		 Eine einzelne Logik-App kann über mehrere zustandsbehaftete und zustandslose Workflows verfügen.

Workflows in einer einzelnen Logik-App und einem einzelnen Mandanten nutzen dieselben Ressourcen für die Verarbeitung (Compute), den Speicher, das Netzwerk usw.

Daten verbleiben in derselben Region, in der Sie Ihre Logik-Apps bereitstellen.		 App Service-Plan Sie können die Standardwerte für viele Grenzwerte basierend auf den Anforderungen Ihres Szenarios ändern.

Wichtig: Einige Grenzwerte haben harte Obergrenzen. In Visual Studio Code werden die Änderungen, die Sie an den Standardgrenzwerten in den Konfigurationsdateien Ihrer Logik-App-Projekte vornehmen, nicht in der Designererfahrung angezeigt. Weitere Informationen finden Sie unter Bearbeiten von App- und Umgebungseinstellungen für Logik-Apps in einzelinstanzenfähigen Azure Logic Apps.

Standard-Logik-App und -Workflow

Die Logik-App und der Workflow vom Typ Standard werden von der neu gestalteten Runtime für Azure Logic Apps-Instanzen mit einem einzigen Mandanten unterstützt. Die Runtime wendet das Azure Functions-Erweiterbarkeitsmodell an und wird als Erweiterung der Azure Functions-Runtime gehostet. Dieser Entwurf bietet Portabilität, Flexibilität und eine höhere Leistung für Ihre Logik-App-Workflows sowie weitere Funktionen und Vorteile der Azure Functions-Plattform und des Azure App Service-Ökosystems. Beispielsweise können Sie Logik-Apps mit nur einem Mandanten und deren Workflows in Azure App Service-Umgebung v3 (nur Windows-Pläne) erstellen, bereitstellen und ausführen.

Mit der Standard-Logik-App wird eine Ressourcenstruktur zum Hosten mehrerer Workflows eingeführt. Dies ist vergleichbar mit einer Azure Funktions-App, die mehrere Funktionen hosten kann. Bei einer 1:n-Zuordnung nutzen Workflows in derselben Logik-App und demselben Mandanten Compute- und Verarbeitungsressourcen gemeinsam und bieten aufgrund ihrer Nähe eine bessere Leistung. Diese Struktur weicht gegenüber der Verbrauchs-Logik-App-Ressource ab, bei der zwischen der Logik-App-Ressource und einem Workflow eine 1:1-Zuordnung besteht.

Weitere Informationen zu Portabilität, Flexibilität und Leistungsverbesserungen finden Sie in den folgenden Abschnitten. Weitere Informationen zur Runtime für Azure Logic Apps-Instanzen mit einem Mandanten sowie Azure Functions-Erweiterungen finden Sie in den folgenden Artikeln:

Portabilität und Flexibilität

Wenn Sie eine Logik-App und einen Workflow vom Typ Standard erstellen, können Sie Ihren Workflow in anderen Umgebungen, wie z. B. Azure App Service-Umgebung v3 (nur Windows-Pläne) bereitstellen und ausführen. Wenn Sie Visual Studio Code mit der Erweiterung Azure Logic Apps (Standard) verwenden, können Sie Ihren Workflow lokal in Ihrer Entwicklungsumgebung entwickeln, erstellen und ausführen, ohne eine Bereitstellung in Azure durchführen zu müssen. Falls in Ihrem Szenario Container erforderlich sind, können Sie Logik-Apps mit nur einem Mandanten mithilfe von Logic Apps mit Azure Arc-Unterstützung erstellen. Weitere Informationen finden Sie unter Was ist Logic Apps mit Azure Arc-Unterstützung?.

Verglichen mit dem mehrinstanzenfähigen Modell, bei dem Sie für eine vorhandene, in Azure ausgeführte Ressource entwickeln müssen, stellen diese Funktionen eine erhebliche Verbesserung und einen entscheidenden Vorteil dar. Das mehrinstanzenfähige Modell für die automatisierte Bereitstellung von Verbrauchs-Logik-App-Ressourcen basiert auf ARM-Vorlagen (Azure Resource Manager-Vorlagen), in denen die Ressourcenbereitstellung für Apps sowie die Infrastruktur kombiniert und gemeinsam verarbeitet wird.

Mit der Standard-Logik-App-Ressource wird die Bereitstellung einfacher, da Sie Apps und die Infrastruktur getrennt voneinander bereitstellen können. Sie können die Runtime für die Azure Logic Apps-Instanz mit einem Mandanten und Ihre Workflows gemeinsam als Teil Ihrer Logik-App-Ressource oder Ihres Projekts zusammenfassen. Mit allgemeinen Schritten oder Aufgaben können Sie die Ressourcen Ihrer Logik-App als einsatzbereite Artefakte erstellen, zusammenstellen und zippen. Für die Bereitstellung Ihrer Infrastruktur können Sie weiterhin ARM-Vorlagen verwenden, um die einzelnen Ressourcen zusammen mit anderen Prozessen und Pipelines für diese Zwecke bereitzustellen.

Kopieren Sie zum Bereitstellen Ihrer App die Artefakte in die Hostumgebung. Starten Sie anschließend die Apps, um Ihre Workflows auszuführen. Alternativ können Sie Ihre Artefakte mithilfe der Tools und Prozesse, die Sie bereits kennen und verwenden, in Bereitstellungspipelines integrieren. Auf diese Weise können Sie die Bereitstellung mit Ihren eigenen Tools durchführen, unabhängig vom Technologiestapel, den Sie für die Entwicklung verwenden.

Durch die Verwendung von Standardbuild- und -bereitstellungsoptionen können Sie sich unabhängig von der Infrastrukturbereitstellung auf die App-Entwicklung konzentrieren. So erhalten Sie ein allgemeineres Projektmodell, in dem Sie viele ähnliche oder identische Bereitstellungsoptionen wie für eine generische App anwenden können. Sie profitieren auch von einer konsistenteren Oberfläche, wenn Sie Bereitstellungspipelines für Ihre Apps erstellen und die erforderlichen Tests und Überprüfungen ausführen, bevor Sie in der Produktion veröffentlichen.

Leistung

Mit einer Standard-Logik-App können Sie mehrere Workflows in derselben einzelnen Logik-App-Ressource und demselben Einzelmandanten erstellen und ausführen. Bei dieser 1:n-Zuordnung nutzen diese Workflows Ressourcen wie Compute-, Verarbeitungs-, Speicher- und Netzwerkressourcen gemeinsam und bieten aufgrund ihrer Nähe eine bessere Leistung.

Die Standard-Logik-App-Ressource und die Azure Logic Apps-Runtime für Einzelmandanten bieten einen weiteren erheblichen Vorteil: Sie stellen die beliebteren verwalteten Connectors als integrierte Connectorvorgänge bereit. So können Sie etwa integrierte Connectorvorgänge für Azure Service Bus, Azure Event Hubs, SQL Server und andere nutzen. Die verwalteten Connectorversionen sind weiterhin verfügbar und funktionieren.

Wenn Sie die neuen integrierten Connectorvorgänge verwenden, erstellen Sie Verbindungen, die als integrierte Verbindungen oder Dienstanbieterverbindungen bezeichnet werden. Die entsprechenden verwalteten Verbindungen werden API-Verbindungen genannt. Diese werden separat als Azure-Ressourcen erstellt und ausgeführt, die Sie anschließend auch mithilfe von ARM-Vorlagen bereitstellen müssen. Integrierte Vorgänge und die zugehörigen Verbindungen werden lokal in demselben Prozess ausgeführt wie Ihre Workflows. Beide werden in der Azure Logic Apps-Runtime für den Einzelmandanten gehostet. Aufgrund der Nähe zu Ihren Workflows bieten integrierte Vorgänge und deren Verbindungen eine bessere Leistung. Diese Methode ist auch für Bereitstellungspipelines geeignet, da die Dienstanbieterverbindungen in dasselbe Buildartefakt gepackt werden.

Datenresidenz

Standard-Logik-App-Ressourcen werden in einer Azure Logic Apps-Instanz mit nur einem Mandanten gehostet, die Daten außerhalb der Region, in der Sie diese Logik-App-Ressourcen bereitstellen, weder speichert noch verarbeitet oder repliziert, was bedeutet, dass Daten in Ihren Workflows in derselben Region bleiben, in der Sie deren übergeordnete Ressourcen erstellen und bereitstellen.

Direkter Zugriff auf Ressourcen in virtuellen Azure-Netzwerken

Workflows, die in einer Azure Logic Apps-Instanz mit nur einem Mandanten ausgeführt werden, können direkt auf gesicherte Ressourcen wie virtuelle Computer (VMs), andere Dienste sowie Systeme, die sich in einem virtuellen Azure-Netzwerk befinden, zugreifen.

Bei einer Azure Logic Apps-Instanz mit nur einem Mandanten handelt es sich um eine dedizierte Instanz des Azure Logic Apps-Diensts, die dedizierte Ressourcen nutzen und getrennt von mehrinstanzenfähigen Azure Logic Apps-Instanzen ausgeführt werden. Das Ausführen von Workflows in einer dedizierten Instanz trägt dazu bei, mögliche Auswirkungen anderer Azure-Mandanten auf die Leistung von Apps zu verringern. Dies ist auch als „Noisy Neighbors“-Problem bekannt.

Azure Logic Apps mit nur einem Mandanten bieten außerdem die folgenden Vorteile:

  • Ihre eigenen statischen IP-Adressen, die von den statischen IP-Adressen gesondert sind, die von den Logik-Apps in mehrinstanzenfähigen Azure Logic Apps gemeinsam verwendet werden. Sie können auch eine einzelne öffentliche, statische und vorhersagbare ausgehende IP-Adresse für die Kommunikation mit Zielsystemen einrichten. Auf diese Weise müssen Sie nicht auf den Zielsystemen extra Firewallzugänge einrichten.

  • Höhere Grenzwerte für Ausführungsdauer, Speicheraufbewahrung, Durchsatz, Zeitlimits für HTTP-Anforderungen und -Antworten, Nachrichtengröße und benutzerdefinierte Connectoranforderungen. Weitere Informationen finden Sie unter Grenzwerte und Konfiguration für Azure Logic Apps.

Erstellen und Bereitstellen von Optionen

Zum Erstellen einer Logik-App-Ressource in der von Ihnen gewünschten Umgebung stehen Ihnen mehrere Optionen zur Verfügung, zum Beispiel:

Umgebung mit einem Mandanten

Option Ressourcen und Tools Weitere Informationen
Azure-Portal Standard-Logik-App Erstellen eines Standard-Logik-App-Beispielworkflows in Azure Logic Apps für einen einzelnen Mandanten – Microsoft Azure-Portal
Visual Studio Code Erweiterung Azure Logic Apps (Standard) Erstellen eines Standard-Logik-App-Beispielworkflows in Azure Logic Apps für einen einzelnen Mandanten – Visual Studio Code
Azure CLI Erweiterung „Logic Apps Azure CLI“ az logicapp
Azure Resource Manager - Local
- DevOps		 Azure Logic Apps-Instanz mit nur einem Mandanten
Logik-Apps mit Azure Arc-Unterstützung Logic Apps-Beispiel mit Azure Arc-Unterstützung - Was ist Logic Apps mit Azure Arc-Unterstützung?

- Erstellen und Bereitstellen von Logik-App-Workflows auf Basis eines einzelnen Mandanten mit Logic Apps mit Azure Arc-Unterstützung
Azure-REST-API Azure App Service-REST-API*

Hinweis: Die REST-API der Standard-Logik-App ist in der Azure App Service-REST-API enthalten.		 Erste Schritte mit der Azure-REST-API-Referenz

Mehrinstanzenfähige Umgebungen

Option Ressourcen und Tools Weitere Informationen
Azure-Portal Verbrauchs-Logik-App Schnellstart: Erstellen eines Beispiels für einen Verbrauchs-Logik-App-Workflow in Azure Logic Apps für mehrere Mandanten – Azure-Portal
Visual Studio Code Erweiterung Azure Logic Apps (Verbrauch) Schnellstart: Erstellen eines Beispiels für einen Verbrauchs-Logik-App-Workflow in Azure Logic Apps für mehrere Mandanten – Visual Studio Code
Azure CLI Erweiterung Logic Apps Azure CLI - Schnellstart: Erstellen und Verwalten von Verbrauchs-Logik-App-Workflows in Azure Logic Apps für mehrere Mandanten – Azure CLI

- az logic
Azure Resource Manager Erstellen einer ARM-Vorlage für Logik-App Schnellstart: Erstellen und Bereitstellen von Verbrauchs-Logik-App-Workflows in Azure Logic Apps für mehrere Mandanten –ARM-Vorlage
Azure PowerShell Modul „Az.LogicApp“ Erste Schritte mit Azure PowerShell
Azure-REST-API Azure Logic Apps-REST-API Erste Schritte mit der Azure-REST-API-Referenz

Trotz der Unterschiede bei der Entwicklung einer Logik-App-Ressource vom Typ Verbrauch und einer Ressource vom Typ Standard können Sie in Ihrem Azure-Abonnement auf alle von Ihnen bereitgestellten Logik-Apps zugreifen.

Im Azure-Portal werden beispielsweise auf der Seite Logik-Apps die beiden Logik-App-Ressourcen Verbrauch und Standard angezeigt. In Visual Studio Code werden bereitgestellte Logik-Apps unter Ihrem Azure-Abonnement angezeigt, aber Verbrauchs-Logik-Apps werden im Azure-Fenster unter der Erweiterung Azure Logic Apps (Verbrauch) angezeigt, während Standard-Logik-Apps im Abschnitt Ressourcen angezeigt werden.

Zustandsbehaftete und zustandslose Workflows

In einer Standard-Logik-App können Sie die folgenden Workflowtypen erstellen:

  • Zustandsbehaftet

    Erstellen Sie einen zustandsbehafteten Workflow, wenn Sie Daten von vorherigen Ereignissen beibehalten, überprüfen oder referenzieren müssen. Diese Workflows speichern alle Eingaben, Ausgabe und Zustände des Vorgangs im externen Speicher. Diese Informationen ermöglichen die detaillierte Überprüfung der Workflowausführung und des Verlaufs nach Abschluss jeder Ausführung. Zustandsbehaftete Workflows bieten hohe Resilienz, falls es zu Ausfällen kommen sollte. Nachdem Dienste und Systeme wiederhergestellt wurden, können Sie unterbrochene Ausführungen aus dem gespeicherten Zustand rekonstruieren und die Workflows bis zum Abschluss erneut ausführen. Zustandsbehaftete Workflows können wesentlich länger ausgeführt werden als zustandslose Workflows.

    Standardmäßig laufen zustandsbehaftete Workflows sowohl in mehrinstanzfähigen als auch in einzelinstanzfähigen Azure Logic Apps asynchron. Alle HTTP-basierten Aktionen folgen dem Standardmuster für asynchrone Operationen. Wenn eine HTTP-Aktion einen Aufruf oder eine Anforderung an einen Endpunkt, einen Dienst, das System oder die API sendet, gibt der Empfänger sofort eine 202 ACCEPTED-Antwort zurück. Dieser Code bestätigt, dass der Empfänger die Anforderung akzeptiert, aber die Verarbeitung noch nicht abgeschlossen hat. Die Antwort kann einen location Header enthalten, der den URI und eine Refresh-ID angibt, mit der Aufrufer den Status der asynchronen Anforderung abfragen oder überprüfen kann, bis der Empfänger die Verarbeitung beendet und eine "200 OK" Erfolgsmeldung oder eine andere Nicht-202-Antwort zurückgibt. Der Aufrufer muss jedoch nicht darauf warten, dass die Verarbeitung der Anforderung abgeschlossen wird, und kann mit der Ausführung der nächsten Aktion fortfahren. Weitere Informationen finden Sie unter Gegenüberstellung von synchronem und asynchronem Messaging.

  • Zustandslos

    Erstellen Sie einen zustandslosen Workflow, wenn Sie Daten von vorherigen Ereignissen nicht zur späteren Überprüfung in externem Speicher sichern, überprüfen oder referenzieren müssen, nachdem jede Ausführung beendet wurde und einer Überprüfung unterzogen werden kann. Diese Workflows speichern sämtliche Ein- und Ausgaben für jede Aktion und deren Zustände nur im Arbeitsspeicher und nicht im externen Speicher. Daher sind die Ausführungen zustandsloser Workflows in der Regel in höchstens 5 Minuten abgeschlossen, sie bieten eine höhere Leistung mit schnelleren Antwortzeiten, einen höheren Durchsatz und niedrigere Ausführungskosten, da die Ausführungsdetails und der Ausführungsverlauf nicht im externen Speicher gespeichert werden. Wenn es aber zu Ausfällen kommen sollte, werden unterbrochene Ausführungen nicht automatisch wiederhergestellt, sodass der Aufrufer unterbrochene Ausführungen manuell erneut übermitteln muss.

    Ein zustandsloser Workflow bietet die beste Leistung bei der Verarbeitung von Daten oder Inhalten, die insgesamt 64 KB nicht überschreiten, z. B. einer Datei. Größere Inhalte, z. B. mehrere große Anlagen, können die Leistung Ihres Workflows erheblich beeinträchtigen oder sogar dazu führen, dass Ihr Workflow aufgrund von Ausnahmen wegen nicht genügend Arbeitsspeicher abstürzt. Wenn Ihr Workflow möglicherweise größere Inhalte verarbeiten muss, verwenden Sie stattdessen einen zustandsbehafteten Workflow.

    Hinweis

    In zustandslosen Workflows können Sie nur Pushtrigger verwenden, für die Sie keinen Zeitplan für die Ausführung für Ihren Workflow angeben. Diese Webhook-basierten Trigger warten, bis ein Ereignis auftritt oder Daten verfügbar werden. Der Serientrigger ist beispielsweise nur für zustandsbehaftete Workflows verfügbar. Um Ihren Workflow zu starten, wählen Sie einen Pushtrigger aus, z. B. die Trigger „Anforderung“, „Event Hubs“ oder „Service Bus“. Weitere Informationen zu eingeschränkten, nicht verfügbaren oder nicht unterstützten Triggern, Aktionen und Connectors finden Sie unter Geänderte, eingeschränkte, nicht verfügbare oder nicht unterstützte Funktionen.

    Zustandslose Workflows laufen nur synchron ab. Sie verwenden also nicht das standardmäßige asynchrone Vorgangsmuster, das von zustandsabhängigen Workflows verwendet wird. Stattdessen fahren alle HTTP-basierten Aktionen, die eine „202 ACCEPTED“-Antwort zurückgeben, mit dem nächsten Schritt der Workflowausführung fort. Wenn die Antwort einen locationHeader enthält, wird ein zustandsloser Arbeitsablauf die angegebene URI nicht abfragen, um den Status zu überprüfen. Um dem Standardmuster für asynchrone Operationen zu folgen, verwenden Sie stattdessen einen zustandsabhängigen Workflow.

    Um das Debuggen zu vereinfachen, können Sie den Ausführungsverlauf für einen zustandslosen Workflow aktivieren und den Ausführungsverlauf wieder deaktivieren, wenn Sie fertig sind, da die Aktivierung die Leistung beeinträchtigt. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten in Visual Studio Code oder Erstellen von Workflows für Instanzen mit einem Mandanten im Azure-Portal.

Wichtig

Sie müssen sich für den Workflowtyp entscheiden, entweder zustandsbehaftet oder zustandslos, um zur Erstellungszeit zu implementieren. Änderungen am Workflowtyp nach der Erstellung führen zu Laufzeitfehlern.

Zusammenfassung der Unterschiede zwischen zustandsabhängigen und zustandslosen Workflows

Zustandsbehaftet Zustandslos
Speichert Laufverlauf, Eingaben und Ausgaben Speichert standardmäßig keine Laufhistorie, Eingaben oder Ausgaben
Verwaltete Verbindungsauslöser sind verfügbar und erlaubt Verwaltete Verbindungsauslöser sind nicht verfügbar oder nicht erlaubt
Unterstützt Chunking Keine Unterstützung für Chunking
Unterstützt asynchrone Operationen Keine Unterstützung für asynchrone Operationen
Standardmäßige maximale Laufzeit in der Hostkonfiguration bearbeiten Am besten geeignet für Arbeitsabläufe mit einer maximalen Dauer von unter 5 Minuten
Verarbeitet große Nachrichten Am besten geeignet für die Bearbeitung kleiner Nachrichtengrößen (unter 64 KB)

Unterschiede im Verhalten von geschachtelten zustandsbehafteten und geschachtelten zustandslosen Workflows

Sie können einen Workflow so erstellen, dass er aus anderen Workflows heraus, die in derselben Ressource vom Typ Standard-Logik-App enthalten sind, aufgerufen werden kann, indem Sie hierfür den Anforderungstrigger, den HTTP-Webhooktrigger oder Trigger für verwaltete Connectors vom Typ „ApiConnectionWebhook“ verwenden, die auch HTTPS-Anforderungen empfangen können.

In der folgenden Liste werden die Verhaltensmuster beschrieben, denen geschachtelte Workflows folgen können, nachdem ein übergeordneter Workflow einen untergeordneten Workflow aufgerufen hat:

  • Asynchrones Abrufmuster

    Der übergeordnete Workflow wartet nicht auf die Antwort des untergeordneten Workflows auf den anfänglichen Aufruf. Der übergeordnete Workflow überprüft jedoch fortwährend den Ausführungsverlauf des untergeordneten Workflows, bis dessen Ausführung abgeschlossen ist. Standardmäßig halten zustandsbehaftete Workflows dieses Muster ein, das sich ideal für untergeordnete Workflows mit langer Laufzeit eignet, die Anforderungstimeout-Limits überschreiten können.

  • Synchrones Muster („Fire and Forget“)

    Der untergeordnete Workflow bestätigt den Aufruf des übergeordneten Workflows, indem er sofort eine 202 ACCEPTED-Antwort zurückgibt. Der übergeordnete Workflow wartet jedoch nicht, bis der untergeordnete Workflow Ergebnisse zurückgibt. Stattdessen fährt der übergeordnete Workflow mit der nächsten Aktion im Workflow fort und empfängt die Ergebnisse, wenn die Ausführung des untergeordneten Workflows abgeschlossen wird. Untergeordnete zustandsbehaftete Workflows, die keine Antwortaktion enthalten, folgen immer dem synchronen Muster und stellen Ihnen einen Ausführungsverlauf zur Überprüfung bereit.

    Um dieses Verhalten zu aktivieren, legen Sie in der JSON-Definition des Workflows die operationOptions-Eigenschaft auf DisableAsyncPattern fest. Weitere Informationen finden Sie unter Trigger- und Aktionstypen: Optionen für Vorgänge.

  • Auslösen und Warten

    Zustandslose Workflows werden im Arbeitsspeicher ausgeführt. Wenn also ein übergeordneter Workflow einen untergeordneten zustandslosen Workflow aufruft, wartet der übergeordnete Workflow auf eine Antwort, mit der die Ergebnisse vom untergeordneten Workflow zurückgegeben werden. Dieses Muster funktioniert ähnlich wie die Verwendung des integrierten HTTP-Triggers oder der HTTP-Aktion, um einen untergeordneten Workflow aufzurufen. Untergeordnete zustandslose Workflows, die keine Antwortaktion enthalten, geben sofort eine 202 ACCEPTED-Antwort zurück, aber der übergeordnete Workflow wartet, bis der untergeordnete Workflow abgeschlossen ist, bevor er mit der nächsten Aktion fortfährt. Diese Verhalten gelten nur für untergeordnete zustandslose Workflows.

Die folgende Tabelle gibt das Verhalten des untergeordneten Workflows an, je nachdem, ob der übergeordnete und untergeordnete Workflow zustandsbehaftete, zustandslose oder gemischte Workflowtypen sind. Die Liste hinter der Tabelle

Übergeordneter Workflow Untergeordneter Workflow Untergeordnetes Verhalten
Zustandsbehaftet Zustandsbehaftet Asynchron oder synchron mit "operationOptions": "DisableAsyncPattern"-Einstellung
Zustandsbehaftet Zustandslos Auslösen und Warten
Zustandslos Zustandsbehaftet Synchron
Zustandslos Zustandslos Auslösen und Warten

Weitere Funktionen des Einzelmandantenmodells

Das Einzelmandantenmodell und die Standard-Logik-App enthalten viele aktuelle und neue Funktionen, zum Beispiel:

  • Erstellen von Logik-Apps und deren Workflows mit mehr als 100 verwalteten Connectors für SaaS- (Software-as-a-Service) und PaaS-Apps (Platform-as-a-Service) und -Dienste sowie Connectors für lokale Systeme

    • Weitere verwaltete Connectors sind jetzt als integrierte Connectors in Standardworkflows verfügbar. Die integrierten Versionen werden nativ in der Runtime für Azure Logic Apps-Instanzen mit einem einzelnen Mandanten ausgeführt. Einige integrierte Connectors werden informell auch als Dienstanbieterconnectors bezeichnet. Eine Liste finden Sie unter Integrierte Connectors in „Verbrauch“ und „Standard“.

    • Sie können Ihre eigenen benutzerdefinierten, integrierten Connectors für jeden benötigten Dienst erstellen, indem Sie das Erweiterbarkeitsframework für Azure Logic Apps-Instanzen mit einem einzelnen Mandanten verwenden. Ähnlich wie integrierte Connectors wie Azure Service Bus und SQL Server bieten benutzerdefinierte integrierte Connectors einen höheren Durchsatz, niedrige Wartezeiten und lokale Konnektivität, da sie im selben Prozess wie die Runtime mit einzelnem Mandanten ausgeführt werden. Benutzerdefinierte integrierte Connectors entsprechen jedoch nicht benutzerdefinierten verwalteten Connectors, die derzeit nicht unterstützt werden. Weitere Informationen finden Sie in der Übersicht benutzerdefinierter Connectors und in Erstellen benutzerdefinierter, integrierter Connectors für Logik-Apps „Standard“ in Azure Logic Apps mit einem einzelnen Mandanten.

    • Sie können die folgenden Aktionen für Liquid- und XML-Vorgänge ohne Integrationskonto verwenden. Dazu gehören die folgenden Aktionen:

      • XML: Transformieren von XML undXML-Überprüfung

      • Liquid: Json in JSON transformieren, JSON in TEXT transformieren, XML in JSON transformieren und XML in Text transformieren

      Hinweis

      Um diese Aktionen in Standardworkflows verwenden zu können, benötigen Sie Liquid-Zuordnungen, XML-Zuordnungen oder XML-Schemas. Sie können diese Artefakte im Azure-Portal über das Ressourcenmenü Ihrer Logik-App unter Artifacts hochladen, das die Abschnitte Schemas und Karten enthält. Sie können diese Artefakte auch dem Ordner Artifacts ihres Visual Studio Code-Projekts hinzufügen, indem Sie die entsprechenden Ordner Karten und Schemas verwenden. Sie können diese Artefakte dann in mehreren Workflows innerhalb derselben Logik-App verwenden.

    • Standard-Logik-App-Workflows können überall ausgeführt werden, da Azure Logic Apps SAS-Verbindungszeichenfolgen (Shared Access Signature) generiert, die diese Logic Apps zum Senden von Anforderungen an den Cloudverbindungs-Laufzeitendpunkt verwenden können. Azure Logic Apps speichert diese Verbindungszeichenfolgen zusammen mit anderen Anwendungseinstellungen, sodass Sie diese Werte bei einer Bereitstellung in Azure problemlos in Azure Key Vault speichern können.

    • Standard-Logik-App-Workflows unterstützen die gleichzeitige Aktivierung der systemseitig zugewiesenen verwalteten Identität und mehrerer benutzerseitig zugewiesener verwalteter Identitäten , obwohl Sie immer nur eine Identität auswählen können. Obwohl integrierte dienstanbieterbasierte Connectors die Verwendung der systemseitig zugewiesenen Identität unterstützen, unterstützen die meisten derzeit die Auswahl von benutzerseitig zugewiesenen verwalteten Identitäten für die Authentifizierung nicht, mit Ausnahme von SQL Server und den HTTP-Connectors.

      Hinweis

      Standardmäßig ist die systemseitig zugewiesene Identität bereits für die Authentifizierung von Verbindungen zur Laufzeit aktiviert. Diese Identität unterscheidet sich von den Anmeldeinformationen für die Authentifizierung oder der Verbindungszeichenfolge, die Sie verwenden, wenn Sie eine Verbindung herstellen. Wenn Sie diese Identität deaktivieren, funktionieren Verbindungen zur Laufzeit nicht. Wählen Sie zum Anzeigen dieser Einstellung im Menü Ihrer Logik-App unter Einstellungen die Option Identität aus.

  • Sie können Ihre Logik-Apps und die zugehörigen Workflows in der Visual Studio Code-Entwicklungsumgebung lokal ausführen, testen und debuggen.

    Bevor Sie Ihre Logik-App ausführen und testen, können Sie das Debuggen vereinfachen, indem Sie in der Datei workflow.json für einen Workflow Breakpoints hinzufügen und verwenden. Breakpoints werden derzeit jedoch nur für Aktionen unterstützt, nicht für Trigger. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten in Visual Studio Code.

  • Veröffentlichen Sie Ihre Logik-Apps und die zugehörigen Workflows direkt aus Visual Studio Code, oder stellen Sie sie in verschiedenen Hostumgebungen bereit, wie z. B. Azure und durch Azure Arc aktivierte Logic Apps.

  • Aktivieren Sie die Funktionen zur Diagnoseprotokollierung und Ablaufverfolgung für Ihre Logik-App, indem Sie Application Insights verwenden, sofern dies von Ihrem Azure-Abonnement und den Einstellungen der Logik-App unterstützt wird.

  • Der Premium-Tarif für Azure Functions bietet Zugriff auf Netzwerkfunktionen wie das Herstellen einer privaten Verbindung zu virtuellen Azure-Netzwerken und das Integrieren dieser Netzwerke. Diese Funktionen ähneln den Funktionen in Azure Functions für das Erstellen und Bereitstellen Ihrer Logik-Apps. Weitere Informationen finden Sie in der folgenden Dokumentation:

  • Generieren Sie Zugriffsschlüssel für verwaltete Verbindungen erneut, die von einzelnen Workflows in einer Standard-Logik-App verwendet werden. Führen Sie für diese Aufgabe dieselben Schritte wie für eine Verbrauchs-Logik-App aus, aber auf Workflowebene, nicht auf der Logik-App-Ressourcenebene.

Integrierte Connectors für „Standard“

Ein Standardworkflow kann viele derselben integrierten Connectors wie ein Verbrauchsworkflow verwenden, aber nicht alle. Umgekehrt verfügt ein Standardworkflow über viele integrierte Connectors, die in einem Verbrauchsworkflow nicht verfügbar sind.

Beispielsweise verfügt ein Standardworkflow sowohl über verwaltete Connectors als auch über integrierte Connectors für Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server und andere. Obwohl ein Verbrauchsworkflow nicht über dieselben integrierten Connectorversionen verfügt, sind andere integrierte Connectors wie Azure API Management und Azure App Services verfügbar.

In Azure Logic Apps-Instanzen mit einem einzelnen Mandanten werden integrierte Connectors mit bestimmten Attributen informell als Dienstanbieter bezeichnet. Einige integrierte Connectors unterstützen nur eine einzige Möglichkeit, eine Verbindung mit dem zugrunde liegenden Dienst zu authentifizieren. Andere integrierte Connectors bieten mehrere Optionen wie die Verwendung von Verbindungszeichenfolgen, Microsoft Entra ID oder verwalteten Identitäten. Alle integrierten Connectors werden im selben Prozess wie die neu entwickelte Azure Logic Apps-Runtime ausgeführt. Weitere Informationen finden Sie in der Liste integrierter Connectors für Logik-App-Standardworkflows.

Wichtig

Stellen Sie sicher, dass Sie alle auf Dienstanbietern basierenden Trigger korrekt einrichten und testen, um den erfolgreichen Vorgang zu bestätigen. Ein fehlgeschlagener auf Dienstanbietern basierender Trigger kann zu einer unnötigen Skalierung führen, was Ihre Abrechnungskosten drastisch erhöhen kann. Ein häufiger Fehler ist z.B. das Festlegen eines Triggers, ohne Ihrer Logik-Anwendung die Erlaubnis oder den Zugriff auf das Ziel zu geben, wie z. B. eine Service Bus-Warteschlange, einen Azure Storage Blob-Container usw. Stellen Sie außerdem sicher, dass Sie solche Trigger jederzeit überwachen, damit Sie eventuelle Probleme sofort erkennen und beheben können.

Geänderte, eingeschränkte, nicht verfügbare oder nicht unterstützte Funktionen

Für den Standard-Logik-App-Workflow haben sich die folgenden Funktionen geändert oder sind zurzeit eingeschränkt, nicht verfügbar oder werden nicht unterstützt:

  • Trigger und Aktionen: Integrierte Trigger und Aktionen laufen nativ in Azure Logic Apps, während verwaltete Connectors mithilfe gemeinsam genutzter Ressourcen in Azure gehostet und ausgeführt werden. Für Standardworkflows sind einige integrierte Auslöser und Aktionen zurzeit nicht verfügbar, z. B. Gleitendes Fenster (Sliding Window), Azure App Service und Azure API Management. Um einen zustandsbehafteten oder zustandslosen Workflow zu starten, verwenden Sie einen integrierten Trigger wie „Anforderung“, „Event Hubs“ oder „Service Bus“. Der Wiederholungstrigger ist für zustandsbehaftete Workflows verfügbar, aber nicht für zustandslose Workflows. Im Designer werden integrierte Trigger und Aktionen mit der Bezeichnung In-App angezeigt, während verwaltete Connectortrigger und -aktionen mit der Bezeichnung Freigegeben angezeigt werden.

    Zustandslose Workflows können nur Push-Trigger verwenden, für die Sie keinen Zeitplan für die Ausführung für Ihren Workflow angeben. Diese Webhook-basierten Trigger warten, bis ein Ereignis auftritt oder Daten verfügbar werden. Der Serientrigger ist beispielsweise nur für zustandsbehaftete Workflows verfügbar. Um Ihren Workflow zu starten, wählen Sie einen Pushtrigger aus, z. B. die Trigger „Anforderung“, „Event Hubs“ oder „Service Bus“. Obwohl Sie verwaltete Connectors für zustandslose Workflows aktivieren können, zeigt der Connectorkatalog keine Abruf-Trigger für verwaltete Connectors, die Sie hinzufügen können.

    Hinweis

    Damit webhookbasierte Trigger und Aktionen lokal in Visual Studio Code ausgeführt werden können, sind zusätzliche Einrichtungsschritte erforderlich. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten in Visual Studio Code.

    • Die folgenden Trigger und Aktionen wurden entweder geändert, sind zurzeit eingeschränkt oder nicht verfügbar oder werden nicht unterstützt:

      • Die integrierte Aktion Azure Functions: Azure-Funktion auswählen heißt nun Azure Functions-Vorgänge: Azure-Funktion aufrufen. Diese Aktion funktioniert derzeit nur für Funktionen, die über die Vorlage für HTTP-Trigger erstellt werden.

        Sie können im Azure-Portal eine HTTP-Triggerfunktion auswählen, auf die Sie Zugriff haben, indem Sie über die Benutzeroberfläche eine Verbindung erstellen. Wenn Sie die JSON-Definition der Funktionsaktion in der Codeansicht oder der Datei workflow.json mithilfe von Visual Studio Code überprüfen, verweist die Aktion über einen connectionName-Verweis auf die Funktion. Diese Version abstrahiert die Informationen der Funktion als Verbindung, die Sie in der Datei connections.json des Projekts Ihrer Logik-App finden, die nach dem Erstellen einer Verbindung in Visual Studio Code verfügbar ist.

        Hinweis

        Im Einzelmandantenmodell unterstützt die Funktionsaktion nur die Authentifizierung über Abfragezeichenfolgen. Azure Logic Apps ruft den Standardschlüssel beim Herstellen der Verbindung aus der Funktion ab, speichert ihn in den Einstellungen Ihrer App und verwendet ihn beim Aufrufen der Funktion für die Authentifizierung.

        Wie im mehrinstanzenfähigen Modell gilt auch hier: Wenn Sie diesen Schlüssel erneuern (z. B. über die Azure Functions-Benutzeroberfläche im Portal), funktioniert die Funktionsaktion aufgrund eines ungültigen Schlüssels nicht mehr. Um dieses Problem zu beheben, müssen Sie die Verbindung mit der Funktion, die Sie aufrufen möchten, neu erstellen oder die App-Einstellungen mit dem neuen Schlüssel aktualisieren.

      • Der Name der integrierten Aktion Inline-Code wird in Inlinecodevorgänge geändert, es ist kein Integrationskonto mehr erforderlich, und die Grenzwerte wurden aktualisiert.

      • Die integrierte Aktion Azure Logic Apps: Logik-App-Workflow auswählen heißt nun Workflowvorgänge: Workflow in dieser Workflow-App aufrufen.

      • Der Gmail-Connector wird derzeit nicht unterstützt.

      • Benutzerdefinierte verwaltete Connectors werden derzeit nicht unterstützt. Mit Visual Studio Code können Sie jedoch benutzerdefinierte integrierte Vorgänge erstellen. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten in Visual Studio Code.

      • Ein standardmäßiger Logik-App-Workflow kann nur einen Trigger haben und unterstützt nicht mehrere Trigger.

  • Authentifizierung: Die folgenden Authentifizierungstypen sind derzeit für Standardworkflows nicht verfügbar:

    • Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) für eingehende Aufrufe an anforderungsbasierte Trigger, z. B. Anforderungs-Trigger und HTTP-Webhook-Trigger.

    • Authentifizierung für verwaltete Identitäten: Unterstützung für systemseitig zugewiesene wie auch benutzerseitig zugewiesene verwaltete Identitäten ist verfügbar. Standardmäßig wird die systemseitig zugewiesene verwaltete Identität automatisch aktiviert. Derzeit unterstützen jedoch die meisten integrierten, auf Dienstanbietern basierten Connectors die Auswahl benutzerseitig zugewiesener verwalteter Identitäten für die Authentifizierung nicht.

  • XML-Transformation: Derzeit wird nur XSLT 1.0 unterstützt.

  • Breakpoints für das Debuggen in Visual Studio Code: Sie können zwar in der Datei workflow.json Breakpoints für einen Workflow hinzufügen und verwenden, aber diese Breakpoints werden derzeit nur für Aktionen unterstützt, nicht für Trigger. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten in Visual Studio Code.

  • Trigger- und Ausführungsverlauf: Für eine Standard-Logik-App werden der Trigger- und Ausführungsverlauf im Azure-Portal auf Workflowebene angezeigt, nicht auf Ebene der Logik-App-Ressource. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten im Azure-Portal.

  • Sichern und Wiederherstellen für den Workflowausführungsverlauf: Standard-Logik-Apps unterstützen die Sicherung und Wiederherstellung für den Workflowausführungsverlauf derzeit nicht.

  • Terraform-Vorlagen: Sie können diese Vorlagen nicht mit einer Standard-Logik-App-Ressource für die vollständige Infrastrukturbereitstellung verwenden. Weitere Informationen finden Sie unter Was ist Terraform in Azure?.

  • Azure API Management: Aktuell können Sie eine Standard-Logik-App-Ressource nicht in Azure API Management importieren. Sie können jedoch eine Verbrauchs-Logik-App-Ressource importieren.

Strenge Berechtigungen für Netzwerk- und Firewalldatenverkehr

Wenn in Ihrer Umgebung strenge Netzwerkanforderungen gelten oder Firewalls vorhanden sind, die den Datenverkehr einschränken, müssen Sie den Zugriff für alle Trigger- oder Aktionsverbindungen in Ihren Workflows zulassen. Sie können optional den Datenverkehr von Diensttags zulassen und dieselbe Ebene von Einschränkungen oder Richtlinien wie Azure App Service verwenden. Sie müssen außerdem die vollqualifizierten Domänennamen (FQDNs) für Ihre Verbindungen finden und verwenden. Weitere Informationen finden Sie in den entsprechenden Abschnitten in der folgenden Dokumentation:

Nächste Schritte

Teilen Sie uns gerne Ihre Erfahrungen mit den Azure Logic Apps-Instanzen mit einem Mandanten mit.