Herstellen einer Verbindung mit Azure Service Bus über Workflows in Azure Logic Apps

Gilt für: Azure Logic Apps (Verbrauch + Standard)

In diesem Leitfaden wird gezeigt, wie Sie über einen Workflow in Azure Logic Apps mit dem Service Bus-Connector auf Azure Service Bus zugreifen. Anschließend können Sie automatisierte Workflows erstellen, die durch Ereignisse in einem Service Bus ausgelöst werden, oder Aktionen ausführen, um Service Bus-Elemente zu verwalten. Beispiele:

• Überwachen des Eingangs (automatisch abschließen) oder Empfangs (Peek-Lock) von Nachrichten in Warteschlangen, Themen und Abonnements
• Senden von Nachrichten
• Erstellen und Löschen von Themenabonnements
• Verwalten von Nachrichten in Warteschlangen und Themenabonnements, z.B. abrufen, verzögert abrufen, abschließen, verzögern, verwerfen und als unzustellbar kennzeichnen.
• Erneuern von Sperren für Nachrichten und Sitzungen in Warteschlangen und Themenabonnements
• Schließen von Sitzungen in Warteschlangen und Themen

Sie können Trigger verwenden, die Antworten von Azure Service Bus erhalten, und die Ausgabe für andere Aktionen in Ihren Workflows verfügbar machen. Sie können die Ausgaben von Service Bus-Aktionen auch in anderen Aktionen verwenden.

Technische Referenz für den Connector

Der Service Bus-Connector liegt in verschiedenen Versionen vor, je nach Workflowtyp und Hostumgebung der logischen Anwendung.

Voraussetzungen

• Ein Azure-Konto und ein Azure-Abonnement. Wenn Sie nicht über ein Azure-Abonnement verfügen, können Sie sich für ein kostenloses Azure-Konto registrieren.

• Ein Service Bus-Namespace und eine Messagingentität, z.B. eine Warteschlange. Weitere Informationen finden Sie in der folgenden Dokumentation:

  • Erstellen eines Service Bus-Namespaces

  • Erstellen eines Service Bus-Namespace und einer Service Bus-Warteschlange

  • Erstellen eines Service Bus-Namespace und eines Service Bus-Themas mit einem Abonnement

• Der Logik-App-Workflow, in dem Sie eine Verbindung mit Ihrem Service Bus-Namespace und der Messagingentität herstellen. Wenn Sie Ihren Workflow mit einem Service Bus-Trigger starten möchten, müssen Sie mit einem leeren Workflow beginnen. Um in Ihrem Workflow eine Service Bus-Aktion zu verwenden, starten Sie Ihren Workflow mit einem beliebigen Trigger.

• Wenn Ihre Logik-App-Ressource eine verwaltete Identität verwendet, um den Zugriff auf Ihren Service Bus-Namespace und die Messagingentität zu authentifizieren, stellen Sie sicher, dass Sie Rollenberechtigungen auf den entsprechenden Ebenen zugewiesen haben. Wenn Sie beispielsweise auf eine Warteschlange zugreifen möchten, benötigt die verwaltete Identität eine Rolle, die über die erforderlichen Berechtigungen für diese Warteschlange verfügt.

  • Jede Logik-App-Ressource sollte nur eine verwaltete Identität verwenden, auch wenn der Workflow der Logik-App auf unterschiedliche Messaging-Entitäten zugreift.

  • Jede verwaltete Identität, die auf eine Warteschlange oder ein Themenabonnement zugreift, sollte eine eigene Service Bus-API-Verbindung verwenden.

  • Service Bus-Vorgänge, die Nachrichten mit verschiedenen Messagingentitäten austauschen und unterschiedliche Berechtigungen erfordern, sollten ihre eigenen Service Bus-API-Verbindungen verwenden.

  Weitere Informationen zu verwalteten Identitäten finden Sie unter Authentifizieren des Zugriffs auf Azure-Ressourcen mithilfe verwalteter Identitäten in Azure Logic Apps.

