Freigeben über

Azure Service Bus-Bindungen für Azure Functions

  • Artikel

Azure Functions wird über Trigger und Bindungen in Azure Service Bus integriert. Durch die Integration mit Service Bus können Sie Funktionen erstellen, die auf Warteschlangen- oder Themennachrichten reagieren und diese senden.

Aktion type
Ausführen einer Funktion, wenn eine Warteschlangen- oder Themennachricht von Service Bus empfangen wird Trigger
Senden von Azure Service Bus-Nachrichten Ausgabebindung

Installieren der Erweiterung

Das NuGet-Erweiterungspaket, das Sie installieren, hängt vom C#-Modus ab, den Sie in Ihrer Funktions-App verwenden:

Funktionen werden in einem isolierten C#-Workerprozess ausgeführt. Weitere Informationen finden Sie im Leitfaden zum Ausführen von Azure Functions (C#) in einem isolierten Workerprozess.

Fügen Sie Ihrem Projekt die Erweiterung hinzu, indem Sie dieses NuGet-Paket installieren.

Die Funktionalität der Erweiterung ist abhängig von der Erweiterungsversion unterschiedlich:

Diese Version bietet die Möglichkeit, eine Verbindung mithilfe einer Identität anstelle eines Geheimnisses herzustellen. Ein Tutorial zum Konfigurieren Ihrer Funktions-Apps mit verwalteten Identitäten finden Sie im Tutorial zum Erstellen einer Funktions-App mit identitätsbasierten Verbindungen.

Mit dieser Version können Sie Bindungen an Typen aus Azure.Messaging.ServiceBus erstellen.

Diese Version unterstützt die Konfiguration von Triggern und Bindungen über die .NET Aspire-Integration.

Fügen Sie ihrem Projekt die Erweiterung hinzu, indem Sie das NuGet-Paket, Version 5.x, installieren.

Installieren des Pakets

Die Service Bus-Speicherbindung ist Teil eines Erweiterungspakets, das in der Projektdatei „host.json“ angegeben ist. Möglicherweise müssen Sie dieses Paket ändern, um die Version der Bindung zu ändern, oder wenn Pakete noch nicht installiert sind. Weitere Informationen finden Sie unter Erweiterungspakete.

Diese Version bietet die Möglichkeit, eine Verbindung mithilfe einer Identität anstelle eines Geheimnisses herzustellen. Ein Tutorial zum Konfigurieren Ihrer Funktions-Apps mit verwalteten Identitäten finden Sie im Tutorial zum Erstellen einer Funktions-App mit identitätsbasierten Verbindungen.

Sie können diese Version der Erweiterung aus dem Erweiterungspaket v3 hinzufügen, indem Sie den folgenden Code in Ihrer Datei host.json hinzufügen oder ersetzen:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

Weitere Informationen finden Sie unter Aktualisierung Ihrer Erweiterungen.

Bindungstypen

Die für .NET unterstützten Bindungstypen hängen sowohl von der Erweiterungsversion als auch von dem C#-Ausführungsmodus ab, der einer der folgenden sein kann:

Eine Klassenbibliothek in einem isolierten Workerprozess ist eine kompilierte C#-Funktion, die in einem Prozess ausgeführt wird, der von der Runtime isoliert ist.

Wählen Sie eine Version aus, um für den Modus und die Version Details zum Bindungstyp anzuzeigen.

Der isolierte Workerprozess unterstützt Parametertypen gemäß den folgenden Tabellen.

Service Bus-Trigger

Wenn die Funktion eine einzelne Nachricht verarbeiten soll, kann der Service Bus-Trigger an die folgenden Typen gebunden werden:

type BESCHREIBUNG
string Die Nachricht als Zeichenfolge. Verwenden Sie diesen Parameter, wenn es sich bei der Nachricht um einfachen Text handelt.
byte[] Die Bytes der Nachricht.
Serialisierbare JSON-Typen Wenn ein Ereignis JSON-Daten enthält, versucht Azure Functions, die JSON-Daten in einen POCO-Typ (Plain Old CLR Object) zu deserialisieren.
ServiceBusReceivedMessage1 Das Nachrichtenobjekt.

Bei der Bindung an ServiceBusReceivedMessagekönnen Sie optional auch einen Parameter vom Typ ServiceBusMessageActions1,2 einschließen, um Nachrichtenabrechnungsaktionen auszuführen.

Wenn die Funktion einen Nachrichtenbatch verarbeiten soll, kann der Service Bus-Trigger an die folgenden Typen gebunden werden:

