Freigeben über

Azure Service Bus Ausgabebindung für Azure Functions

Verwenden Sie Azure Service Bus Ausgabebindung, um Warteschlangen- oder Themennachrichten zu senden.

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 Entwicklerhandbuch Azure Functions Node.js. 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 Dekoratoren direkt in Ihrem Python Funktionscode definieren. Weitere Informationen finden Sie im Entwicklerhandbuch Python.

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. Der isolierte Arbeitsprozess ist erforderlich, um C#-Funktionen zu unterstützen, die auf LTS- und nicht LTS-Versionen .NET und dem .NET Framework ausgeführt werden. Erweiterungen für isolierte Arbeitsprozessfunktionen 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 Service Bus Ausgabebindung in OutputEvent 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 eine Service Bus Warteschlange myqueue sendet, wenn sie von einer 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 in der Java-Funktionslaufzeitbibliothek die @QueueOutput Anmerkung für Funktionsparameter, deren Wert in eine Service Bus Warteschlange geschrieben würde. Der Parametertyp sollte OutputBinding<T> sein, wobei T ein systemeigener Java Typ eines alten Java-Objekts (POJO) ist.

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. Zum 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. Zum 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 function.jsondatei und einer 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 
}

Im folgenden Beispiel wird veranschaulicht, wie Sie in Service Bus Themen und Service Bus Warteschlangen in Python herausschreiben. Das Beispiel hängt davon ab, ob Sie das v1- oder v2-Python Programmiermodell verwenden.

In diesem Beispiel wird gezeigt, wie Sie in ein Service Bus Thema schreiben.

import logging
import azure.functions as func

app = func.FunctionApp()

@app.route(route="put_message")
@app.service_bus_topic_output(arg_name="message",
                              connection="AzureServiceBusConnectionString",
                              topic_name="outTopic")
def main(req: func.HttpRequest, message: func.Out[str]) -> func.HttpResponse:
    input_msg = req.params.get('message')
    message.set(input_msg)
    return 'OK'

In diesem Beispiel wird gezeigt, wie Sie in eine Service Bus Warteschlange schreiben.

import azure.functions as func

app = func.FunctionApp()

@app.route(route="put_message")
@app.service_bus_queue_output(
    arg_name="msg",
    connection="AzureServiceBusConnectionString",
    queue_name="outqueue")
def put_message(req: func.HttpRequest, msg: func.Out[str]):
    msg.set(req.get_body().decode('utf-8'))
    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 die ServiceBusOutputAttribute, um die Warteschlange oder das Thema zu definieren, in die die Ausgabe geschrieben wurde.

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.
Verbindung Der Name einer App-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit Service Bus hergestellt werden soll. Siehe Verbindungen.

Decorator-Elemente

Gilt nur für das Python v2-Programmiermodell.

Für Python v2-Funktionen, die mithilfe eines Dekorators definiert sind, werden die folgenden Eigenschaften für die 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-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit Service Bus hergestellt werden soll. Siehe Verbindungen.

Informationen zu Python Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Configuration.

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-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit Service Bus hergestellt werden soll. 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-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit Service Bus hergestellt werden soll. 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
Typ Muss auf serviceBus festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure-Portal erstellen.
Richtung Muss auf out festgelegt sein. 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).
Verbindung Der Name einer App-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit Service Bus hergestellt werden soll. Siehe Verbindungen.
accessRights (nur v1) Zugriffsrechte 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 Azure Functions Version 2.x und höher ist diese Eigenschaft nicht verfügbar, da die neueste Version des Service Bus SDK keine Verwaltungsvorgänge 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.

Verbrauch

Alle C#-Modalitäten und Erweiterungsversionen unterstützen die folgenden Ausgabeparametertypen:

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.
Objekt 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 und sind nicht mit der JSON-Serialisierung kompatibel. Daher ist es nicht möglich, die Ausgabebindung im isolierten Modell zu verwenden ServiceBusMessage . 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:

Typ 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:

Typ 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 aus Azure. Messaging.ServiceBus direkt. Ein Beispiel für die Verwendung der Abhängigkeitsinjektion zum Erstellen eines Clienttyps aus dem Azure SDK finden Sie unter Register Azure Clients.

In Azure Functions 1.x erstellt die Laufzeit die Warteschlange, wenn sie nicht vorhanden ist, und Sie haben accessRights auf manage festgelegt. In Azure Functions Version 2.x und höher muss die Warteschlange oder das Thema bereits vorhanden sein. Wenn Sie eine Warteschlange oder ein Thema angeben, die nicht vorhanden ist, schlägt die Funktion fehl.

Verwenden Sie anstelle der integrierten Ausgabebindung das Azure Service Bus SDK.

Auf die Ausgabemeldung greifen Sie zu, indem Sie den Wert direkt zurückgeben oder context.extraOutputs.set() verwenden.

Die Ausgabe an die Service Bus ist über das Cmdlet Push-OutputBinding verfügbar, in dem Sie Argumente übergeben, die dem durch den Namensparameter der Bindung in der Datei function.json entsprechen.