• Standardmäßig sind die integrierten Service Bus-Connectorvorgänge in der Vorschau zustandslos. Um diese Vorgänge im zustandsbehafteten Modus auszuführen, lesen Sie Aktivieren des zustandsbehafteten Modus für zustandslose integrierte Connectors.

Überlegungen zu Azure Service Bus Vorgängen

Endlosschleifen

Grenzwert für gespeicherte Sitzungen im Connectorcache

Der Service Bus-Connector kann pro Service Bus-Messagingentität wie Abonnement oder Thema bis zu 1.500 eindeutige Sitzungen gleichzeitig im Connectorcache speichern. Wenn die Anzahl der Sitzungen dieses Limit überschreitet, werden alte Sitzungen aus dem Cache entfernt. Weitere Informationen finden Sie unter Nachrichtensitzungen.

Senden von korrelierten Nachrichten in einer bestimmten Reihenfolge

Wenn Sie zusammengehörige Nachrichten in einer bestimmten Reihenfolge senden müssen, können Sie über den Service Bus-Connector und das Muster für einen sequenziellen Konvoi einen Workflow erstellen. Korrelierte Nachrichten verfügen über eine Eigenschaft zum Definieren der Beziehung zwischen diesen Nachrichten, z. B. die ID für die Sitzung in Azure Service Bus.

Beim Erstellen eines Workflows für eine Logik-App im Tarif „Verbrauch“ können Sie die Vorlage Zustellung korrelierter Nachrichten in der richtigen Reihenfolge mithilfe von Service Bus-Sitzungen auswählen, mit der das Muster für einen sequenziellen Konvoi implementiert wird. Weitere Informationen finden Sie im Artikel zum Senden zusammengehöriger Nachrichten in der richtigen Reihenfolge.

Unterstützung großer Nachrichten

Die Unterstützung großer Nachrichten ist nur für Workflows im Tarif „Standard“ verfügbar, wenn Sie die integrierten Service Bus-Connectorvorgänge verwenden. Beispielsweise können Sie mithilfe der integrierten Trigger und Aktionen große Nachrichten empfangen und erhalten.

Für den vom Service Bus verwalteten Connector ist die maximale Nachrichtengröße auf 1 MB beschränkt, auch wenn Sie einen Service Bus-Namespace der Premiumebene verwenden.

Erhöhen des Timeouts für das Empfangen und Senden von Nachrichten

In Workflows des Tarifs „Standard“, die integrierte Service Bus-Vorgänge verwenden, können Sie das Timeout für das Empfangen und Senden von Nachrichten erhöhen. Um beispielsweise das Timeout für den Empfang einer Nachricht zu erhöhen, , ändern Sie die folgende Einstellung in der Azure Functions-Erweiterung:

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "serviceBus": {
         "batchOptions": {
            "operationTimeout": "00:15:00"
         }
      }  
   }
}

Um das Timeout für das Senden einer Nachricht zu erhöhen, fügen Sie die Einstellung der ServiceProviders.ServiceBus.MessageSenderOperationTimeout-App hinzu.

Referenz zum verwalteten Service Bus-Connector

• Für den verwalteten Service Bus-Connector weisen alle Trigger ein langes Abrufintervall auf. Dieser Triggertyp verarbeitet alle Nachrichten und wartet dann 30 Sekunden lang auf weitere Nachrichten, die in der Warteschlange oder im Themenabonnement eingehen. Gehen innerhalb von 30 Sekunden keine Nachrichten ein, wird die Triggerausführung übersprungen. Andernfalls fährt der Trigger mit dem Lesen von Nachrichten fort, bis die Warteschlange oder das Themenabonnement leer ist. Der nächste Triggerabruf basiert auf dem in den Triggereigenschaften angegebenen Wiederholungsintervall.