type BESCHREIBUNG
T[], wobei T einer der einzelnen Nachrichtentypen ist Ein Array von Ereignissen aus dem Batch. Jeder Eintrag stellt ein Ereignis dar.

Bei der Bindung an ServiceBusReceivedMessage[]können Sie optional auch einen Parameter vom Typ ServiceBusMessageActions1,2 einschließen, um Nachrichtenabrechnungsaktionen auszuführen.

1 Um diese Typen zu verwenden, müssen Sie auf Microsoft.Azure.Functions.Worker.Extensions.ServiceBus 5.14.1 oder höher und die gemeinsamen Abhängigkeiten für SDK-Typbindungen verweisen.

2 Legen Sie bei Verwendung ServiceBusMessageActionsdie AutoCompleteMessages Eigenschaft des Trigger-Attributs auf false. Dadurch wird verhindert, dass die Laufzeit nach einem erfolgreichen Funktionsaufruf versucht, Nachrichten abzuschließen.

Service Bus-Ausgabebindung

Wenn die Funktion eine einzelne Nachricht schreiben soll, kann die Service Bus-Ausgabebindung an die folgenden Typen gebunden werden:

type BESCHREIBUNG
string Die Nachricht als Zeichenfolge. Verwenden Sie diesen Parameter, wenn es sich bei der Nachricht um einfachen Text handelt.
byte[] Die Bytes der Nachricht.
Serialisierbare JSON-Typen Ein Objekt, das die Nachricht darstellt. Functions versucht, einen POCO-Typ (Plain-Old CLR Object) in JSON-Daten zu serialisieren.

Wenn die Funktion mehrere Nachrichten schreiben soll, kann die Service Bus-Ausgabebindung an die folgenden Typen gebunden werden:

type BESCHREIBUNG
T[], wobei T einer der einzelnen Nachrichtentypen ist. Ein Array, das mehrere Nachrichten enthält. Jeder Eintrag stellt eine Nachricht dar.

Erstellen und verwenden Sie für andere Ausgabeszenarien einen ServiceBusClient mit anderen Typen von Azure.Messaging.ServiceBus direkt. Ein Beispiel für die Verwendung der Abhängigkeitsinjektion zum Erstellen eines Clienttyps aus dem Azure SDK finden Sie unter Registrieren von Azure-Clients .

Einstellungen für „host.json“

In diesem Abschnitt werden die für diese Bindung verfügbaren Konfigurationseinstellungen beschrieben (abhängig von der Laufzeit und der Erweiterungsversion).

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "clientRetryOptions":{
                "mode": "exponential",
                "tryTimeout": "00:01:00",
                "delay": "00:00:00.80",
                "maxDelay": "00:01:00",
                "maxRetries": 3
            },
            "prefetchCount": 0,
            "transportType": "amqpWebSockets",
            "webProxy": "https://proxyserver:8080",
            "autoCompleteMessages": true,
            "maxAutoLockRenewalDuration": "00:05:00",
            "maxConcurrentCalls": 16,
            "maxConcurrentSessions": 8,
            "maxMessageBatchSize": 1000,
            "minMessageBatchSize": 1,
            "maxBatchWaitTime": "00:00:30",
            "sessionIdleTimeout": "00:01:00",
            "enableCrossEntityTransactions": false
        }
    }
}

Die clientRetryOptions-Einstellungen gelten nur für Interaktionen mit dem Service Bus-Dienst. Sie wirken sich nicht auf Wiederholungsversuche von Funktionsausführungen aus. Weitere Informationen finden Sie unter Wiederholungsversuche.

