Vergleich zwischen Umgebungen mit einem Mandanten und mehreren Mandanten bzw. Integrationsdienstumgebung für Azure Logic Apps

Ressourcentyp Vorteile Ressourcenfreigabe und -nutzung Preis- und Abrechnungsmodell Verwaltung von Grenzwerten
Logik-App (Verbrauch)

Hostumgebung: Mehrere Mandanten in Azure Logic Apps

– Einfacher Einstieg

– Nutzungsabhängige Abrechnung

– Vollständig verwaltet

Eine Logik-App kann nur einen Workflow haben.

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

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.
Logik-App (Verbrauch)

Hostumgebung:
Integrationsdienstumgebung (Integration Service Environment, ISE)

– Unternehmensweite Skalierung für große Workloads

– Mehr als 20 ISE-spezifische Connectors, die eine direkte Verbindung mit virtuellen Netzwerken herstellen

– Vorhersagbare Preise mit integrierter nutzungs- und kundengesteuerter Skalierung

– Daten verbleiben in derselben Region, in der Sie die ISE bereitstellen.

Eine Logik-App kann nur einen Workflow haben.

Logik-Apps in derselben Umgebung nutzen dieselben Ressourcen für die Verarbeitung (Compute), den Speicher, das Netzwerk usw.

ISE (fest) 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.
Logik-App (Standard)

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?.

– Ausführen mithilfe der Azure Logic Apps-Runtime für den Einzelmandanten Bereitstellungsslots werden derzeit nicht unterstützt.

– Mehr integrierte Connectors für einen höheren Durchsatz und geringere Kosten für eine skalierbare Lösung

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

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

– Erstellen von eigenen integrierten Connectors

– Daten verbleiben in derselben Region, in der Sie die Logik-Apps bereitstellen.

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.

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.

Logik-App (Standard)

Hostumgebung:
App Service-Umgebung v3 (ASEv3)

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

– Daten verbleiben in derselben Region, in der Sie die Logik-Apps bereitstellen.

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

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.

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.

Ressourcentyp „Logik-App (Standard)“

Der Ressourcentyp Logik-App (Standard) wird von der neu gestalteten Runtime für Azure Logic Apps-Instanzen mit einem 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 erstellen, bereitstellen und ausführen.

Mit dem Ressourcentyp „Standard“ wird eine Ressourcenstruktur zum Hosten mehrerer Workflows eingeführt. Dies ist vergleichbar mit einer Azure Functions-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 stellt einen Unterschied zum Ressourcentyp Logik-App (Verbrauch) dar, bei dem zwischen einer 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 Logik-Apps mit dem Ressourcentyp Logik-App (Standard) erstellen, können Sie Ihre Workflows in anderen Umgebungen, wie z. B. Azure App Service-Umgebung v3 bereitstellen und ausführen. Wenn Sie Visual Studio Code mit der Erweiterung Azure Logic Apps (Standard) verwenden, können Sie Ihre Workflows 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, 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?

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. Zudem basiert das mehrinstanzenfähige Modell für die automatisierte Bereitstellung des Ressourcentyps Logik-App (Verbrauch) vollständig auf ARM-Vorlagen (Azure Resource Manager), mit denen die Ressourcenbereitstellung für Apps und die Infrastruktur zusammengeführt und verarbeitet wird.

Mit dem Ressourcentyp Logik-App (Standard) 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 Workflows als Teil Ihrer Logik-App in einem Paket 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. Außerdem profitieren Sie von einer konsistenteren Umgebung zum Erstellen von Bereitstellungspipelines für Ihre App-Projekte und zum Ausführen der erforderlichen Tests und Überprüfungen vor der Veröffentlichung in der Produktion.

Leistung

Mit dem Ressourcentyp Logik-App (Standard) können Sie mehrere Workflows in derselben Logik-App und demselben Mandanten 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.