• Einige Trigger, z. B. der TriggerBei Empfang mindestens einer Nachricht in der Warteschlange (autom. abschließen), können eine oder mehrere Nachrichten zurückgeben. Wird ein solcher Trigger ausgelöst, gibt er mindestens eine und maximal so viele Nachrichten zurück, wie diese in seiner Eigenschaft Maximale Nachrichtenanzahl angegeben ist.

  Hinweis

  Mit dem Trigger für automatisches Abschließen wird eine Nachricht automatisch abgeschlossen, doch der Abschluss erfolgt erst beim nächsten Aufruf des Service Bus. Dieses Verhalten kann sich auf den Entwurf Ihres Workflows auswirken. Beispielsweise sollten Sie die Parallelität für den Trigger zum automatischen Abschließen nicht ändern, da diese Änderung doppelte Nachrichten verursachen kann, wenn Ihr Workflow in einen gedrosselten Zustand versetzt wird. Eine Änderung des Parallelitätssteuerelements führt zu folgenden Bedingungen:

  • Gedrosselte Trigger werden mit dem WorkflowRunInProgress-Code übersprungen.

  • Der Vorgang zum Abschließen wird nicht ausgeführt.

  • Die nächste Triggerausführung findet nach dem Abrufintervall statt.

  Sie müssen die Sperrdauer des Service Bus auf einen längeren Wert als das Abrufintervall festlegen. Trotz dieser Einstellung wird die Nachricht möglicherweise noch immer nicht abgeschlossen, wenn Ihr Workflow beim nächsten Abrufintervall weiterhin in einem gedrosselten Zustand verbleibt.

  Wenn Sie die Parallelität für einen Service Bus-Auslöser für die automatische Vervollständigung ändern müssen, nehmen Sie diese Änderung erst vor dem ersten Speichern des Workflows vor. Erstellen und speichern Sie zuerst Ihren Workflow, bevor Sie den Auslöser bearbeiten, um die Parallelität zu ändern.

Integrierte ServiceBus-Connectortrigger

Für den integrierten Service-Bus-Connector folgen nicht-sitzungsbezogene Trigger einem kontinuierlichen Abfragetriggermuster, das vollständig vom Connector verwaltet wird. Bei diesem Muster überprüft der Trigger ständig, ob Nachrichten in der Warteschlange oder im Themenabonnement vorhanden sind. Sitzungsbezogene Trigger folgen dem Triggermuster mit langem Abrufintervall. Ihre Konfiguration wird durch die Azure Functions-Einstellung namens clientRetryOptions:tryTimeout geregelt. Derzeit werden Konfigurationseinstellungen für den integrierten Service Bus-Trigger von der Azure Functions-Hosterweiterung, die in der host.json-Datei Ihrer Logik-App definiert ist, und den Triggereinstellungen gemeinsam verwendet, die im Workflow Ihrer Logik-App definiert sind, die Sie entweder über den Designer oder die Codeansicht einrichten können. In diesem Abschnitt werden beide Einstellungsspeicherorte behandelt.

• In Standardworkflows können einige Trigger, z. B. wenn Nachrichten in einem Warteschlangentrigger verfügbar sind, eine oder mehrere Nachrichten zurückgeben. Wenn diese Trigger ausgelöst werden, werden sie zwischen einer und der Anzahl der Nachrichten zurückgegeben. Für diesen Triggertyp und bei dem der Parameter Maximale Nachrichtenanzahl nicht unterstützt wird, können Sie die Anzahl der empfangenen Nachrichten mithilfe der Eigenschaft maxMessageBatchSize in der host.json Datei weiterhin steuern. Informationen zum Auffinden dieser Datei finden Sie unter Bearbeiten von Host- und App-Einstellungen für Standardlogik-Apps.

  "extensions": {
    "serviceBus": {
        "maxMessageBatchSize": 25
    }
  }
  