Der Ausgabefunktionsparameter muss als func.Out[str] oder func.Out[bytes]definiert werden. Ausführliche Informationen finden Sie im Ausgabebeispiel . Alternativ können Sie das Azure Service Bus SDK anstelle der integrierten Ausgabebindung verwenden.

Ein vollständiges Beispiel finden Sie im Beispielabschnitt.

Verbindungen

Die connection-Eigenschaft verweist auf die Umgebungskonfiguration, die angibt, wie die App eine Verbindung mit Service Bus herstellt. Sie kann Folgendes angeben:

  • Der Name einer Anwendungseinstellung, die eine Verbindungszeichenfolge enthält.
  • Der Name eines freigegebenen Präfixes für mehrere Anwendungseinstellungen, die gemeinsam eine verwaltete Identitätsverbindung 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.

Tipp

Verwenden Sie verwaltete Identitätsverbindungen anstelle von Verbindungszeichenfolgen, um eine bessere Sicherheit zu gewährleisten. Verbindungszeichenfolgen enthalten Anmeldeinformationen, die verfügbar gemacht werden können, während verwaltete Identitäten die Notwendigkeit zum Verwalten von geheimen Schlüsseln vermeiden.

Wenn Sie version 5.x oder höher der Erweiterung verwenden, anstatt ein Verbindungszeichenfolge mit einem geheimen Schlüssel zu verwenden, können Sie die App über eine Microsoft Entra Identity verfügen. Um verwaltete Identitäten zu verwenden, definieren Sie Einstellungen unter einem allgemeinen Präfix, das der Eigenschaft in der connection Trigger- und Bindungskonfiguration zugeordnet ist.

In diesem Modus erfordert die Erweiterung die folgenden Anwendungseinstellungen:

Vorlagenbasierte Einstellung BESCHREIBUNG Identitätstyp
<CONNECTION_NAME_PREFIX>__fullyQualifiedNamespace Der vollqualifizierte Service Bus Namespace. Vom System zugewiesene oder vom Benutzer zugewiesene
<CONNECTION_NAME_PREFIX>__credential Muss auf managedidentity festgelegt sein. Benutzerseitig zugewiesen
<CONNECTION_NAME_PREFIX>__clientId Die Client-ID einer benutzerseitig zugewiesenen verwalteten Identität. Benutzerseitig zugewiesen

Der Wert, mit dem Sie ersetzen <CONNECTION_NAME_PREFIX> , wird von der Bindungserweiterung als Name der Verbindungseinstellung behandelt.

Wenn Ihre Bindungskonfiguration beispielsweise mit einer vom Benutzer zugewiesenen verwalteten Identität angibt connection = "ServiceBusConnection" , konfigurieren Sie die folgenden Anwendungseinstellungen:

{
    "ServiceBusConnection__fullyQualifiedNamespace": "myservicebus.servicebus.windows.net",
    "ServiceBusConnection__credential": "managedidentity",
    "ServiceBusConnection__clientId": "00000000-0000-0000-0000-000000000000"
}

Tipp

Verwenden Sie vom Benutzer zugewiesene verwaltete Identitäten für Produktionsszenarien, in denen Sie eine differenzierte Kontrolle über Identitätsberechtigungen über mehrere Ressourcen benötigen.

Sie können andere Einstellungen in der Vorlage verwenden, um die Verbindung weiter 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 Verwaltete Identitätsverbindungen bereitzustellen, sollten Einstellungsnamen ein gültiges Schlüsseltrennzeichen wie : oder / anstelle der __ verwenden, um sicherzustellen, dass Namen ordnungsgemäß aufgelöst werden.

Beispiel: ServiceBusConnection:fullyQualifiedNamespace

Beim Hosten im Azure Functions Dienst verwenden identitätsbasierte Verbindungen eine managed Identity. 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. Für die meisten Azure Dienste bedeutet dies, dass Sie eine Rolle in Azure RBAC zuweisen müssen, indem Sie entweder integrierte oder benutzerdefinierte Rollen verwenden, die diese Berechtigungen bereitstellen.

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. In der folgenden Tabelle sind integrierte Rollen aufgeführt, die empfohlen werden, wenn Sie die Service Bus Erweiterung im normalen Betrieb verwenden. Ihre Anwendung erfordert möglicherweise zusätzliche Berechtigungen basierend auf dem von Ihnen geschriebenen Code.

Bindungstyp Integrierte Beispielrollen
Auslöser1 Azure Service Bus Data Receiver, Azure Service Bus Data Owner
Ausgabebindung Azure Service Bus Data Sender

1 Um aus Service Bus Themen auszulösen, muss die Rollenzuweisung über die Service Bus Abonnementressource einen effektiven Bereich haben. Wenn nur das Thema eingeschlossen wird, tritt ein Fehler auf. Einige Clients, z. B. das Azure-Portal, machen die Service Bus Abonnementressource nicht als Bereich für die Rollenzuweisung verfügbar. In solchen Fällen kann stattdessen die Azure CLI verwendet werden. Weitere Informationen finden Sie unter Azure integrierten Rollen für Azure Service Bus.

Ausnahmen und Rückgabecodes

Bindung Verweis
Service Bus Service Bus Fehlercodes
Service Bus Service Bus Limits

Nächste Schritte

  • Last updated on