Azure Service Bus-Ausgabebindung für Azure Functions
Verwendet Azure Service Bus-Ausgabebindung zum Senden von Warteschlangen- oder Themanachrichten.
Informationen zu Setup- und Konfigurationsdetails finden Sie in der Übersicht.
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 Nachricht empfängt und sie in eine zweite Warteschlange 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;
}
In diesem Beispiel wird ein HTTP-Trigger mit einem OutputType
Objekt verwendet, um eine HTTP-Antwort zu senden und die Ausgabenachricht zu schreiben.
[Function("HttpSendMsg")]
public async Task<OutputType> Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req, FunctionContext context)
{
_logger.LogInformation($"C# HTTP trigger function processed a request for {context.InvocationId}.");
HttpResponseData response = req.CreateResponse(HttpStatusCode.OK);
await response.WriteStringAsync("HTTP response: Message sent");
return new OutputType()
{
OutputEvent = "MyMessage",
HttpResponse = response
};
}
Dieser Code definiert den mehrfachen Ausgabetyp OutputType
, der die Definition der ServiceBus-Ausgabebindung für OutputEvent
Folgendes enthält:
public class OutputType
{
[ServiceBusOutput("TopicOrQueueName", Connection = "ServiceBusConnection")]
public string OutputEvent { get; set; }
public HttpResponseData HttpResponse { get; set; }
}
Das folgende Beispiel zeigt eine Java-Funktion, die eine Nachricht an die Service Bus-Warteschlange myqueue
sendet, wenn sie durch eine HTTP-Anforderung ausgelöst wird.
@FunctionName("httpToServiceBusQueue")
@ServiceBusQueueOutput(name = "message", queueName = "myqueue", connection = "AzureServiceBusConnection")
public String pushToQueue(
@HttpTrigger(name = "request", methods = {HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS)
final String message,
@HttpOutput(name = "response") final OutputBinding<T> result ) {
result.setValue(message + " has been sent.");
return message;
}
Verwenden Sie die @QueueOutput
-Anmerkung in der Laufzeitbibliothek für Java-Funktionen für Funktionsparameter, deren Wert in eine Service Bus-Warteschlange geschrieben wird. Der Parametertyp sollte OutputBinding<T>
lauten, wobei T
für einen beliebigen nativen Java-Typ eines POJO steht.
Java-Funktionen können auch in ein Service Bus-Thema schreiben. Im folgenden Beispiel wird die @ServiceBusTopicOutput
-Anmerkung verwendet, um die Konfiguration für die Ausgabebindung zu beschreiben.
@FunctionName("sbtopicsend")
public HttpResponseMessage run(
@HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) HttpRequestMessage<Optional<String>> request,
@ServiceBusTopicOutput(name = "message", topicName = "mytopicname", subscriptionName = "mysubscription", connection = "ServiceBusConnection") OutputBinding<String> message,
final ExecutionContext context) {
String name = request.getBody().orElse("Azure Functions");
message.setValue(name);
return request.createResponseBuilder(HttpStatus.OK).body("Hello, " + name).build();
}
Das folgende Beispiel zeigt eine durch einen Timer ausgelöste TypeScript-Funktion, die alle 5 Minuten eine Warteschlangennachricht sendet.
import { app, InvocationContext, output, Timer } from '@azure/functions';
export async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<string> {
const timeStamp = new Date().toISOString();
return `Message created at: ${timeStamp}`;
}
app.timer('timerTrigger1', {
schedule: '0 */5 * * * *',
return: output.serviceBusQueue({
queueName: 'testqueue',
connection: 'MyServiceBusConnection',
}),
handler: timerTrigger1,
});
Um mehrere Nachrichten auszugeben, geben Sie ein Array anstelle eines einzelnen Objekts zurück. Beispiel:
const timeStamp = new Date().toISOString();
const message = `Message created at: ${timeStamp}`;
return [`1: ${message}`, `2: ${message}`];
Das folgende Beispiel zeigt eine durch einen Timer ausgelöste JavaScript-Funktion, die alle 5 Minuten eine Warteschlangennachricht sendet.
const { app, output } = require('@azure/functions');
const serviceBusOutput = output.serviceBusQueue({
queueName: 'testqueue',
connection: 'MyServiceBusConnection',
});
app.timer('timerTrigger1', {
schedule: '0 */5 * * * *',
return: serviceBusOutput,
handler: (myTimer, context) => {
const timeStamp = new Date().toISOString();
return `Message created at: ${timeStamp}`;
},
});
Um mehrere Nachrichten auszugeben, geben Sie ein Array anstelle eines einzelnen Objekts zurück. Beispiel:
const timeStamp = new Date().toISOString();
const message = `Message created at: ${timeStamp}`;
return [`1: ${message}`, `2: ${message}`];
Das folgende Beispiel zeigt eine Service Bus-Ausgabebindung in einer Datei function.json sowie eine PowerShell-Funktion, die die Bindung verwendet.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"type": "serviceBus",
"direction": "out",
"connection": "AzureServiceBusConnectionString",
"name": "outputSbMsg",
"queueName": "outqueue",
"topicName": "outtopic"
}
]
}
Hier ist das PowerShell-Skript, das eine Nachricht als Ausgabe der Funktion erstellt.
param($QueueItem, $TriggerMetadata)
Push-OutputBinding -Name outputSbMsg -Value @{
name = $QueueItem.name
employeeId = $QueueItem.employeeId
address = $QueueItem.address
}
Das folgende Beispiel zeigt, wie Sie Ausgaben in eine Service Bus-Warteschlange in Python schreiben. 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.route(route="put_message")
@app.service_bus_topic_output(arg_name="message",
connection="<CONNECTION_SETTING>",
topic_name="<TOPIC_NAME>")
def main(req: func.HttpRequest, message: func.Out[str]) -> func.HttpResponse:
input_msg = req.params.get('message')
message.set(input_msg)
return 'OK'
Attribute
Sowohl von C#-Bibliotheken des Typs In-Process als auch des Typs Isolierter Workerprozess werden Attribute verwendet, um die Ausgabebindung zu definieren. Das C#-Skript verwendet stattdessen eine Konfigurationsdatei function.json, wie im C#-Skript-Handbuch beschrieben.
Verwenden Sie in C#-Klassenbibliotheken das Attribut ServiceBusOutputAttribute, um die Warteschlange oder das Thema zu definieren, in die bzw. in das von der Ausgabe geschrieben wird.
In der folgenden Tabelle werden die Eigenschaften erläutert, die mithilfe des Attributs festgelegt werden können:
Eigenschaft | BESCHREIBUNG |
---|---|
EntityType | Legt den Entitätstyp entweder auf Queue (zum Senden von Nachrichten an eine Warteschlange) oder auf Topic (zum Senden von Nachrichten an ein Thema) fest. |
QueueOrTopicName | Der Name der Warteschlange oder des Themas, an die bzw. an das Nachrichten gesendet werden sollen. Verwenden Sie EntityType , um den Zieltyp festzulegen. |
Connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
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_topic_output
:
Eigenschaft | BESCHREIBUNG |
---|---|
arg_name |
Der Name der Variablen, die die Warteschlangen- oder Themanachricht im Funktionscode darstellt. |
queue_name |
Name der Warteschlange. Legen Sie diesen nur fest, wenn Warteschlangennachrichten gesendet werden (nicht für ein Thema). |
topic_name |
Name des Themas. Legen Sie diesen nur fest, wenn Themanachrichten gesendet werden (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. |
Informationen zu Python-Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Konfiguration.
Anmerkungen
Die Anmerkungen ServiceBusQueueOutput
und ServiceBusTopicOutput
sind zum Schreiben einer Nachricht als Funktionsausgabe verfügbar. Der mit diesen Anmerkungen ergänzte Parameter muss als OutputBinding<T>
deklariert werden, wobei T
der Typ ist, der dem Typ der Nachricht entspricht.
Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values
-Sammlung hinzu.
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 output.serviceBusQueue()
-Methode übergeben wurde.
Eigenschaft | BESCHREIBUNG |
---|---|
queueName | Name der Warteschlange. |
Verbindung | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options
-Objekt festlegen können, das an die output.serviceBusTopic()
-Methode übergeben wurde.
Eigenschaft | Beschreibung |
---|---|
topicName | Name des Themas. |
Verbindung | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
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 und im Attribut ServiceBus
festlegen:
Eigenschaft von „function.json“ | BESCHREIBUNG |
---|---|
type | Muss auf „serviceBus“ festgelegt werden. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
direction | Muss auf „out“ 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. Legen Sie diesen Wert auf „$return“ fest, um auf den Rückgabewert der Funktion zu verweisen. |
queueName | Name der Warteschlange. Legen Sie diesen nur fest, wenn Warteschlangennachrichten gesendet werden (nicht für ein Thema). |
topicName | Name des Themas. Legen Sie diesen nur fest, wenn Themanachrichten gesendet werden (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 (nur v1) | 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. |
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 Ausgabeparametertypen werden von allen C#-Modalitäten und Erweiterungsversionen unterstützt:
Typ | BESCHREIBUNG |
---|---|
System.String | Verwenden Sie diese Option, wenn es sich bei der zu schreibenden Nachricht um einfachen Text handelt. Wenn der Parameterwert am Ende der Funktion NULL ist, wird keine Nachricht erstellt. |
byte[] | Verwenden Sie diese Option zum Schreiben binärer Datennachrichten. Wenn der Parameterwert am Ende der Funktion NULL ist, wird keine Nachricht erstellt. |
Object | Wenn eine Nachricht JSON-Code enthält, wird das Objekt von Functions in JSON-Nachrichtennutzdaten serialisiert. Wenn der Parameterwert am Ende der Funktion NULL ist, wird eine Nachricht mit einem NULL-Objekt erstellt. |
Messagingspezifische Parametertypen enthalten zusätzliche Nachrichtenmetadaten. Die von der Ausgabebindung unterstützten spezifischen Parametertypen hängen von der Version der Functions-Runtime, von der Version des Erweiterungspakets sowie von der verwendeten C#-Modalität ab.
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. |
Für andere Ausgabeszenarien erstellen und verwenden Sie Typen direkt aus Azure.Messaging.ServiceBus.
In Azure Functions 1.x erstellt die Runtime die Warteschlange, falls sie nicht vorhanden ist und Sie accessRights
auf manage
festgelegt haben. In Azure Functions ab Version 2.x muss die Warteschlange oder das Thema bereits vorhanden sein. Wenn Sie eine nicht vorhandene Warteschlange oder ein nicht vorhandenes Thema angeben, tritt bei der Funktion ein Fehler auf.
Verwenden Sie das Azure Service Bus SDK anstelle der integrierten Ausgabebindung.
Die Ausgabe an den Service Bus ist über das Push-OutputBinding
-Cmdlet verfügbar. Dort übergeben Sie Argumente, die dem Namen entsprechen, der durch den Namensparameter der Bindung in der Datei Push-OutputBinding
festgelegt wird.
Verwenden Sie das Azure Service Bus SDK anstelle der integrierten Ausgabebindung.
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.
Ausnahmen und Rückgabecodes
Bindung | Verweis |
---|---|
Service Bus | Service Bus-Fehlercodes |
Service Bus | Service Bus-Grenzwerte |