Der Ressourcentyp Logik-App (Standard) und die Azure Logic Apps-Runtime für Einzelmandanten bieten einen weiteren erheblichen Vorteil: Sie stellen gängige verwaltete Connectors als integrierte Vorgänge bereit. So stehen Ihnen etwa die folgenden integrierten Vorgänge zur Verfügung: Azure Service Bus, Azure Event Hubs, SQL usw. Die verwalteten Connectorversionen sind weiterhin verfügbar und funktionieren.

Wenn Sie die neuen integrierten Vorgä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

Logik-App-Ressourcen, die mit dem Ressourcentyp Logik-App (Standard) erstellt wurden, 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, nicht speichert, verarbeitet oder repliziert, was bedeutet, dass Daten in Ihren Logik-App-Workflows in derselben Region bleiben, in der Sie deren übergeordneten Ressourcen erstellen und bereitstellen.

Erstellen und Bereitstellen von Optionen

Zum Erstellen einer Logik-App in der von Ihnen gewünschten Umgebung stehen Ihnen beispielsweise folgende Optionen zur Verfügung:

Umgebung mit einem Mandanten

Option Ressourcen und Tools Weitere Informationen
Azure-Portal Ressourcentyp Logik-App (Standard) Erstellen von Integrationsworkflows für Azure Logic Apps-Instanzen mit einem Mandanten – Azure-Portal
Visual Studio Code Erweiterung Azure Logic Apps (Standard) Erstellen von Integrationsworkflows für Azure Logic Apps-Instanzen mit einem Mandanten – Visual Studio Code
Azure CLI Erweiterung „Logic Apps Azure CLI“ Noch nicht verfügbar

Umgebungen mit mehreren Mandanten

Option Ressourcen und Tools Weitere Informationen
Azure-Portal Ressourcentyp Logik-App (Verbrauch) Schnellstart: Erstellen von Integrationsworkflows in Azure Logic Apps-Instanzen mit mehreren Mandanten – Azure-Portal
Visual Studio Code Erweiterung Azure Logic Apps (Verbrauch) Schnellstart: Erstellen von Integrationsworkflows in Azure Logic Apps-Instanzen mit mehreren Mandanten – Visual Studio Code
Azure CLI Erweiterung Logic Apps Azure CLI - -

- -

Azure Resource Manager Erstellen einer ARM-Vorlage für Logik-App Schnellstart: Erstellen und Bereitstellen von Integrationsworkflows in Azure Logic Apps-Instanzen mit mehreren 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

Integrationsdienstumgebung

Option Ressourcen und Tools Weitere Informationen
Azure-Portal Ressourcentyp Logik-App (Verbrauch) mit vorhandener ISE-Ressource Identisch mit Schnellstart: Erstellen von Integrationsworkflows in Azure Logic Apps-Instanzen mit mehreren Mandanten – Azure-Portal, aber wählen Sie eine ISE und keine mehrinstanzenfähige Region aus.

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 Ressourcentypen Verbrauch und Standard angezeigt. In Visual Studio Code werden bereitgestellte Logik-Apps in Ihrem Azure-Abonnement angezeigt. Diese werden jedoch nach der von Ihnen verwendeten Erweiterung gruppiert in Azure: Logik-Apps (Verbrauch) und Azure: Logik-Apps (Standard) .

Zustandsbehaftete und zustandslose Workflows

