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

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.

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:

• Azure Logic Apps Running Anywhere - Runtime Deep Dive (Azure Logic Apps läuft überall – Runtimeanalyse)
• Einführung in Azure Functions
• Trigger und Bindungen in Azure Functions

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

Mehrinstanzenfähige Umgebungen

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.

Zusammenfassung der Unterschiede zwischen zustandsabhängigen und zustandslosen Workflows

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

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 1.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 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, XML-Validierung, Erstellen von XML-Code mit einem Schema und Parsen von XML-Code mit einem Schema

    • 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 von überall ausgelöst werden, da Azure Logic Apps SAS-Verbindungszeichenfolgen (Shared Access Signature) generiert, die diese Logik-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:

  • Netzwerkoptionen von Azure Functions

  • Azure Logic Apps ohne Grenzen: Netzwerkoptionen mit Azure Logic Apps

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

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

Für den Standard-Logik-App-Workflow unterscheiden sich die folgenden Funktionen 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 Standard-Workflows sind einige integrierte Trigger und Aktionen zurzeit nicht verfügbar, z. B. rollierende Fenster und Azure App Service-Vorgänge. 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.

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

    • Standard-Workflows können nur einen Trigger haben und unterstützen nicht mehrere Trigger.

• Authentifizierung

  • Einige anforderungsbasierte Trigger, die eingehende Aufrufe verarbeiten (z. B. der Anforderungstrigger), unterstützen derzeit nicht Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), während andere (z. B. der HTTP-Webhooktrigger) diese Unterstützung bieten.

  • Einige integrierte, anbieterbasierte Connectors unterstützen derzeit nicht die Auswahl der benutzerseitig zugewiesenen verwalteten Identität für die Authentifizierung. Allgemein werden aber sowohl systemseitig als auch benutzerseitig zugewiesene verwaltete Identitäten unterstützt. Standardmäßig wird die systemseitig zugewiesene verwaltete Identität automatisch aktiviert.

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

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

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:

• Firewallberechtigungen für Logik-Apps für einzelinstanzenfähige Logik-Apps – Azure-Portal
• Firewallberechtigungen für Logik-Apps für einzelinstanzenfähige Logik-Apps – Visual Studio Code

Nächste Schritte

• Erstellen von Workflows für Instanzen mit einem Mandanten im Azure-Portal
• Erstellen von Workflows für Instanzen mit einem Mandanten in Visual Studio Code

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

• Bei Fehlern oder Problemen erstellen Sie Ihre Probleme in GitHub.
• Bei Fragen, Anforderungen, Kommentaren und anderem Feedback verwenden Sie dieses Feedbackformular.