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

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

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.

Logik-Apps in Azure Active Directory-Mandanten nutzen dieselben Ressourcen für die Verarbeitung (Compute), den Speicher, das Netzwerk usw.

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

Daten verbleiben in derselben Region, in der Sie die ISE bereitstellen.
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
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.
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) – 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 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.

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.

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 (nur Windows-Pläne) 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 (nur Windows-Pläne) 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) 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. 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 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“ 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

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 - Schnellstart: Erstellen und Verwalten von Integrationsworkflows in Azure Logic Apps-Instanzen mit mehreren Mandanten – Azure CLI

- az logic

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 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 multimandantenfähigen als auch in einzelmandantenfä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.

    In zustandslosen Workflows sind verwaltete Connectoraktionen verfügbar, aber verwaltete Connectortrigger sind nicht verfügbar. Um den Workflow zu starten, wählen Sie also stattdessen einen integrierten Trigger aus, z. B. den Anforderungs-, Event Hubs- oder Service Bus-Trigger. Diese Trigger werden nativ in der Azure Logic Apps-Runtime ausgeführt. Der Wiederholungstrigger ist für zustandslose Workflows nicht verfügbar, sondern nur für zustandsbehaftete Workflows. 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 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.

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

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

    • Der Ressourcentyp Logik-App (Standard) unterstützt die gleichzeitige Aktivierung der systemseitig zugewiesenen verwalteten Identität und mehrerer benutzerseitig zugewiesener verwalteter Identitäten. Sie können jedoch immer noch jeweils nur eine Identität auswählen.

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

Integrierte Connectors für „Standard“

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

Beispielsweise verfügt ein Logik-App-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 Logik-App-Verbrauchsworkflow nicht über dieselben integrierten Connectorversionen verfügt, sind andere integrierte Connectors wie Azure API Management, Azure App Services und Batch 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, Azure Active Directory (Azure AD) 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.

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:

  • Trigger und Aktionen: Integrierte Trigger und Aktionen werden nativ in Azure Logic Apps ausgeführt, während verwaltete Connectors in Azure gehostet und ausgeführt werden. Für Standardworfklows sind einige integrierte Auslöser und Aktionen zurzeit nicht verfügbar, z. B. Gleitendes Fenster (Sliding Window), Batch, 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 die integrierten Trigger und Aktionen auf der Registerkarte Integriert angezeigt, während die Trigger und Aktionen der verwalteten Connectors auf der Registerkarte Azure angezeigt werden.

    Für zustandslose Workflows sind verwaltete Connectoraktionen verfügbar, aber verwaltete Connectortrigger sind nicht verfügbar. Somit wird die Registerkarte Azure nur angezeigt, wenn Sie verwaltete Connectoraktionen auswählen können. Obwohl Sie in 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 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.

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