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.
| Logik-App | Environment | Connector-Version |
|---|---|---|
| Verbrauch | Azure Logic Apps mit mehreren Mandanten | Verwalteter Connector (Standardklasse). Weitere Informationen finden Sie in der folgenden Dokumentation: - Referenz zum verwalteten Service Bus-Connector - Verwaltete Connectors in Azure Logic Apps |
| Verbrauch | Integrationsdienstumgebung (Integration Service Environment, ISE) | Verwalteter Connector (Standardklasse) und ISE-Version, die unterschiedliche Nachrichtenlimits als die Standardklasse aufweist. Weitere Informationen finden Sie in der folgenden Dokumentation: - Referenz zum verwalteten Service Bus-Connector - ISE-Nachrichtenlimits - Verwaltete Connectors in Azure Logic Apps |
| Standard | Einzelmandanten-Azure Logic Apps und App Service-Umgebung v3 (nur Windows-Pläne) | Verwalteter Connector (in Azure gehostet) und integrierter Connector, der auf dem Dienstanbieter basiert. Die integrierte Version bietet in der Regel eine höhere Leistung, bessere Funktionen und niedrigere Preise. Hinweis: Integrierte ServiceBus-Connectortrigger folgen dem Abruftrigger-Muster. Das bedeutet, dass der Trigger kontinuierlich nach Nachrichten in der Warteschlange oder im Themenabonnement sucht. Weitere Informationen finden Sie in der folgenden Dokumentation: - Referenz zum verwalteten Service Bus-Connector - Vorgänge für den integrierten Service Bus-Connector - Integrierte Connectors in Azure Logic Apps |
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:
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
Wichtig
Gehen Sie vorsichtig vor, wenn Sie einen Trigger und eine Aktion auswählen, die denselben Connectortyp aufweisen, und damit an derselben Entität arbeiten, z. B. einer Messagingwarteschlange oder einem Themenabonnement. Eine solche Kombination kann eine Endlosschleife bewirken, und Sie erhalten eine nie endende Logik-App.
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 dieEinstellung 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 jedoch für einen Service Bus-Trigger die Einstellung für Parallelität aktivieren, weist die Eigenschaft
maximumWaitingRunsden Standardwert 10 auf. Je nach Einstellung für die Sperrdauer der Service Bus-Entität und der Ausführungsdauer des Workflows ist dieser Standardwert möglicherweise zu hoch und kann zu einer Ausnahme „Sperre verloren“ führen. Um den optimalen Wert für Ihr Szenario zu ermitteln, beginnen Sie testweise mit dem Wert 1 oder 2 für die EigenschaftmaximumWaitingRuns. Weitere Informationen zum Ändern des Werts für die maximale Anzahl wartender Ausführungen finden Sie unter Ändern des Limits für wartende Ausführungen.
Integrierte ServiceBus-Connectortrigger
Derzeit werden Konfigurationseinstellungen für den integrierten ServiceBus-Trigger zwischen der Hosterweiterung Azure Functions gemeinsam verwendet, die in der host.json DateiIhrer Logik-App definiert ist, und den Triggereinstellungen, 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:
Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.
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“)
| Authentication type | Erforderliche Informationen |
|---|---|
| Zugriffsschlüssel | Die Verbindungszeichenfolge für Ihren Service Bus-Namespace. Weitere Informationen finden Sie unter Abrufen der Verbindungszeichenfolge für den Service Bus-Namespace. |
| Microsoft Entra integriert | Die Endpunkt-URL für Ihren Service Bus-Namespace. Weitere Informationen finden Sie unter Abrufen der Endpunkt-URL für den Service Bus-Namespace. |
| Verwaltete Logic Apps-Identität | Die Endpunkt-URL für Ihren Service Bus-Namespace. Weitere Informationen finden Sie unter Abrufen der Endpunkt-URL für den Service Bus-Namespace. |
Integrierte Connectorauthentifizierung (nur Workflows des Tarifs „Standard“)
| Authentication type | Erforderliche Informationen |
|---|---|
| Verbindungszeichenfolge | Die Verbindungszeichenfolge für Ihren Service Bus-Namespace. Weitere Informationen finden Sie unter Abrufen der Verbindungszeichenfolge für den Service Bus-Namespace. |
| Active Directory OAuth | Der vollqualifizierte Name für Ihren Service Bus-Namespace, z. B. <your-Service-Bus-namespace>.servicebus.windows.net. Weitere Informationen finden Sie unter Abrufen des vollqualifizierten Namens für den Service Bus-Namespace. Informationen zu den übrigen Eigenschaftswerten finden Sie unter Microsoft Entra ID Open Authentication. |
| Verwaltete Identität | Der vollqualifizierte Name für Ihren Service Bus-Namespace, z. B. <your-Service-Bus-namespace>.servicebus.windows.net. Weitere Informationen finden Sie unter Abrufen des vollqualifizierten Namens für den Service Bus-Namespace. |
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://.
Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.
Wählen Sie im Menü „Namespace“ unter Einstellungen die Option Freigegebene Zugriffsrichtlinien aus.
Wählen Sie im Bereich Richtlinien für gemeinsamen Zugriff auf RootManageSharedAccessKey aus.
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.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://.
Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.
Wählen Sie im Namespacemenü unter Einstellungen die Option Eigenschaften aus.
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
Öffnen Sie im Azure-Portal Ihren Service Bus-Namespace.
Wählen Sie im Namespacemenü Übersicht aus.
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:
Logik-App-Workflows für den Verbrauch: Visual Studio oder Visual Studio Code
Standard-Logik-App-Workflows: Visual Studio Code
Öffnen Sie im Azure-Portal die verbrauchsbasierte Logik-App-Ressource mit einem leeren Workflow im Designer.
-
In diesem Beispiel wird als Nächstes der Trigger namens Bei Empfang einer Nachricht in einer Warteschlange (automatisch abschließen) verwendet.
Wenn Sie dazu aufgefordert werden, geben Sie für Ihre Verbindung die folgenden Informationen an. Wählen Sie Erstellen, wenn Sie fertig sind.
Eigenschaft Erforderlich BESCHREIBUNG Verbindungsname Ja Ein Name für Ihre Verbindung Authentifizierungstyp Ja Der Typ der Authentifizierung, die für den Zugriff auf Ihren Service Bus-Namespace verwendet werden soll. Weitere Informationen hierzu finden Sie unter Authentifizierung über einen verwalteten Connector. Verbindungszeichenfolge Ja Die zuvor kopierte und gespeicherte Verbindungszeichenfolge. Diese Verbindung verwendet beispielsweise die Zugriffsschlüsselauthentifizierung und stellt die Verbindungszeichenfolge für einen Service Bus-Namespace bereit:
Wenn das Triggerinformationsfeld angezeigt wird, geben Sie die erforderlichen Informationen an, z. B.:
Eigenschaft Erforderlich Beschreibung Warteschlangenname Ja Die ausgewählte Warteschlange für den Zugriff Warteschlangentyp Nein Der Typ für die ausgewählte Warteschlange Wie oft möchten Sie auf Elemente prüfen?: Ja Das Abrufintervall und die Häufigkeit, mit der die Warteschlange auf Elemente überprüft wird 
Öffnen Sie zum Hinzufügen weiterer verfügbarer Eigenschaften zum Trigger die Liste Neuen Parameter hinzufügen, und wählen Sie die gewünschten Eigenschaften aus.
Fügen Sie für Ihren Workflow erforderliche Aktionen hinzu.
Sie können beispielsweise eine Aktion hinzufügen, die eine E-Mail sendet, wenn eine neue Nachricht eingeht. Wenn Ihr Trigger die Warteschlange überprüft und eine neue Nachricht findet, führt Ihr Workflow die von Ihnen ausgewählten Aktionen für die gefundene Nachricht aus.
Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.
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:
Logik-App-Workflows für den Verbrauch: Visual Studio oder Visual Studio Code
Standard-Logik-App-Workflows: Visual Studio Code
Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App und deren Workflow im Workflow-Designer.
-
In diesem Beispiel wird als Nächstes die Aktion Nachricht senden verwendet.
Wenn Sie dazu aufgefordert werden, geben Sie für Ihre Verbindung die folgenden Informationen an. Wählen Sie Erstellen, wenn Sie fertig sind.
Eigenschaft Erforderlich BESCHREIBUNG Verbindungsname Ja Ein Name für Ihre Verbindung Authentifizierungstyp Ja Der Typ der Authentifizierung, die für den Zugriff auf Ihren Service Bus-Namespace verwendet werden soll. Weitere Informationen hierzu finden Sie unter Authentifizierung über einen verwalteten Connector. Verbindungszeichenfolge Ja Die zuvor kopierte und gespeicherte Verbindungszeichenfolge. Diese Verbindung verwendet beispielsweise die Zugriffsschlüsselauthentifizierung und stellt die Verbindungszeichenfolge für einen Service Bus-Namespace bereit:
Wenn das Aktionsinformationsfeld angezeigt wird, geben Sie die erforderlichen Informationen an, z. B.:
Eigenschaft Erforderlich Beschreibung Warteschlangen-/Themenname Ja Das ausgewählte Warteschlangen- oder Themenziel zum Senden der Nachricht Sitzungs-ID Nein Die Sitzungs-ID, wenn die Nachricht an eine sitzungsfähige Warteschlange oder ein sitzungsfähigesThema gesendet wird Systemeigenschaften Nein - Keine
- Ausführungsdetails: Fügen Sie Metadateneigenschaftsinformationen zur Ausführung als benutzerdefinierte Eigenschaften in der Nachricht hinzu.
Öffnen Sie zum Hinzufügen weiterer verfügbarer Eigenschaften zu der Aktion die Liste Neuen Parameter hinzufügen, und wählen Sie die gewünschten Eigenschaften aus.
Fügen Sie alle weiteren Aktionen hinzu, die Ihr Workflow erfordert.
Sie können beispielsweise eine Aktion hinzufügen, die eine E-Mail sendet, um das Senden Ihrer Nachricht zu bestätigen.
Wenn Sie fertig sind, speichern Sie Ihren Workflow. Wählen Sie auf der Symbolleiste des Designers Speichern aus.
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:
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).
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.
Keine Sitzung verfügbar
Gelegentlich führen Vorgänge wie das Abschließen einer Nachricht oder das Erneuern einer Sitzung zu dem folgenden Fehler:
{
"status": 400,
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'. clientRequestId: facae905-9ba4-44f4-a42a-888888888888",
"error": {
"message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
}
}
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.
Es besteht die Möglichkeit, dass Anforderungen nicht an dieselbe Rolleninstanz weitergeleitet werden, z. B. aufgrund einer Aktualisierung der Infrastruktur, der Bereitstellung eines Connectors usw. In diesem Fall schlagen Anforderungen fehl, weil der Empfänger zum Ausführen der Vorgänge in der Sitzung nicht in der Rolleninstanz verfügbar ist, die die Anforderung verarbeitet.
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.