• Sie können auch die Parallelität für den ServiceBus-Trigger aktivieren, entweder über den Designer oder im Code:

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100
      }
  }
  

  Wenn Sie die Parallelität mithilfe eines Batches einrichten, behalten Sie die Anzahl gleichzeitiger Ausführungen bei, die größer als die Gesamtbatchgröße sind. Auf diese Weise gehen Lesenachrichten nicht in einen Wartezustand und werden immer wieder aufgenommen, wenn sie gelesen werden. In einigen Fällen kann der Trigger bis zu zweimal die Batchgröße aufweisen.

• Wenn Sie die Parallelität aktivieren, wird der SplitOn-Grenzwert auf 100 Elemente reduziert. Dieses Verhalten gilt für alle Trigger, nicht nur für den ServiceBus-Trigger. Stellen Sie sicher, dass die angegebene Batchgröße kleiner als dieser Grenzwert für jeden Trigger ist, in dem Sie die Parallelität aktivieren.

• Einige Szenarien sind vorhanden, in denen der Trigger die Parallelitätseinstellungen überschreiten kann. Statt diese Ausführung fehlzuschlagen, werden sie von Azure Logic Apps in eine Warteschleife eingereiht, bis sie gestartet werden können. Die Einstellung maximumWaitingRuns steuert die Anzahl der im Wartezustand zulässigen Läufe:

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100,
          "maximumWaitingRuns": 50
      }
  }
  

  Stellen Sie mit dem ServiceBus-Trigger sicher, dass Sie diese Änderungen sorgfältig testen, damit die Ausführung nicht länger als das Nachrichtensperrtimeout wartet. Weitere Informationen zu den Standardwerten finden Sie hier unter Parallelitäts- und Debatchierungsgrenzwerte.

• Wenn Sie die Parallelität aktivieren, ist standardmäßig eine Verzögerung von 30 Sekunden zwischen Batchlesevorgängen vorhanden. Diese Verzögerung verlangsamt den Auslöser, um die folgenden Ziele zu erreichen:

  • Verringern Sie die Anzahl der gesendeten Speicheraufrufe, um die Anzahl der Ausführungen zu überprüfen, auf die Parallelität angewendet werden soll.

  • Imitieren Sie das Verhalten des vom Service Bus verwalteten Connectortriggers, der eine 30-sekunden lange Abfrage aufweist, wenn keine Nachrichten gefunden werden.

  Sie können diese Verzögerung ändern, aber stellen Sie sicher, dass Sie alle Änderungen am Standardwert sorgfältig testen:

  "workflow": {
      "settings": {
          "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
      }
  }
  
  

Schritt 1: Überprüfen des Zugriffs auf den Service Bus-Namespace

Um zu bestätigen, dass Ihre Logik-App-Ressource über Berechtigungen zum Zugriff auf Ihren Service Bus-Namespace verfügt, gehen Sie folgendermaßen vor:

1. Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.

2. Wählen Sie im Menü „Namespace“ unter Einstellungen die Option Freigegebene Zugriffsrichtlinien aus. Stellen Sie im Bereich Ansprüche sicher, dass Sie die Verwaltungsberechtigungen für diesen Namespace besitzen.

   

Schritt 2: Abrufen von Verbindungsauthentifizierungsanforderungen

Wenn Sie später erstmals einen Service Bus-Trigger oder eine Aktion hinzufügen, werden Sie aufgefordert, Verbindungsinformationen einschließlich des Verbindungsauthentifizierungstyps anzugeben. Basierend auf Ihrem Logik-App-Workflowtyp, der Version des Service Bus-Connectors und dem ausgewählten Authentifizierungstyp benötigen Sie die folgenden Elemente:

Authentifizierung über einen verwalteten Connector (Workflows der Tarife „Verbrauch“ und „Standard“)

Integrierte Connectorauthentifizierung (nur Workflows des Tarifs „Standard“)

Abrufen der Verbindungszeichenfolge für den Service Bus-Namespace

Um eine Verbindung zu erstellen, wenn Sie einen Service Bus-Trigger oder eine Aktion hinzufügen, müssen Sie über die Verbindungszeichenfolge für Ihren Service Bus-Namespace verfügen. Die Verbindungszeichenfolge beginnt mit dem Präfix sb://.

1. Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.

2. Wählen Sie im Menü „Namespace“ unter Einstellungen die Option Freigegebene Zugriffsrichtlinien aus.

3. Wählen Sie im Bereich Richtlinien für gemeinsamen Zugriff auf RootManageSharedAccessKey aus.

4. Wählen Sie neben der primären oder sekundären Verbindungszeichenfolge die Schaltfläche „Kopieren“ aus.

   

   Hinweis

   Um zu überprüfen, ob die Zeichenfolge für den Namespace und nicht für eine bestimmte Messagingentität gilt, durchsuchen Sie die Verbindungszeichenfolge nach dem Parameter EntityPath. Wenn Sie diesen Parameter gefunden haben, gilt die Verbindungszeichenfolge für eine bestimmte Entität und ist nicht zur Verwendung mit Ihrem Workflow geeignet.

5. Speichern Sie die Verbindungszeichenfolge für die spätere Verwendung.

Abrufen der Endpunkt-URL für den Service Bus-Namespace

Wenn Sie den verwalteten Service Bus-Connector verwenden, benötigen Sie diese Endpunkt-URL, wenn Sie einen Authentifizierungstyp für Microsoft Entra integriert oder Verwaltete Logic Apps-Identitätauswählen. Die Endpunkt-URL beginnt mit dem Präfix sb://.

1. Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.

2. Wählen Sie im Namespacemenü unter Einstellungen die Option Eigenschaften aus.

3. Kopieren Sie unter Eigenschaften, neben Service Bus-Endpunkt die Endpunkt-URL, und speichern Sie sie zur späteren Verwendung, wenn Sie die Endpunkt-URL für den Service Bus angeben müssen.

Abrufen des vollqualifizierten Namens für den Service Bus-Namespace

1. Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.

2. Wählen Sie im Namespacemenü Übersicht aus.

3. Suchen Sie im Bereich Übersicht nach der Eigenschaft Hostname, und kopieren Sie den vollqualifizierten Namen, der das Format <your-Service-Bus-namespace>.servicebus.windows.net aufweist.

Schritt 3: Option 1 – Hinzufügen eines Service Bus-Triggers

In den folgenden Schritte wird das Azure-Portal verwendet. Mit der entsprechenden Azure Logic Apps-Erweiterung können Sie aber auch die folgenden Tools verwenden, um Logik-App-Workflows zu erstellen:

• Verbrauchsworkflows: Visual Studio Code
• Standardlogik-App-Workflows: Visual Studio Code

Schritt 3: Option 2 – Hinzufügen einer Service Bus-Aktion

In den folgenden Schritte wird das Azure-Portal verwendet. Mit der entsprechenden Azure Logic Apps-Erweiterung können Sie aber auch die folgenden Tools verwenden, um Logik-App-Workflows zu erstellen:

• Verbrauchsworkflows: Visual Studio Code
• Standardlogik-App-Workflows: Visual Studio Code

App-Einstellungen für den integrierten Service Bus-Connector

In einer Logik-App-Ressource des Tarifs „Standard“ enthält der integrierte Service Bus-Connector App-Einstellungen, die verschiedene Schwellenwerte steuern, z. B. ein Timeout für das Senden von Nachrichten und die Anzahl der Nachrichtenabsender pro Prozessorkern im Nachrichtenpool. Weitere Informationen finden Sie unter Referenz für App-Einstellungen (local.settings.json).

Lesen von Nachrichten aus Warteschlangen für unzustellbare Nachrichten mit integrierten Service Bus-Triggern

Führen Sie in Standardworkflows die folgenden Schritte mit den angegebenen Triggern aus, um eine Nachricht aus einer Warteschlange für unzustellbare Nachrichten oder einem Themenabonnement zu lesen:

1. Fügen Sie in Ihrem leeren Workflow basierend auf Ihrem Szenario den integrierten-Service Bus-Connectortrigger mit folgender Bezeichnung aus: Wenn Nachrichten in einer Warteschlange verfügbar sind oder Wenn eine Nachricht in einem Themaabonnement verfügbar ist (Peek-Lock).

2. Legen Sie im Trigger die folgenden Parameterwerte fest, um Ihre Warteschlange oder die Standardwarteschlange für unzustellbare Nachrichten des Themaabonnements anzugeben, die Sie wie jede andere Warteschlange aufrufen können:

   • Trigger Wenn Nachrichten in einer Warteschlange verfügbar sind: Legen Sie den Parameter Warteschlangenname auf queuename/$deadletterqueue fest.

   • Trigger Wenn eine Nachricht in einem Themenabonnement verfügbar ist (Peek-Lock): Legen Sie den Parameter Themenname auf topicname/Subscriptions/subscriptionname/$deadletterqueue fest.

   Weitere Informationen finden Sie unter Übersicht über Service Bus-Warteschlangen für unzustellbare Nachrichten.

Problembehandlung

Verzögerungen beim Inkrafttreten von Updates an Ihrem Workflow

Wenn das Abrufintervall eines Service Bus-Triggers kurz ist (z. B. 10 Sekunden), dauert es möglicherweise bis zu 10 Minuten, bis Updates für Ihren Workflow wirksam werden. Um dieses Problem zu umgehen, können Sie die Logik-App-Ressource deaktivieren, die Änderungen vornehmen und dann die Logik-App-Ressource wieder aktivieren.

Es ist keine Sitzung verfügbar oder sie ist von einem anderen Empfänger gesperrt.

Gelegentlich führen Vorgänge wie das Abschließen einer Nachricht oder das Erneuern einer Sitzung zu dem folgenden Fehler:

{
  "status": 400,
  "error": {
    "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
  }
}

Gelegentlich kann ein sitzungsbasierter Trigger mit dem folgenden Fehler fehlschlagen:

{
  "status": 400,
  "error": {
    "message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
  }
}

Der Service Bus-Connector verwendet einen In-Memory-Cache, um alle mit den Sitzungen verbundenen Vorgänge zu unterstützen. Der Service Bus-Nachrichtenempfänger wird im Arbeitsspeicher der Rolleninstanz (VM) zwischengespeichert, die die Nachrichten empfängt. Um alle Anforderungen zu verarbeiten, werden alle Aufrufe für die Verbindung an dieselbe Rolleninstanz weitergeleitet. Dieses Verhalten ist erforderlich, weil für alle Service Bus-Vorgänge in einer Sitzung derselbe Empfänger benötigt wird, der die Nachrichten für eine bestimmte Sitzung empfängt.

Aufgrund einer Aktualisierung der Infrastruktur, der Bereitstellung eines Connectors usw. besteht die Möglichkeit, dass Anforderungen nicht an dieselbe Rolleninstanz weitergeleitet werden. In diesem Fall schlagen Anforderungen aus einem der folgenden Gründe fehl:

• Der Empfänger ist nicht zum Ausführen der Vorgänge in der Sitzung in der Rolleninstanz verfügbar, die die Anforderung verarbeitet.

• Die neue Rolleninstanz versucht, die Sitzung abzurufen, für die in der alten Rolleninstanz eine Zeitüberschreitung aufgetreten ist oder die nicht geschlossen wurde.

Solange dieser Fehler nur gelegentlich auftritt, handelt es sich um einen erwarteten Fehler. Bei Auftreten des Fehlers bleibt die Nachricht dennoch in der Service Bus-Instanz erhalten. Bei der nächsten Trigger- oder Workflowausführung wird erneut versucht, die Nachricht zu verarbeiten.

Nächste Schritte

• Integrierte Trigger und Aktionen für Azure Logic Apps
• Integrierte Connectors für Azure Logic Apps
• Was sind Connectors in Azure Logic Apps