Azure Service Bus-Trigger für Azure Functions
Verwenden Sie den Service Bus-Trigger, um auf Nachrichten von einer Service Bus-Warteschlange oder einem Thema zu reagieren. Beginnend mit der Erweiterungsversion 3.1.0 können Sie Trigger für sitzungsfähige Warteschlangen oder Themen verwenden.
Informationen zu Setup- und Konfigurationsdetails finden Sie in der Übersicht.
Skalierungsentscheidungen von Service Bus für Verbrauchs- und Premium-Pläne werden basierend auf zielbasierter Skalierung getroffen. Weitere Informationen finden Sie unter Zielbasierte Skalierung.
Wichtig
In diesem Artikel werden Registerkarten verwendet, um mehrere Versionen des Node.js-Programmiermodells zu unterstützen. Das v4-Modell ist allgemein verfügbar und bietet JavaScript- und TypeScript-Entwicklern eine flexiblere und intuitivere Erfahrung. Weitere Informationen zur Funktionsweise des v4-Modells finden Sie im Azure Functions Node.js-Entwicklerhandbuch. Weitere Informationen zu den Unterschieden zwischen v3 und v4 finden Sie im Migrationshandbuch.
Azure Functions unterstützt zwei Programmiermodelle für Python. Wie Sie Ihre Bindung definieren, hängt vom gewählten Python-Programmiermodell ab.
Mit dem Python v2-Programmiermodell können Sie Bindungen mithilfe von Decorators direkt im Python-Funktionscode definieren. Weitere Informationen finden Sie im Python Developer-Leitfaden.
In diesem Artikel werden beide Programmiermodelle unterstützt.
Beispiel
Eine C#-Funktion kann mit einem der folgenden C#-Modi erstellt werden:
- Isoliertes Workermodell: Kompilierte C#-Funktion, die in einem Workerprozess ausgeführt wird, der von der Runtime isoliert ist. Ein isolierter Workerprozess ist erforderlich, um C#-Funktionen zu unterstützen, die in LTS- und Nicht-LTS-Versionen von .NET und .NET Framework ausgeführt werden. Erweiterungen für isolierte Workerprozessfunktionen verwenden
Microsoft.Azure.Functions.Worker.Extensions.*
-Namespaces. - In-Process-Modell: Kompilierte C#-Funktion, die im gleichen Prozess wie die Functions-Runtime ausgeführt wird. In einer Variante dieses Modells kann Functions mithilfe von C#-Skripts ausgeführt werden. Dies wird hauptsächlich für die Bearbeitung im C#-Portal unterstützt. Erweiterungen für In-Process-Funktionen verwenden
Microsoft.Azure.WebJobs.Extensions.*
-Namespaces.
Wichtig
Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, um den vollständigen Support zu ermöglichen.
Mit diesem Code wird ILogger
definiert und initialisiert:
private readonly ILogger<ServiceBusReceivedMessageFunctions> _logger;
public ServiceBusReceivedMessageFunctions(ILogger<ServiceBusReceivedMessageFunctions> logger)
{
_logger = logger;
}
Dieses Beispiel zeigt eine C#-Funktion, die eine einzelne Service Bus-Warteschlangennachricht empfängt und in die Protokolle schreibt:
[Function(nameof(ServiceBusReceivedMessageFunction))]
[ServiceBusOutput("outputQueue", Connection = "ServiceBusConnection")]
public string ServiceBusReceivedMessageFunction(
[ServiceBusTrigger("queue", Connection = "ServiceBusConnection")] ServiceBusReceivedMessage message)
{
_logger.LogInformation("Message ID: {id}", message.MessageId);
_logger.LogInformation("Message Body: {body}", message.Body);
_logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);
var outputMessage = $"Output message created at {DateTime.Now}";
return outputMessage;
}
Dieses Beispiel zeigt eine C#-Funktion, die mehrere Service Bus-Warteschlangennachrichten in einem einzelnen Batch empfängt und in die Protokolle schreibt:
[Function(nameof(ServiceBusReceivedMessageBatchFunction))]
public void ServiceBusReceivedMessageBatchFunction(
[ServiceBusTrigger("queue", Connection = "ServiceBusConnection", IsBatched = true)] ServiceBusReceivedMessage[] messages)
{
foreach (ServiceBusReceivedMessage message in messages)
{
_logger.LogInformation("Message ID: {id}", message.MessageId);
_logger.LogInformation("Message Body: {body}", message.Body);
_logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);
}
}
Dieses Beispiel zeigt eine C#-Funktion, die mehrere Service Bus-Warteschlangennachrichten empfängt, in die Protokolle schreibt und dann die Nachricht als abgeschlossen festlegt.
[Function(nameof(ServiceBusMessageActionsFunction))]
public async Task ServiceBusMessageActionsFunction(
[ServiceBusTrigger("queue", Connection = "ServiceBusConnection", AutoCompleteMessages = false)]
ServiceBusReceivedMessage message,
ServiceBusMessageActions messageActions)
{
_logger.LogInformation("Message ID: {id}", message.MessageId);
_logger.LogInformation("Message Body: {body}", message.Body);
_logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);
// Complete the message
await messageActions.CompleteMessageAsync(message);
}
Die folgende Java-Funktion verwendet die @ServiceBusQueueTrigger
-Anmerkung aus der @ServiceBusQueueTrigger
, um die Konfiguration für einen Service Bus-Warteschlangentrigger zu beschreiben. Die Funktion ruft die Nachricht aus der Warteschlange ab und fügt sie den Protokollen hinzu.
@FunctionName("sbprocessor")
public void serviceBusProcess(
@ServiceBusQueueTrigger(name = "msg",
queueName = "myqueuename",
connection = "myconnvarname") String message,
final ExecutionContext context
) {
context.getLogger().info(message);
}
Java-Funktionen können auch dadurch ausgelöst werden, dass eine Nachricht einem Service Bus-Thema hinzugefügt wird. Im folgenden Beispiel wird die @ServiceBusTopicTrigger
-Anmerkung verwendet, um die Triggerkonfiguration zu beschreiben.
@FunctionName("sbtopicprocessor")
public void run(
@ServiceBusTopicTrigger(
name = "message",
topicName = "mytopicname",
subscriptionName = "mysubscription",
connection = "ServiceBusConnection"
) String message,
final ExecutionContext context
) {
context.getLogger().info(message);
}
Das folgende Beispiel zeigt eine TypeScript-Funktion des Service Bus-Triggers. Die Funktion liest Nachrichtenmetadaten und protokolliert eine Service Bus-Warteschlangennachricht.
import { app, InvocationContext } from '@azure/functions';
export async function serviceBusQueueTrigger1(message: unknown, context: InvocationContext): Promise<void> {
context.log('Service bus queue function processed message:', message);
context.log('EnqueuedTimeUtc =', context.triggerMetadata.enqueuedTimeUtc);
context.log('DeliveryCount =', context.triggerMetadata.deliveryCount);
context.log('MessageId =', context.triggerMetadata.messageId);
}
app.serviceBusQueue('serviceBusQueueTrigger1', {
connection: 'MyServiceBusConnection',
queueName: 'testqueue',
handler: serviceBusQueueTrigger1,
});
Das folgende Beispiel zeigt eine JavaScript-Funktion des Service Bus-Triggers. Die Funktion liest Nachrichtenmetadaten und protokolliert eine Service Bus-Warteschlangennachricht.
const { app } = require('@azure/functions');
app.serviceBusQueue('serviceBusQueueTrigger1', {
connection: 'MyServiceBusConnection',
queueName: 'testqueue',
handler: (message, context) => {
context.log('Service bus queue function processed message:', message);
context.log('EnqueuedTimeUtc =', context.triggerMetadata.enqueuedTimeUtc);
context.log('DeliveryCount =', context.triggerMetadata.deliveryCount);
context.log('MessageId =', context.triggerMetadata.messageId);
},
});
Das folgende Beispiel zeigt eine Service Bus-Triggerbindung in einer Datei function.json sowie eine PowerShell-Funktion, die die Bindung verwendet.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"name": "mySbMsg",
"type": "serviceBusTrigger",
"direction": "in",
"topicName": "mytopic",
"subscriptionName": "mysubscription",
"connection": "AzureServiceBusConnectionString"
}
]
}
Dies ist die Funktion, die ausgeführt wird, wenn eine Service Bus-Nachricht gesendet wird.
param([string] $mySbMsg, $TriggerMetadata)
Write-Host "PowerShell ServiceBus queue trigger function processed message: $mySbMsg"
Das folgende Beispiel zeigt, wie Sie eine Service Bus-Warteschlangennachricht mittels Trigger lesen. Das Beispiel hängt davon ab, ob Sie das Python-Programmiermodell v1 oder v2 verwenden.
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="ServiceBusQueueTrigger1")
@app.service_bus_queue_trigger(arg_name="msg",
queue_name="<QUEUE_NAME>",
connection="<CONNECTION_SETTING>")
def test_function(msg: func.ServiceBusMessage):
logging.info('Python ServiceBus queue trigger processed message: %s',
msg.get_body().decode('utf-8'))
Das folgende Beispiel zeigt, wie ein Service Bus-Warteschlangenthema über einen Trigger gelesen wird.
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="ServiceBusTopicTrigger1")
@app.service_bus_topic_trigger(arg_name="message",
topic_name="TOPIC_NAME",
connection="CONNECTION_SETTING",
subscription_name="SUBSCRIPTION_NAME")
def test_function(message: func.ServiceBusMessage):
message_body = message.get_body().decode("utf-8")
logging.info("Python ServiceBus topic trigger processed message.")
logging.info("Message Body: " + message_body)
Attributes
Sowohl von C#-Bibliotheken vom Typ In-Process als auch von C#-Bibliotheken vom Typ Isolierter Workerprozess wird das ServiceBusTriggerAttribute-Attribut verwendet, um die Funktionstrigger zu definieren. Das C#-Skript verwendet stattdessen eine Konfigurationsdatei function.json, wie im C#-Skript-Handbuch beschrieben.
In der folgenden Tabelle werden die Eigenschaften erläutert, die mithilfe des Triggerattributs festgelegt werden können:
Eigenschaft | BESCHREIBUNG |
---|---|
QueueName | Der Name der zu überwachenden Warteschlange. Legen Sie diesen nur fest, wenn Sie eine Warteschlange überwachen (nicht für ein Thema). |
TopicName | Der Name des zu überwachenden Themas. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
SubscriptionName | Der Name des zu überwachenden Abonnements. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
Connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
IsBatched | Nachrichten werden in Batches übermittelt. Es ist ein Array oder ein Sammlungstyp erforderlich. |
IsSessionsEnabled | true , wenn eine Verbindung mit einer true Warteschlange oder einem Abonnement hergestellt wird. Andernfalls false , wobei es sich um den Standardwert handelt. |
AutoCompleteMessages | true wenn der Trigger die Nachricht nach einem erfolgreichen Aufruf automatisch abschließen soll. false sollte dies nicht erfolgen, z. B. wenn Sie die Meldungsabrechnung im Code behandeln. Wenn nicht explizit festgelegt, basiert das Verhalten auf der Konfiguration in host.json .autoCompleteMessages |
Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values
-Sammlung hinzu.
Decorator-Elemente
Gilt nur für das Python v2-Programmiermodell.
Für Python v2-Funktionen, die mithilfe eines Decorators definiert wurden, gelten die folgenden Eigenschaften für service_bus_queue_trigger
:
Eigenschaft | BESCHREIBUNG |
---|---|
arg_name |
Der Name der Variablen, die die Warteschlangen- oder Themanachricht im Funktionscode darstellt. |
queue_name |
Der Name der zu überwachenden Warteschlange. Legen Sie diesen nur fest, wenn Sie eine Warteschlange überwachen (nicht für ein Thema). |
connection |
Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
Informationen zu Python-Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Konfiguration.
Anmerkungen
Mit der ServiceBusQueueTrigger
-Anmerkung können Sie eine Funktion erstellen, die ausgeführt wird, wenn eine Service Bus-Warteschlangennachricht erstellt wird. Zu den verfügbaren Konfigurationsoptionen gehören die folgenden Eigenschaften:
Eigenschaft | Beschreibung |
---|---|
name | Der Name der Variablen, die die Warteschlangen- oder Themanachricht im Funktionscode darstellt. |
queueName | Der Name der zu überwachenden Warteschlange. Legen Sie diesen nur fest, wenn Sie eine Warteschlange überwachen (nicht für ein Thema). |
topicName | Der Name des zu überwachenden Themas. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
subscriptionName | Der Name des zu überwachenden Abonnements. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
Mit der ServiceBusTopicTrigger
-Anmerkung können Sie ein Thema und ein Abonnement festlegen, um zu bestimmen, welche Daten die Funktion auslösen.
Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values
-Sammlung hinzu.
Weitere Details finden Sie unter Trigger – Beispiel.
Konfiguration
Gilt nur für das Python v1-Programmiermodell.
In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options
-Objekt festlegen können, das an die Methoden app.serviceBusQueue()
oder app.serviceBusTopic()
übergeben wird.
Eigenschaft | BESCHREIBUNG |
---|---|
queueName | Der Name der zu überwachenden Warteschlange. Legen Sie diesen nur fest, wenn Sie eine Warteschlange überwachen (nicht für ein Thema). |
topicName | Der Name des zu überwachenden Themas. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
subscriptionName | Der Name des zu überwachenden Abonnements. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
accessRights | Zugriffsberechtigungen für die Verbindungszeichenfolge. Verfügbare Werte sind manage und listen . Die Standardeinstellung ist manage , d.h. heißt, dass die connection die Berechtigung manage hat. Wenn Sie eine Verbindungszeichenfolge verwenden, die nicht über die Berechtigung Manage verfügt, legen Sie accessRights auf „listen“ fest. Andernfalls versucht die Functions-Runtime ggf. erfolglos Vorgänge auszuführen, die Verwaltungsrechte erfordern. In Version 2.x und höheren Versionen von Azure Functions ist diese Eigenschaft nicht verfügbar, da die aktuelle Version des Service Bus SDK Verwaltungsvorgänge nicht unterstützt. |
isSessionsEnabled | true , wenn eine Verbindung mit einer true Warteschlange oder einem Abonnement hergestellt wird. Andernfalls false , wobei es sich um den Standardwert handelt. |
autoComplete | Muss für Funktionen, die nicht C# sind, true sein. Das bedeutet, dass der Trigger entweder automatisch nach der Verarbeitung abgeschlossen wird oder der Funktionscode manuell abgeschlossen wird.Wenn der Wert auf true festgelegt ist, wird die Nachricht automatisch durch den Triggervorgang abgeschlossen, sofern die Ausführung der Funktion erfolgreich war, andernfalls wird die Meldung verworfen.Ausnahmen führen in der Funktion dazu, dass die Runtime abandonAsync im Hintergrund aufruft. Wenn keine Ausnahme auftritt, wird completeAsync im Hintergrund aufgerufen. Diese Eigenschaft ist nur in Azure Functions ab Version 2.x und höher verfügbar. |
Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values
-Sammlung hinzu.
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
function.json-Eigenschaft | BESCHREIBUNG |
---|---|
type | Muss auf serviceBusTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
direction | Muss auf „in“ festgelegt werden. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
name | Der Name der Variablen, die die Warteschlangen- oder Themanachricht im Funktionscode darstellt. |
queueName | Der Name der zu überwachenden Warteschlange. Legen Sie diesen nur fest, wenn Sie eine Warteschlange überwachen (nicht für ein Thema). |
topicName | Der Name des zu überwachenden Themas. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
subscriptionName | Der Name des zu überwachenden Abonnements. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
accessRights | Zugriffsberechtigungen für die Verbindungszeichenfolge. Verfügbare Werte sind manage und listen . Die Standardeinstellung ist manage , d.h. heißt, dass die connection die Berechtigung manage hat. Wenn Sie eine Verbindungszeichenfolge verwenden, die nicht über die Berechtigung Manage verfügt, legen Sie accessRights auf „listen“ fest. Andernfalls versucht die Functions-Runtime ggf. erfolglos Vorgänge auszuführen, die Verwaltungsrechte erfordern. In Version 2.x und höheren Versionen von Azure Functions ist diese Eigenschaft nicht verfügbar, da die aktuelle Version des Service Bus SDK Verwaltungsvorgänge nicht unterstützt. |
isSessionsEnabled | true , wenn eine Verbindung mit einer true Warteschlange oder einem Abonnement hergestellt wird. Andernfalls false , wobei es sich um den Standardwert handelt. |
autoComplete | Muss für Funktionen, die nicht C# sind, true sein. Das bedeutet, dass der Trigger entweder automatisch nach der Verarbeitung abgeschlossen wird oder der Funktionscode manuell abgeschlossen wird.Wenn der Wert auf true festgelegt ist, wird die Nachricht automatisch durch den Triggervorgang abgeschlossen, sofern die Ausführung der Funktion erfolgreich war, andernfalls wird die Meldung verworfen.Ausnahmen führen in der Funktion dazu, dass die Runtime abandonAsync im Hintergrund aufruft. Wenn keine Ausnahme auftritt, wird completeAsync im Hintergrund aufgerufen. Diese Eigenschaft ist nur in Azure Functions ab Version 2.x und höher verfügbar. |
Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values
-Sammlung hinzu.
Vollständige Beispiele finden Sie im Abschnitt Beispiele.
Verwendung
Die folgenden Parametertypen werden von allen C#-Modalitäten und Erweiterungsversionen unterstützt:
Typ | BESCHREIBUNG |
---|---|
System.String | Verwenden Sie diesen Parameter, wenn es sich bei der Nachricht um einfachen Text handelt. |
byte[] | Wird für binäre Datenmeldungen verwendet |
Object | Wenn eine Nachricht JSON enthält, versucht Functions, die JSON-Daten in einen bekannten, einfachen („plain old“) CLR-Objekttyp zu deserialisieren. |
Messagingspezifische Parametertypen enthalten zusätzliche Nachrichtenmetadaten. Der vom Service Bus-Trigger unterstützten spezifischen Parametertypen hängen von der Runtimeversion von Functions, von der Version des Erweiterungspakets sowie von der verwendeten C#-Modalität ab.
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 ServiceBusReceivedMessage kö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 ServiceBusMessageActions
die AutoCompleteMessages
Eigenschaft des Trigger-Attributs auf false
. Dadurch wird verhindert, dass die Laufzeit nach einem erfolgreichen Funktionsaufruf versucht, Nachrichten abzuschließen.
Wenn die Connection
-Eigenschaft nicht definiert ist, sucht Functions nach einer App-Einstellung mit dem Namen AzureWebJobsServiceBus
. Dies ist der Standardname für die Service Bus-Verbindungszeichenfolge. Sie können die Connection
-Eigenschaft auch festlegen, um den Namen einer Anwendungseinstellung anzugeben, die die zu verwendende Service Bus-Verbindungszeichenfolge enthält.
Die eingehende Service Bus-Nachricht ist über einen ServiceBusQueueMessage
- oder ServiceBusTopicMessage
-Parameter verfügbar.
Die Service Bus-Instanz ist über den Parameter verfügbar, der in der name-Eigenschaft der Datei function.json konfiguriert ist.
Die Warteschlangennachricht ist über einen als func.ServiceBusMessage
typisierten Parameter für die Funktion verfügbar. Die Service Bus-Nachricht wird als Zeichenfolge oder als JSON-Objekt an die Funktion übergeben.
Ein vollständiges Beispiel finden Sie im Beispielabschnitt.
Verbindungen
Die connection
-Eigenschaft ist ein Verweis auf eine Umgebungskonfiguration, die angibt, wie sich die App mit Service Bus verbinden soll. Folgendes kann angegeben werden:
- Der Name einer Anwendungseinstellung, die eine Verbindungszeichenfolge enthält
- Der Name eines gemeinsam genutzten Präfixes für mehrere Anwendungseinstellungen, die zusammen eine identitätsbasierte Verbindung definieren.
Wenn der konfigurierte Wert sowohl eine genaue Übereinstimmung für eine einzelne Einstellung als auch eine Präfix-Übereinstimmung für andere Einstellungen ist, wird die genaue Übereinstimmung verwendet.
Verbindungszeichenfolge
Um die Verbindungszeichenfolge zu erhalten, führen Sie die Schritte unter Abrufen der Verwaltungsanmeldeinformationen aus. Die Verbindungszeichenfolge muss für einen Service Bus-Namespace gelten und darf nicht auf eine bestimmte Warteschlange oder ein Thema beschränkt sein.
Diese Verbindungszeichenfolge sollte in einer Anwendungseinstellung mit einem Namen gespeichert werden, der dem in der Eigenschaft connection
der Bindungskonfiguration angegebenen Wert entspricht.
Falls der Name der App-Einstellung mit „AzureWebJobs“ beginnt, können Sie nur den Rest des Namens angeben. Wenn Sie connection
also beispielsweise auf „MyServiceBus“ festlegen, sucht die Functions-Laufzeit nach einer App-Einstellung namens „AzureWebJobsMyServiceBus“. Ohne Angabe für connection
verwendet die Functions-Laufzeit die standardmäßige Service Bus-Verbindungszeichenfolge aus der App-Einstellung „AzureWebJobsServiceBus“.
Identitätsbasierte Verbindungen
Wenn Sie Version 5.x oder eine höhere Version der Erweiterung verwenden, kann die App anstelle einer Verbindungszeichenfolge mit einem Geheimnis eine Microsoft Entra-Identität verwenden. Dazu definieren Sie Einstellungen unter einem gemeinsamen Präfix, das der Eigenschaft connection
in der Trigger- und Bindungskonfiguration entspricht.
In diesem Modus benötigt die Erweiterung die folgenden Eigenschaften:
Eigenschaft | Vorlage für Umgebungsvariable | BESCHREIBUNG | Beispielwert |
---|---|---|---|
Vollqualifizierter Namespace | <CONNECTION_NAME_PREFIX>__fullyQualifiedNamespace |
Der vollqualifizierte Service Bus-Namespace. | <service_bus_namespace>.servicebus.windows.net |
Zusätzliche Eigenschaften können festgelegt werden, um die Verbindung anzupassen. Weitere Informationen finden Sie unter Allgemeine Eigenschaften für identitätsbasierte Verbindungen.
Hinweis
Wenn Sie Azure App Configuration oder Key Vault verwenden, um Einstellungen für Verbindungen mit verwalteter Identität bereitzustellen, sollten die Namen der Einstellungen ein gültiges Schlüsseltrennzeichen wie :
oder /
anstelle von __
verwenden, um sicherzustellen, dass die Namen richtig aufgelöst werden.
Beispiel: <CONNECTION_NAME_PREFIX>:fullyQualifiedNamespace
.
Identitätsbasierte Verbindungen verwenden eine verwaltete Identität, wenn sie im Azure Functions-Dienst gehostet werden. Standardmäßig wird eine vom System zugewiesene Identität verwendet, auch wenn mit den Eigenschaften credential
und clientID
eine vom Benutzer zugewiesene Identität angegeben werden kann. Beachten Sie, dass das Konfigurieren einer benutzerseitig zugewiesenen Identität mit einer Ressourcen-ID nicht unterstützt wird. Bei Ausführung in anderen Kontexten (z. B. bei der lokalen Entwicklung) wird stattdessen Ihre Entwickleridentität verwendet, Dieses Verhalten kann angepasst werden. Weitere Informationen finden Sie unter Lokale Entwicklung mit identitätsbasierten Verbindungen.
Erteilen der Berechtigung für die Identität
Unabhängig davon, welche Identität verwendet wird, muss diese über Berechtigungen zum Ausführen der vorgesehenen Aktionen verfügen. Daher müssen Sie für die meisten Azure-Dienste eine Rolle in Azure RBAC zuweisen, indem Sie entweder integrierte oder benutzerdefinierte Rollen verwenden, die diese Berechtigungen bieten.
Wichtig
Vom Zieldienst werden möglicherweise einige nicht für alle Kontexte erforderliche Berechtigungen verfügbar gemacht. Befolgen Sie nach Möglichkeit das Prinzip der geringsten Berechtigung, und gewähren Sie der Identität nur die erforderlichen Berechtigungen. Wenn die App beispielsweise nur Daten aus einer Datenquelle lesen muss, verwenden Sie eine Rolle, die nur über Leseberechtigungen verfügt. Es wäre nicht angemessen, eine Rolle zu zuweisen, die auch das Schreiben in diesen Dienst zulässt, da dies eine übermäßige Berechtigung für einen Lesevorgang wäre. Ebenso sollten Sie sicherstellen, dass die Rollenzuweisung auf die Ressourcen begrenzt ist, die gelesen werden müssen.
Sie müssen eine Rollenzuweisung erstellen, die zur Laufzeit Zugriff auf Ihre Themen und Warteschlangen ermöglicht. Verwaltungsrollen wie Besitzer sind nicht ausreichend. Die folgende Tabelle zeigt integrierte Rollen, die für die Service Bus-Erweiterung im Normalbetrieb empfohlen werden. Ihre Anwendung erfordert möglicherweise zusätzliche Berechtigungen basierend auf dem von Ihnen geschriebenen Code.
Bindungstyp | Integrierte Beispielrollen |
---|---|
Trigger1 | Azure Service Bus-Datenempfänger, Azure Service Bus-Datenbesitzer |
Ausgabebindung | Azure Service Bus-Datensender |
1 Zum Auslösen von Service Bus-Themen muss die Rollenzuweisung einen effektiven Bereich für die Service Bus-Abonnementressource aufweisen. Wenn nur das Thema eingeschlossen wird, tritt ein Fehler auf. Einige Clients (z. B. das Azure-Portal) stellen die Service Bus-Abonnementressource nicht als Bereich für die Rollenzuweisung bereit. In solchen Fällen kann die Azure CLI stattdessen verwendet werden. Weitere Informationen finden Sie unter Integrierte Azure-Rollen für Azure Service Bus.
Nicht verarbeitbare Nachrichten
Die Verarbeitung von nicht verarbeitbaren Nachricht kann nicht in Azure Functions gesteuert oder konfiguriert werden. Service Bus verarbeitet nicht verarbeitbare Nachrichten selbst.
PeekLock-Verhalten
Die Functions-Laufzeit empfängt eine Nachricht im PeekLock Modus.
Standardmäßig ruft die Laufzeit die Nachricht auf Complete
, wenn die Funktion erfolgreich abgeschlossen ist, oder aufruft Abandon
, wenn die Funktion fehlschlägt. Sie können den automatischen Abschluss mit der autoCompleteMessages
Eigenschaft in host.json
deaktivieren.
Standardmäßig ruft die Laufzeit die Nachricht auf Complete
, wenn die Funktion erfolgreich abgeschlossen ist, oder aufruft Abandon
, wenn die Funktion fehlschlägt. Sie können den automatischen Abschluss mit der autoCompleteMessages
Eigenschaft in host.json
oder über eine Eigenschaft für das Trigger-Attribut deaktivieren. Sie sollten den automatischen Abschluss deaktivieren, wenn der Funktionscode die Meldungsabrechnung verarbeitet.
Wenn die Funktion länger als im PeekLock
-Timeout angegeben ausgeführt wird, wird die Sperre automatisch verlängert, solange die Funktion ausgeführt wird. Die maxAutoRenewDuration
kann in der Datei host.json konfiguriert werden, die ServiceBusProcessor.MaxAutoLockRenewalDuration zugeordnet ist. Der Standardwert dieser Einstellung ist 5 Minuten.
Metadaten von Nachrichten
Messagingspezifische Typen ermöglichen das einfache Abrufen von Metadaten als Eigenschaften des Objekts. Diese Eigenschaften hängen von der Runtimeversion von Functions, der Version des Erweiterungspakets und der verwendeten C#-Variante ab.
Diese Eigenschaften sind Mitglieder der ServiceBusReceivedMessage-Klasse.
Eigenschaft | Typ | BESCHREIBUNG |
---|---|---|
ApplicationProperties |
ApplicationProperties |
Eigenschaften, die vom Absender festgelegt werden. |
ContentType |
string |
Ein Inhaltstypbezeichner, der vom Sender und Empfänger für anwendungsspezifische Logik verwendet wird. |
CorrelationId |
string |
Die Korrelations-ID. |
DeliveryCount |
Int32 |
Die Anzahl der Übermittlungen. |
EnqueuedTime |
DateTime |
Die in die Warteschlange eingereihte Uhrzeit in UTC. |
ScheduledEnqueueTimeUtc |
DateTime |
Die in die Warteschlange eingereihte geplante Uhrzeit in UTC |
ExpiresAt |
DateTime |
Die Ablaufzeit in UTC. |
MessageId |
string |
Benutzerdefinierter Wert, mit dem Service Bus doppelte Nachrichten ermitteln kann (sofern aktiviert). |
ReplyTo |
string |
Die Antwort auf die Warteschlangenadresse. |
Subject |
string |
Die anwendungsspezifische Bezeichnung, die statt der Metadateneigenschaft Label verwendet werden kann. |
To |
string |
Die Zieladresse. |