Eigenschaft Standard BESCHREIBUNG
mode Exponential Die Methode, die zum Berechnen von Wiederholungsverzögerungen verwendet werden soll Im standardmäßigen exponentiellen Modus werden Wiederholungsversuche mit einer Verzögerung basierend auf einer Backoff-Strategie ausgeführt, bei der jeder Versuch die Wartezeit bis zum nächsten Versuch erhöht. Im Modus Fixed werden Versuche in festen Abständen wiederholt, und jede Verzögerung hat die gleiche Dauer.
tryTimeout 00:01:00 Die maximale Dauer, die pro Versuch auf einen Vorgang gewartet werden soll
delay 00:00:00.80 Der Verzögerungs- oder Wartezeitfaktor, der zwischen Wiederholungsversuchen angewendet werden soll
maxDelay 00:01:00 Die maximale zugelassene Verzögerung zwischen Wiederholungsversuchen
maxRetries 3 Die maximale Anzahl von Wiederholungsversuchen, bevor der zugeordnete Vorgang als fehlgeschlagen angesehen wird
prefetchCount 0 Ruft die Anzahl der Nachrichten ab, die der Nachrichtenempfänger gleichzeitig anfordern kann, oder legt sie fest.
transportType amqpTcp Das Protokoll und der Transport, die für die Kommunikation mit Service Bus verwendet werden. Verfügbare Optionen: amqpTcp, amqpWebSockets
webProxy – Der Proxy, der für die Kommunikation mit Service Bus über Websockets verwendet werden soll. Ein Proxy kann nicht mit dem amqpTcp-Datentransport verwendet werden.
autoCompleteMessages true Bestimmt, ob nachrichten nach erfolgreicher Ausführung der Funktion automatisch abgeschlossen werden sollen.
maxAutoLockRenewalDuration 00:05:00 Die maximale Zeitspanne, in der die Nachrichtensperre automatisch erneuert wird. Diese Einstellung gilt nur für Funktionen, die nur jeweils eine einzelne Nachricht empfangen.
maxConcurrentCalls 16 Die maximale Anzahl gleichzeitiger Aufrufe für den Rückruf, die pro skalierte Instanz initiiert werden soll. Die Functions-Runtime verarbeitet standardmäßig mehrere Nachrichten gleichzeitig. Diese Einstellung wird nur verwendet, wenn die Eigenschaft oder das Attribut isSessionsEnabled für den Trigger auf false festgelegt ist. Diese Einstellung gilt nur für Funktionen, die nur jeweils eine einzelne Nachricht empfangen.
maxConcurrentSessions 8 Die maximale Anzahl von Sitzungen, die parallel pro skalierter Instanz verarbeitet werden können. Diese Einstellung wird nur verwendet, wenn die Eigenschaft oder das Attribut isSessionsEnabled für den Trigger auf true festgelegt ist. Diese Einstellung gilt nur für Funktionen, die nur jeweils eine einzelne Nachricht empfangen.
maxMessageBatchSize 1000 Die maximale Anzahl von Nachrichten, die an jeden Funktionsaufruf übergeben werden. Diese Einstellung gilt nur für Funktionen, die einen Nachrichtenbatch empfangen.
minMessageBatchSize1 1 Die Mindestanzahl von Nachrichten, die in einem Batch gewünscht sind. Das Minimum gilt nur, wenn die Funktion mehrere Nachrichten empfängt, und muss kleiner als maxMessageBatchSize sein.
Die Mindestgröße ist nicht streng garantiert. Ein partieller Batch wird versendet, wenn ein vollständiger Batch nicht vorbereitet werden kann, bevor maxBatchWaitTime abgelaufen ist.
maxBatchWaitTime1 00:00:30 Das maximale Intervall, das der Trigger warten sollte, um einen Batch zu füllen, bevor die Funktion aufgerufen wird. Die Wartezeit wird nur berücksichtigt, wenn minMessageBatchSize größer als 1 ist, und wird andernfalls ignoriert. Wenn weniger als minMessageBatchSize Nachrichten verfügbar waren, bevor die Wartezeit verstrichen ist, wird die Funktion mit einem partiellen Batch aufgerufen. Die längste zulässige Wartezeit beträgt 50 % der Dauer der Entitätsnachrichtensperre. Das bedeutet, dass die maximal zulässige Wartezeit 2 Minuten und 30 Sekunden beträgt. Andernfalls erhalten Sie möglicherweise Sperrausnahmen.

HINWEIS: Dieses Intervall ist keine strikte Garantie für den genauen Zeitpunkt, zu dem die Funktion aufgerufen wird. Es gibt eine kleine Fehlertoleranz aufgrund der Timergenauigkeit.
sessionIdleTimeout – Die maximale Wartezeit für das Empfangen einer Nachricht für die derzeit aktive Sitzung. Nach Ablauf dieser Zeit wird die Sitzung geschlossen, und die Funktion versucht, eine andere Sitzung zu verarbeiten.
enableCrossEntityTransactions false Gibt an, ob Transaktionen aktiviert werden, die mehrere Entitäten in einem Service Bus umfassen.

1 Verwenden von minMessageBatchSize und maxBatchWaitTime erfordert v5.10.0 des Microsoft.Azure.WebJobs.Extensions.ServiceBus-Pakets oder eine höhere Version.

Nächste Schritte