Mit dem Ressourcentyp Logik-App (Standard) können Sie die folgenden Workflowtypen in derselben Logik-App erstellen:

  • Zustandsbehaftet

    Erstellen Sie einen zustandsbehafteten Workflow, wenn Sie Daten von vorherigen Ereignissen beibehalten, überprüfen oder referenzieren müssen. Diese Workflows behalten bei und übertragen sämtliche Ein- und Ausgaben für jede Aktion und deren Zustände im externen Speicher, sodass die Ausführungsdetails und der Ausführungsverlauf nach Abschluss der jeweiligen Ausführung überprüft werden können. 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 multimandantenfähigen als auch in einzelmandantenfähigen Azure Logic Apps asynchron. Alle HTTP-basierten Aktionen folgen dem Standardmuster für asynchrone Operationen. Laut diesem Muster gibt der Empfänger sofort eine 202 ACCEPTED-Antwort zurück, wenn eine HTTP-Aktion einen Endpunkt, einen Dienst, das System oder die API aufruft oder eine Anforderung an ebendiese sendet. Dieser Code bestätigt, dass der Empfänger die Anforderung akzeptiert, aber die Verarbeitung noch nicht abgeschlossen hat. Die Antwort kann einen locationHeader enthalten, der den URI und eine Refresh-ID angibt, die die aufrufende Person verwenden kann, um den Status der asynchronen Anfrage abzufragen oder zu überprüfen, bis der Empfänger die Verarbeitung beendet und eine location-Erfolgsantwort 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 kürzer (in der Regel weniger als 5 Minuten), 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.

    Wichtig

    Ein zustandsloser Workflow bietet die beste Leistung bei der Verarbeitung von Daten oder Inhalten, z. B. einer Datei, die insgesamt 64 KB nicht überschreitet. 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.

    Zustandslose Workflows laufen nur synchron ab. Sie verwenden also nicht das standardmäßige asynchrone Operationsmuster, 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 Workflow-Ausfü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.

    Hinweis

    Zustandslose Workflows unterstützen derzeit nur Aktionen für in Azure bereitgestellte verwaltete Connectors, keine Aktionen für Trigger. Um Ihren Workflow zu starten, wählen Sie einen der Trigger für integrierte Anforderungen, Event Hubs oder Service Bus aus. Diese Trigger werden nativ in der Azure Logic Apps-Runtime ausgeführt. 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.

Zusammenfassung der Unterschiede zwischen zustandsabhängigen und zustandslosen Workflows

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

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 Logik-App (Standard) enthalten sind, aufrufbar ist. Verwenden Sie hierfür den Anforderungstrigger, den HTTP-Webhooktrigger oder Trigger für verwaltete Connectors vom Typ ApiConnectionWebhook, die HTTPS-Anforderungen empfangen können.

Im Folgenden sind die Verhaltensmuster geschachtelter Workflows aufgeführt, nachdem ein übergeordneter Workflow einen untergeordneten Workflow aufruft:

  • Asynchrones Abrufmuster

    Der übergeordnete Workflow wartet nicht auf eine Antwort auf seinen ursprünglichen Aufruf, sondern überprüft fortlaufend den Ausführungsverlauf Verlauf des untergeordneten Workflows, bis dessen Ausführung beendet wird. 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 durch sofortige Rückgabe einer 202 ACCEPTED-Antwort, und der übergeordnete Workflow fährt mit der nächsten Aktion fort, ohne auf die Ergebnisse des untergeordneten Workflows zu warten. Stattdessen empfängt der übergeordnete Workflow die Ergebnisse, wenn der untergeordnete Workflow abgeschlossen ist. Untergeordnete zustandsbehaftete Workflows, die keine Antwortaktion enthalten, folgen immer dem synchronen Muster. Für untergeordnete zustandsbehaftete Workflows steht Ihnen der Ausführungsverlauf zur Prüfung zur Verfügung.

    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

    Bei einem untergeordneten zustandslosen Workflow 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.

Diese Tabelle gibt das Verhalten des untergeordneten Workflows an, je nachdem, ob der übergeordnete und untergeordnete Workflow zustandsbehaftete, zustandslose oder gemischte Workflowtypen sind:

Ü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 der Ressourcentyp Logik-App (Standard) enthalten viele aktuelle und neue Funktionen, wie beispielsweise:

  • Erstellen von Logik-Apps und deren Workflows mit mehr als 400 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 Vorgänge verfügbar und werden ähnlich wie andere integrierte Vorgänge ausgeführt, wie z. B. Azure Functions. Integrierte Vorgänge werden nativ in der Runtime für Azure Logic Apps-Instanzen mit einem Mandanten ausgeführt. Zu den neuen integrierten Operationen gehören zum Beispiel Azure Service Bus, Azure Event Hubs, SQL Server, MQ, DB2 und IBM Host File.

      Hinweis

      Für die integrierte SQL Server-Version kann nur die Aktion Abfrage ausführen direkt eine Verbindung mit den virtuellen Azure-Netzwerken herstellen, ohne dass das lokale Datengateway erforderlich ist.

    • Sie können Ihre eigenen integrierten Connectors für jeden benötigten Dienst erstellen, indem Sie das Erweiterbarkeitsframework für Azure Logic Apps-Instanzen mit einem Mandanten verwenden. Ähnlich wie integrierte Vorgänge wie Azure Service Bus und SQL Server, jedoch anders als benutzerdefinierte verwaltete Connectors, die derzeit nicht unterstützt werden, bieten benutzerdefinierte integrierte Connectors einen höheren Durchsatz, niedrige Wartezeiten und lokale Konnektivität, da sie nativ im selben Prozess wie die Runtime für die Instanz mit einem Mandanten ausgeführt werden.

      Die Erstellungsfunktion ist derzeit nur in Visual Studio Code verfügbar, aber nicht standardmäßig aktiviert. Um diese Connectors zu erstellen, konvertieren Sie Ihr Projekt von erweiterungspaketbasiert (Node.js) in NuGet-Paketbasiert (.NET). Weitere Informationen finden Sie unter Azure Logic Apps Running Anywhere: Built-in connector extensibility (Azure Logic Apps läuft überall: Erweiterbarkeit integrierter Connectors).

    • 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 einzelmandantenbasierten Azure Logic Apps (Standard) 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-Ressource verwenden.

    • Logic App (Standard) -Ressourcen 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 Cloud-Verbindungslaufzeitendpunkt 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.

      Hinweis

      Standardmäßig ist für den Ressourcentyp Logic App (Standard) die systemseitig zugewiesene verwaltete Identität automatisch aktiviert, um Verbindungen zur Laufzeit zu authentifizieren. 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.

      Die benutzerseitig zugewiesene verwaltete Identität ist derzeit für den Ressourcentyp Logic App (Standard) nicht verfügbar.

  • 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 Ressource vom Typ Logik-App (Standard) verwendet werden. Führen Sie für diese Aufgabe die gleichen Schritte wie für die Ressource vom Typ Logik-App (Verbrauch) aus, jedoch auf der individuellen Workflowebene und nicht auf der Ebene der Logik-App-Ressource.

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

Für Ressourcen vom Typ Logik-App (Standard) wurden die folgenden Funktionen geändert, sind zurzeit eingeschränkt oder nicht verfügbar oder werden nicht unterstützt:

  • Auslöser und Aktionen: Integrierte Auslöser und Aktionen laufen direkt in Azure Logic Apps, während verwaltete Konnektoren in Azure gehostet und ausgeführt werden. Einige integrierte Auslöser und Aktionen sind nicht verfügbar, z. B. Sliding Window, Batch, Azure App Services und Azure API Management. Starten Sie einen zustandsbehafteten oder zustandslosen Workflow mithilfe der integrierten Trigger „Wiederholung“, „Anforderung“, „HTTP“, „HTTP-Webhook“, „Event Hubs“ oder „Service Bus“. Im Designer werden integrierte Trigger und Aktionen auf der Registerkarte Integriert angezeigt.

    Für zustandsbehaftete Workflows werden Trigger und Aktionen für verwaltete Connectors auf der Registerkarte Azure angezeigt, mit Ausnahme der unten aufgeführten nicht verfügbaren Vorgänge. Bei zustandslosen Workflows wird die Registerkarte Azure bei der Auswahl eines Triggers nicht angezeigt. Sie können nur Aktionen für verwaltete Connectors auswählen, keine Trigger. Obwohl Sie in Azure gehostete, verwaltete Connectors für zustandslose Workflows aktivieren können, werden im Designer keine Trigger für verwaltete Connectors angezeigt, 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.

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

      • Lokale Datengatewaytrigger sind nicht verfügbar, aber Gatewayaktionen sind verfügbar.

      • 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 -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.

      • Einige Auslöser und Aktionen für Integrationskonten sind nicht verfügbar, z. B. die AS2 (V2)-Aktionen und RosettaNet-Aktionen.

      • 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.

  • Authentifizierung: Die folgenden Authentifizierungstypen sind derzeit für den Ressourcentyp Logic App (Standard) nicht verfügbar:

    • Azure Active Directory Open Authentication (Azure AD OAuth) für eingehende Anrufe an anfragebasierte Auslöser, wie den Anfrageauslöser und den HTTP-Webhook-Auslöser.

    • Dem Benutzer zugewiesene verwaltete Identität. Derzeit ist nur die vom System zugewiesene verwaltete Identität verfügbar und automatisch aktiviert.

  • XML-Transformation: Unterstützung für die Referenzierung von Zusammenstellungen aus Zuordnungen ist derzeit nicht verfügbar. Außerdem wird derzeit 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 den Ressourcentyp Logik-App (Standard) werden der Trigger- und der Ausführungsverlauf im Azure-Portal auf Workflowebene angezeigt, jedoch nicht auf der Ebene der Logik-App. Weitere Informationen finden Sie unter Erstellen von Workflows für Instanzen mit einem Mandanten im Azure-Portal.

  • Zoomsteuerelement: Das Zoomsteuerelement ist im Designer derzeit nicht verfügbar.

  • Bereitstellungsziele: Sie können den Ressourcentyp Logik-App (Standard) weder in einer Integrationsdienstumgebung (ISE) noch in Azure-Bereitstellungsslots bereitstellen.

  • Azure API Management: Sie können den Ressourcentyp Logik-App (Standard) derzeit nicht in Azure API Management importieren. Sie können jedoch den Ressourcentyp Logik-App (Verbrauch) 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 Logik-App-Workflows zulassen. Informationen zum Auffinden der vollqualifizierten Domänennamen (FQDNs) für diese Verbindungen finden Sie in den entsprechenden Abschnitten in den folgenden Themen:

Nächste Schritte

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

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. Verwenden Sie zum Erstellen einer Logik-App den Ressourcentyp Logik-App (Verbrauch) oder Logik-App (Standard) . Der Ressourcentyp „Verbrauch“ kann in einer Azure Logic Apps-Umgebung mit mehreren Mandanten oder einer Integrationsdienstumgebung ausgeführt werden, der Ressourcentyp „Standard“ in einer Azure Logic Apps-Einzelmandantenumgebung.

Bevor Sie den Ressourcentyp auswählen, lesen Sie diesen Artikel, um sich über die Unterschiede zwischen den Ressourcentypen und Dienstumgebungen zu informieren. Anschließend können Sie basierend auf den Anforderungen Ihres Szenarios, den Lösungsanforderungen und der Umgebung, in der Sie Ihre Workflows bereitstellen, hosten und ausführen möchten, entscheiden, welchen Typ Sie verwenden möchten.

Falls Sie noch nicht mit Azure Logic Apps vertraut sind, finden Sie weitere Informationen in den folgenden Artikeln:

Ressourcentypen und Umgebungen

Wählen Sie basierend auf Ihrem Szenario, den Lösungsanforderungen, den gewünschten Funktionen sowie der Umgebung, in der Ihre Workflows ausgeführt werden sollen, den Logik-App-Ressourcentyp aus, um Logik-App-Workflows zu erstellen.

In der folgenden Tabelle werden die Unterschiede zwischen dem Ressourcentyp Logik-App (Standard) und dem Ressourcentyp Logik-App (Verbrauch) kurz zusammengefasst. Außerdem lernen Sie die Unterschiede zwischen einer Einzelmandantenumgebung und einer Umgebung mit mehreren Mandanten sowie einer Integrationsdienstumgebung (Integration Service Environment, ISE) in Hinblick auf Bereitstellung, Hosten und Ausführung Ihrer Logik-App-Workflows kennen.