Freigeben über

Azure Service Bus Clientbibliothek für Python – Version 7.11.4

  • Artikel

Azure Service Bus ist ein leistungsstarker cloudverwalteter Messagingdienst für die Echtzeit- und fehlertolerante Kommunikation zwischen verteilten Absendern und Empfängern.

Service Bus bietet mehrere Mechanismen für asynchrone hochzuverlässige Kommunikation, z. B. strukturiertes First-in-First-Out-Messaging, Veröffentlichungs-/Abonnentenfunktionen und die Möglichkeit, bei bedarfsbedingtem Bedarf einfach zu skalieren.

Verwenden Sie die Service Bus-Clientbibliothek für Python, um zwischen Anwendungen und Diensten zu kommunizieren und asynchrone Messagingmuster zu implementieren.

  • Erstellen Sie Service Bus-Namespaces, -Warteschlangen, -Themen und -Abonnements, und ändern Sie deren Einstellungen.
  • Senden und Empfangen von Nachrichten in Ihren Service Bus-Kanälen.
  • Verwenden Sie Nachrichtensperren, Sitzungen und Funktionen für unzustellbare Nachrichten, um komplexe Messagingmuster zu implementieren.

Quellcode | Paket (PyPi) | Paket (Conda) | API-Referenzdokumentation | Produktdokumentation | Proben | Changelog

HINWEIS: Wenn Sie Version 0.50 oder niedriger verwenden und zur neuesten Version dieses Pakets migrieren möchten, lesen Sie unseren Migrationsleitfaden, um von Service Bus V0.50 zu Service Bus V7 zu wechseln.

Erste Schritte

Installieren des Pakets

Installieren Sie die Azure Service Bus Clientbibliothek für Python mit pip:

pip install azure-servicebus

Voraussetzungen:

Um dieses Paket verwenden zu können, benötigen Sie Folgendes:

Wenn Sie einen Azure Service Bus-Namespace benötigen, können Sie ihn über das Azure-Portal erstellen. Wenn Sie die grafische Portal-Benutzeroberfläche nicht verwenden möchten, können Sie die Azure CLI über Cloud Shell verwenden oder die Azure CLI lokal ausführen, um eine mit diesem Azure CLI-Befehl zu erstellen:

az servicebus namespace create --resource-group <resource-group-name> --name <servicebus-namespace-name> --location <servicebus-namespace-location>

Authentifizieren des Clients

Die Interaktion mit Service Bus beginnt mit einer instance der ServiceBusClient -Klasse. Sie benötigen entweder eine Verbindungszeichenfolge mit SAS-Schlüssel oder einen Namespace und einen seiner Kontoschlüssel, um das Clientobjekt zu instanziieren. In den unten verlinkten Beispielen wird veranschaulicht, wie Sie sich mit beiden Ansätzen authentifizieren können.

Erstellen eines Clients aus Verbindungszeichenfolge

Erstellen Sie einen Client mithilfe der Azure-Identity-Bibliothek:

  • Dieser Konstruktor verwendet den vollqualifizierten Namespace Ihrer Service Bus-instance und anmeldeinformationen, die das TokenCredential-Protokoll implementiert. Im Paket azure-identity sind Implementierungen des TokenCredential Protokolls verfügbar. Der vollqualifizierte Namespace hat das Format <yournamespace.servicebus.windows.net>.
  • Um die von azure-identitybereitgestellten Anmeldeinformationstypen zu verwenden, installieren Sie das Paket: pip install azure-identity
  • Um die asynchrone API verwenden zu können, müssen Sie außerdem zuerst einen asynchronen Transport installieren, z. B aiohttp. : pip install aiohttp
  • Bei Verwendung von Azure Active Directory muss Ihrem Prinzipal eine Rolle zugewiesen werden, die den Zugriff auf Service Bus ermöglicht, z. B. die Rolle Azure Service Bus Datenbesitzer. Weitere Informationen zur Verwendung der Azure Active Directory-Autorisierung mit Service Bus finden Sie in der zugehörigen Dokumentation.

Hinweis: Der Client kann ohne Kontext-Manager initialisiert werden, muss jedoch manuell über client.close() geschlossen werden, um keine Ressourcen zu löschen.

Wichtige Begriffe

Nachdem Sie ein ServiceBusClientinitialisiert haben, können Sie mit den primären Ressourcentypen innerhalb eines Service Bus-Namespace interagieren, von denen mehrere vorhanden sein können und für die die tatsächliche Nachrichtenübertragung stattfindet, wobei der Namespace häufig als Anwendungscontainer dient:

  • Warteschlange: Ermöglicht das Senden und Empfangen von Nachrichten. Wird häufig für die Punkt-zu-Punkt-Kommunikation verwendet.

  • Thema: Im Gegensatz zu Warteschlangen eignen sich Themen besser für Veröffentlichungs-/Abonnementszenarien. Ein Thema kann an gesendet werden, erfordert jedoch ein Abonnement, von dem mehrere parallel verwendet werden können.

  • Abonnement: Der Mechanismus, der aus einem Thema verwendet werden soll. Jedes Abonnement ist unabhängig und erhält eine Kopie jeder Nachricht, die an das Thema gesendet wird. Mithilfe von Regeln und Filtern können Sie anpassen, welche Nachrichten von einem bestimmten Abonnement empfangen werden.

Weitere Informationen zu diesen Ressourcen finden Sie unter Was ist Azure Service Bus?.

Um mit diesen Ressourcen zu interagieren, sollten Sie mit den folgenden SDK-Konzepten vertraut sein:

  • ServiceBusClient: Dies ist das Objekt, das ein Benutzer zuerst initialisieren sollte, um eine Verbindung mit einem Service Bus-Namespace herzustellen. Um mit einer Warteschlange, einem Thema oder einem Abonnement zu interagieren, würde ein Absender oder Empfänger aus diesem Client ausgelöst.

  • ServiceBusSender: Um Nachrichten an eine Warteschlange oder ein Thema zu senden, verwendet man die entsprechende get_queue_senderget_topic_sender Oder -Methode aus einer ServiceBusClient instance, wie hier gezeigt.

  • ServiceBusReceiver: Um Nachrichten von einer Warteschlange oder einem Abonnement zu empfangen, verwendet man die entsprechende get_queue_receiverget_subscription_receiver Oder -Methode aus einem ServiceBusClient instance, wie hier dargestellt.

  • ServiceBusMessage: Beim Senden ist dies der Typ, den Sie erstellen, um Ihre Nutzlast zu enthalten. Beim Empfang greifen Sie hier auf die Nutzlast zu.

Threadsicherheit

Wir garantieren nicht, dass serviceBusClient, ServiceBusSender und ServiceBusReceiver threadsicher sind. Es wird nicht empfohlen, diese Instanzen threadsübergreifend wiederzuverwenden. Es liegt an der ausgeführten Anwendung, diese Klassen threadsicher zu verwenden.

Beispiele

Die folgenden Abschnitte enthalten mehrere Codeausschnitte, die einige der gängigsten Service Bus-Aufgaben behandeln, einschließlich:

Um Verwaltungsaufgaben auszuführen, z. B. das Erstellen und Löschen von Warteschlangen/Themen/Abonnements, verwenden Sie die azure-mgmt-servicebus-Bibliothek, die hier verfügbar ist.

Weitere Beispiele finden Sie im Beispielverzeichnis , das gängige Service Bus-Szenarien wie Senden, Empfangen, Sitzungsverwaltung und Nachrichtenverarbeitung veranschaulicht.

Senden von Nachrichten an eine Warteschlange

HINWEIS: Siehe Referenzdokumentation hier.

In diesem Beispiel wird eine einzelne Nachricht und ein Array von Nachrichten an eine Warteschlange gesendet, von der angenommen wird, dass sie bereits vorhanden ist und die über die Befehle Azure-Portal oder az erstellt wird.

from azure.servicebus import ServiceBusClient, ServiceBusMessage

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_sender(queue_name) as sender:
        # Sending a single message
        single_message = ServiceBusMessage("Single message")
        sender.send_messages(single_message)

        # Sending a list of messages
        messages = [ServiceBusMessage("First message"), ServiceBusMessage("Second message")]
        sender.send_messages(messages)

HINWEIS: Eine Nachricht kann mit der -Methode oder durch Angeben ServiceBusMessage.scheduled_enqueue_time_utc vor dem Aufruf für eine ServiceBusSender.schedule_messages() verzögerte Übermittlung geplant werden.ServiceBusSender.send_messages()

Weitere Details zur Planung und Terminabbruch finden Sie hier in einem Beispiel.

Empfangen von Nachrichten aus einer Warteschlange

Um aus einer Warteschlange zu empfangen, können Sie entweder einen Ad-hoc-Empfang über receiver.receive_messages() oder dauerhaft über den Empfänger selbst empfangen.

Empfangen von Nachrichten aus einer Warteschlange durch Durchlaufen über ServiceBusReceiver

from azure.servicebus import ServiceBusClient

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    # max_wait_time specifies how long the receiver should wait with no incoming messages before stopping receipt.
    # Default is None; to receive forever.
    with client.get_queue_receiver(queue_name, max_wait_time=30) as receiver:
        for msg in receiver:  # ServiceBusReceiver instance is a generator.
            print(str(msg))
            # If it is desired to halt receiving early, one can break out of the loop here safely.

HINWEIS: Jede Nachricht, die mit receive_mode=PEEK_LOCK empfangen wird (dies ist die Standardeinstellung, wobei die alternative RECEIVE_AND_DELETE die Nachricht sofort nach Erhalt aus der Warteschlange entfernt) verfügt über eine Sperre, die verlängert receiver.renew_message_lock werden muss, bevor sie abläuft, wenn die Verarbeitung länger als die Sperrdauer dauern würde. Unter AutoLockRenewer finden Sie informationen zu einem Hilfsprogramm, um dies automatisch im Hintergrund auszuführen. Die Sperrdauer wird in Azure für die Warteschlange oder das Thema selbst festgelegt.

Empfangen von Nachrichten von einer Warteschlange über ServiceBusReceiver.receive_messages()

HINWEIS:ServiceBusReceiver.receive_messages() empfängt eine einzelne oder eingeschränkte Liste von Nachrichten über einen Ad-hoc-Methodenaufruf, anstatt dauerhaft vom Generator zu empfangen. Sie gibt immer eine Liste zurück.

from azure.servicebus import ServiceBusClient

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        received_message_array = receiver.receive_messages(max_wait_time=10)  # try to receive a single message within 10 seconds
        if received_message_array:
            print(str(received_message_array[0]))

    with client.get_queue_receiver(queue_name) as receiver:
        received_message_array = receiver.receive_messages(max_message_count=5, max_wait_time=10)  # try to receive maximum 5 messages in a batch within 10 seconds
        for message in received_message_array:
            print(str(message))

In diesem Beispiel deklariert max_message_count die maximale Anzahl von Nachrichten, die versucht werden sollen, zu empfangen, bevor ein max_wait_time erreicht wird, wie in Sekunden angegeben.

HINWEIS: Es sollte auch beachtet werden, dass ServiceBusReceiver.peek_messages() sich subtil vom Empfangen unterscheidet, da die angezeigten Nachrichten nicht gesperrt werden und daher nicht abgerechnet werden können.

Senden und Empfangen einer Nachricht aus einer sitzungsaktivierten Warteschlange

HINWEIS: Informationen zum Senden und Empfangen von Sitzungen finden Sie in der Referenzdokumentation.

Sitzungen bieten first-in-first-out- und Single-Receiver-Semantik auf einer Warteschlange oder einem Abonnement. Während die tatsächliche Empfangssyntax identisch ist, unterscheidet sich die Initialisierung geringfügig.

from azure.servicebus import ServiceBusClient, ServiceBusMessage

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_SESSION_QUEUE_NAME']
session_id = os.environ['SERVICE_BUS_SESSION_ID']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_sender(queue_name) as sender:
        sender.send_messages(ServiceBusMessage("Session Enabled Message", session_id=session_id))

    # If session_id is null here, will receive from the first available session.
    with client.get_queue_receiver(queue_name, session_id=session_id) as receiver:
        for msg in receiver:
            print(str(msg))

HINWEIS: Nachrichten, die von einer Sitzung empfangen werden, müssen ihre Sperren nicht wie ein Nicht-Sitzungsempfänger erneuert werden. Stattdessen erfolgt die Sperrverwaltung auf Sitzungsebene mit einer Sitzungssperre, die mit verlängert werden kann receiver.session.renew_lock()

Arbeiten mit Themen und Abonnements

HINWEIS: Informationen zu Themen und Abonnements finden Sie in der Referenzdokumentation.

Themen und Abonnements bieten eine Alternative zu Warteschlangen zum Senden und Empfangen von Nachrichten. Weitere übergreifende Details finden Sie in den Dokumenten hier und darüber, wie sich diese von Warteschlangen unterscheiden.

from azure.servicebus import ServiceBusClient, ServiceBusMessage

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
topic_name = os.environ['SERVICE_BUS_TOPIC_NAME']
subscription_name = os.environ['SERVICE_BUS_SUBSCRIPTION_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_topic_sender(topic_name) as sender:
        sender.send_messages(ServiceBusMessage("Data"))

    # If session_id is null here, will receive from the first available session.
    with client.get_subscription_receiver(topic_name, subscription_name) as receiver:
        for msg in receiver:
            print(str(msg))

Begleichen einer Nachricht nach Dem Empfang

Wenn Sie aus einer Warteschlange empfangen, haben Sie mehrere Aktionen, die Sie für die empfangenen Nachrichten ausführen können.

HINWEIS: Sie können nur Objekte abrechnen ServiceBusReceivedMessage , die im ServiceBusReceiveMode.PEEK_LOCK Modus empfangen werden (dies ist die Standardeinstellung). ServiceBusReceiveMode.RECEIVE_AND_DELETE im Modus wird die Nachricht beim Empfang aus der Warteschlange entfernt. ServiceBusReceivedMessage von peek_messages() zurückgegebene Nachrichten können nicht abgerechnet werden, da die Nachrichtensperre nicht wie in den oben genannten Empfangsmethoden genommen wird.

Wenn die Nachricht wie oben erwähnt über eine Sperre verfügt, schlägt die Abrechnung fehl, wenn die Nachrichtensperre abgelaufen ist. Wenn die Verarbeitung länger als die Sperrdauer dauern würde, muss sie über receiver.renew_message_lock verwaltet werden, bevor sie abläuft. Die Sperrdauer wird in Azure für die Warteschlange oder das Thema selbst festgelegt. Unter AutoLockRenewer finden Sie informationen zu einem Hilfsprogramm, um dies automatisch im Hintergrund auszuführen.

Abgeschlossen

Deklariert die Nachrichtenverarbeitung als erfolgreich abgeschlossen und entfernt die Nachricht aus der Warteschlange.

from azure.servicebus import ServiceBusClient

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        for msg in receiver:
            print(str(msg))
            receiver.complete_message(msg)

Verlassen

Beenden Sie die Verarbeitung der Nachricht vorerst, und geben Sie die Nachricht sofort zurück in die Warteschlange, um von einem anderen (oder demselben) Empfänger empfangen zu werden.

from azure.servicebus import ServiceBusClient

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        for msg in receiver:
            print(str(msg))
            receiver.abandon_message(msg)

DeadLetter

Übertragen Sie die Nachricht aus der primären Warteschlange in eine spezielle "Unterwarteschlange für unzustellbare Nachrichten", auf die sie mithilfe der Funktion mit dem ServiceBusClient.get_<queue|subscription>_receiver Parameter sub_queue=ServiceBusSubQueue.DEAD_LETTER zugegriffen und wie jeder andere Empfänger verwendet werden kann. (siehe Beispiel hier)

from azure.servicebus import ServiceBusClient

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        for msg in receiver:
            print(str(msg))
            receiver.dead_letter_message(msg)

Verzögern

Das Zurückstellen unterscheidet sich subtil von den vorherigen Abrechnungsmethoden. Es verhindert, dass die Nachricht direkt von der Warteschlange empfangen wird, indem sie so festgelegt wird, dass sie in einem Aufruf ServiceBusReceiver.receive_deferred_messages von per Sequenznummer empfangen werden muss (siehe Beispiel hier).

from azure.servicebus import ServiceBusClient

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        for msg in receiver:
            print(str(msg))
            receiver.defer_message(msg)

Automatische Verlängerung von Nachrichten- oder Sitzungssperren

HINWEIS: Siehe Referenzdokumentation zur automatischen Sperrung.

AutoLockRenewer ist eine einfache Methode, um sicherzustellen, dass Ihre Nachricht oder Sitzung auch über einen langen Zeitraum gesperrt bleibt, wenn das Aufrufen receiver.renew_message_lock/receiver.session.renew_lock nicht praktikabel oder unerwünschter Ist. Intern ist es nicht viel mehr als eine Abkürzung für das Erstellen eines gleichzeitigen Watchdogs, um eine Sperrverlängerung auszuführen, wenn sich das Objekt dem Ablauf nähert. Es sollte wie folgt verwendet werden:

  • Automatische Verlängerung der Nachrichtensperre
from azure.servicebus import ServiceBusClient, AutoLockRenewer

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
queue_name = os.environ['SERVICE_BUS_QUEUE_NAME']

# Can also be called via "with AutoLockRenewer() as renewer" to automate closing.
renewer = AutoLockRenewer()
with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(queue_name) as receiver:
        for msg in receiver.receive_messages():
            renewer.register(receiver, msg, max_lock_renewal_duration=60)
            # Do your application logic here
            receiver.complete_message(msg)
renewer.close()
  • Automatische Verlängerung der Sitzungssperre
from azure.servicebus import ServiceBusClient, AutoLockRenewer

import os
connstr = os.environ['SERVICE_BUS_CONNECTION_STR']
session_queue_name = os.environ['SERVICE_BUS_SESSION_QUEUE_NAME']
session_id = os.environ['SERVICE_BUS_SESSION_ID']

# Can also be called via "with AutoLockRenewer() as renewer" to automate closing.
renewer = AutoLockRenewer()
with ServiceBusClient.from_connection_string(connstr) as client:
    with client.get_queue_receiver(session_queue_name, session_id=session_id) as receiver:
        renewer.register(receiver, receiver.session, max_lock_renewal_duration=300) # Duration for how long to maintain the lock for, in seconds.

        for msg in receiver.receive_messages():
            # Do your application logic here
            receiver.complete_message(msg)
renewer.close()

Wenn die automatische Verlängerung aus irgendeinem Grund unterbrochen wurde oder fehlgeschlagen ist, kann dies über die auto_renew_error -Eigenschaft für das Objekt, das erneuert wird, oder durch Übergeben eines Rückrufs an den Parameter bei der on_lock_renew_failure Erneuerungsinitialisierung beobachtet werden. Es würde sich auch manifestieren, wenn versucht wird, Aktionen (z. B. das Abschließen einer Nachricht) für das angegebene Objekt auszuführen.

Problembehandlung

Protokollierung

  • Aktivieren Sie azure.servicebus die Protokollierung, um Ablaufverfolgungen aus der Bibliothek zu sammeln.
  • Aktivieren Sie uamqp die Protokollierung, um Ablaufverfolgungen aus der zugrunde liegenden uAMQP-Bibliothek zu sammeln.
  • Aktivieren Sie die Ablaufverfolgung auf AMQP-Frameebene, indem Sie beim Erstellen des Clients festlegen logging_enable=True .
  • Es gibt Fälle, in denen Sie die uamqp Protokollierung für zu ausführlich halten. Um unnötige Protokollierung zu unterdrücken, fügen Sie den folgenden Codeausschnitt oben im Code hinzu:
import logging

# The logging levels below may need to be changed based on the logging that you want to suppress.
uamqp_logger = logging.getLogger('uamqp')
uamqp_logger.setLevel(logging.ERROR)

# or even further fine-grained control, suppressing the warnings in uamqp.connection module
uamqp_connection_logger = logging.getLogger('uamqp.connection')
uamqp_connection_logger.setLevel(logging.ERROR)

Zeitlimits

Es gibt verschiedene Timeouts, die einem Benutzer innerhalb der Bibliothek bekannt sein sollten.

  • 10 Minuten Service Side Link-Schließung: Ein Link wird nach 10 Minuten im Leerlauf geschlossen, um den Dienst vor Ressourcenlecks zu schützen. Dies sollte für einen Benutzer weitgehend transparent sein, aber wenn Sie feststellen, dass nach einer solchen Dauer eine erneute Verbindung auftritt, ist dies der Grund. Das Ausführen von Vorgängen, einschließlich Verwaltungsvorgängen, für den Link verlängert dieses Timeout.
  • max_wait_time: Wird bei der Erstellung eines Empfängers oder beim Aufrufen receive_messages()angegeben, die Zeit, nach der die empfangenden Nachrichten nach keinem Datenverkehr angehalten werden. Dies gilt sowohl für die imperative receive_messages() Funktion als auch für die Länge, für die ein Generator empfangen wird, bevor er beendet wird, wenn keine Nachrichten vorhanden sind. Das Übergeben von None (Standard) wartet ewig bis zum Schwellenwert von 10 Minuten, wenn keine andere Aktion ausgeführt wird.

HINWEIS: Wenn die Verarbeitung einer Nachricht oder Sitzung ausreichend lang ist, um Timeouts zu verursachen, kann man alternativ zum manuellen Aufrufen receiver.renew_message_lock/receiver.session.renew_lock die AutoLockReneweroben nutzen.

Allgemeine Ausnahmen

Die Service Bus-APIs generieren die folgenden Ausnahmen in azure.servicebus.exceptions:

  • ServiceBusConnectionError: Bei der Verbindung mit dem Dienst ist ein Fehler aufgetreten. Dies kann durch ein vorübergehendes Netzwerk- oder Dienstproblem verursacht worden sein. Es wird empfohlen, es erneut zu versuchen.
  • ServiceBusAuthorizationError: Fehler beim Autorisieren der Verbindung mit dem Dienst. Dies wurde möglicherweise dadurch verursacht, dass die Anmeldeinformationen nicht über die richtige Berechtigung zum Ausführen des Vorgangs verfügten. Es wird empfohlen, die Berechtigung der Anmeldeinformationen zu überprüfen.
  • ServiceBusAuthenticationError: Fehler beim Authentifizieren der Verbindung mit dem Dienst. Dies wurde möglicherweise dadurch verursacht, dass die Anmeldeinformationen falsch waren. Es wird empfohlen, die Anmeldeinformationen zu überprüfen.
  • OperationTimeoutError: Dies gibt an, dass der Dienst nicht innerhalb der erwarteten Zeit auf einen Vorgang reagiert hat. Dies kann durch ein vorübergehendes Netzwerk- oder Dienstproblem verursacht worden sein. Möglicherweise hat der Dienst die Anforderung erfolgreich abgeschlossen; der status ist nicht bekannt. Es wird empfohlen, zu versuchen, den aktuellen Zustand zu überprüfen, und versuchen Sie es bei Bedarf erneut.
  • MessageSizeExceededError: Dies gibt an, dass der Nachrichteninhalt größer als die Service Bus-Framegröße ist. Dies kann vorkommen, wenn zu viele Service Bus-Nachrichten in einem Batch gesendet werden oder der an den Textkörper eines Message übergebene Inhalt zu groß ist. Es wird empfohlen, die Anzahl der nachrichten zu reduzieren, die in einem Batch gesendet werden, oder die Größe des Inhalts, der an eine einzelne ServiceBusMessageübergeben wird.
  • MessageAlreadySettled: Dies deutet darauf hin, dass die Nachricht nicht abgleicht wurde. Dies kann beim Versuch auftreten, eine bereits abgerechnete Nachricht zu beheben.
  • MessageLockLostError: Die Sperre für die Nachricht ist abgelaufen und wurde zurück in die Warteschlange freigegeben. Es muss erneut empfangen werden, um es zu regeln. Sie sollten die Sperrdauer einer Nachricht kennen und die Sperre bei langer Verarbeitungszeit vor ablaufen. AutoLockRenewer kann helfen, die Sperre der Nachricht automatisch zu verlängern.
  • SessionLockLostError: Die Sperre für die Sitzung ist abgelaufen. Alle unaufgeklärten Nachrichten, die empfangen wurden, können nicht mehr beglichen werden. Es wird empfohlen, bei Bedarf erneut eine Verbindung mit der Sitzung herzustellen, wenn Nachrichten erneut empfangen werden. Sie sollten sich der Sperrdauer einer Sitzung bewusst sein und die Sperre bei langer Verarbeitungszeit vor ablaufen. AutoLockRenewer könnte helfen, die Sperre der Sitzung automatisch zu verlängern.
  • MessageNotFoundError: Versuchen Sie, eine Nachricht mit einer bestimmten Sequenznummer zu erhalten. Diese Nachricht wurde nicht gefunden. Stellen Sie sicher, dass die Nachricht nicht bereits empfangen wurde. Überprüfen Sie in der Warteschlange für unzustellbare Nachrichten, ob die Nachricht als unzustellbar gekennzeichnet wurde.
  • MessagingEntityNotFoundError: Die dem Vorgang zugeordnete Entität ist nicht vorhanden oder wurde gelöscht. Stellen Sie sicher, dass die Entität vorhanden ist.
  • MessagingEntityDisabledError: Anforderung eines Laufzeitvorgangs für eine deaktivierte Entität. Aktivieren Sie die Entität.
  • ServiceBusQuotaExceededError: Die Messagingentität hat ihre maximal zulässige Größe erreicht, oder die maximale Anzahl von Verbindungen mit einem Namespace wurde überschritten. Schaffen Sie Platz in der Entität, indem Sie Nachrichten aus der Entität oder ihren Unterwarteschlangen empfangen.
  • ServiceBusServerBusyError: Der Dienst kann die Anforderung derzeit nicht verarbeiten. Der Client kann eine gewisse Zeit warten und dann den Vorgang wiederholen.
  • ServiceBusCommunicationError: Der Client kann keine Verbindung mit Service Bus herstellen. Stellen Sie sicher, dass der angegebene Hostname richtig und der Host erreichbar ist. Falls Ihr Code in einer Umgebung mit einer Firewall oder einem Proxy ausgeführt wird, stellen Sie sicher, dass der für die Service Bus-Domäne/IP-Adresse und -Ports bestimmte Datenverkehr nicht blockiert wird.
  • SessionCannotBeLockedError: Versuchen Sie, eine Verbindung mit einer Sitzung mit einer bestimmten Sitzungs-ID herzustellen, aber die Sitzung ist derzeit von einem anderen Client gesperrt. Stellen Sie sicher, dass die Sperre für die Sitzung von den anderen Clients aufgehoben wird.
  • AutoLockRenewFailed: Der Versuch, eine Sperre für eine Nachricht oder Sitzung im Hintergrund zu verlängern, ist fehlgeschlagen. Dies kann passieren, wenn der von AutoLockRenewer verwendete Empfänger geschlossen ist oder die Sperre der erneuerbaren Ressource abgelaufen ist. Es wird empfohlen, die erneuerbare Nachricht oder Sitzung erneut zu registrieren, indem Sie die Nachricht empfangen oder erneut eine Verbindung mit der sitzungsbehafteten Entität herstellen.
  • AutoLockRenewTimeout: Die Zeit, die zum Erneuern der Nachricht oder Sitzungssperre zugewiesen wurde, ist verstrichen. Sie können das Objekt erneut registrieren, für das die automatische Sperre erneuert werden soll, oder das Timeout im Voraus verlängern.
  • ServiceBusError: Alle anderen Service Bus-bezogenen Fehler. Dies ist die Stammfehlerklasse aller oben beschriebenen Fehler.

Ausführliche Beschreibungen unserer gängigen Ausnahmetypen finden Sie in der Referenzdokumentation zu Ausnahmen .

Nächste Schritte

Weiterer Beispielcode

Weitere Beispiele finden Sie im Beispielverzeichnis , das gängige Service Bus-Szenarien wie Senden, Empfangen, Sitzungsverwaltung und Nachrichtenverarbeitung veranschaulicht.

Zusätzliche Dokumentation

Eine ausführlichere Dokumentation zum Service Bus-Dienst finden Sie in der Service Bus-Dokumentation auf docs.microsoft.com.

Verwaltungsfunktionen und Dokumentation

Benutzer, die Verwaltungsvorgänge für ServiceBus ausführen möchten (Erstellen einer Warteschlange/eines Themas/etc, Ändern von Filterregeln, Auflisten von Entitäten) finden Sie in der Dokumentation zu azure-mgmt-servicebus für die API-Dokumentation. Beispiele für die Verwendung von Terse finden Sie auch hier .

Pure Python AMQP-Transport und Abwärtskompatibilitätsunterstützung

Die Azure Service Bus-Clientbibliothek basiert jetzt auf einer reinen Python-AMQP-Implementierung. uAMQP wurde als erforderliche Abhängigkeit entfernt.

So verwenden Sie uAMQP als zugrunde liegenden Transport:

  1. Installieren Sie uamqp mit pip.
$ pip install uamqp
  1. Passieren Sie uamqp_transport=True während des Baus des Kunden.
from azure.servicebus import ServiceBusClient
connection_str = '<< CONNECTION STRING FOR THE SERVICE BUS NAMESPACE >>'
queue_name = '<< NAME OF THE QUEUE >>'
client = ServiceBusClient.from_connection_string(
    connection_str, uamqp_transport=True
)

Hinweis: Das message Attribut auf ServiceBusMessage//ServiceBusMessageBatchServiceBusReceivedMessage, das zuvor verfügbar gemacht uamqp.Messagehat, ist veraltet. Die vom message Attribut zurückgegebenen "Legacy"-Objekte wurden eingeführt, um den Übergang zu erleichtern.

Erstellen des uAMQP-Rads aus der Quelle

azure-servicebus hängt vom uAMQP für die AMQP-Protokollimplementierung ab. uAMQP-Räder werden für die meisten gängigen Betriebssysteme bereitgestellt und bei der Installation azure-servicebusautomatisch installiert. Wenn uAMQP als zugrunde liegende AMQP-Protokollimplementierung für azure-servicebusverwendet werden soll, können uAMQP-Räder für die meisten wichtigen Betriebssysteme gefunden werden.

Wenn Sie auf einer Plattform laufen, für die uAMQP-Räder nicht bereitgestellt werden, folgen Sie bitte den Anweisungen unter Wenn Sie beabsichtigen, zu verwenden und sie auf einer Plattform zu verwenden uAMQP , für die uAMQP-Räder nicht bereitgestellt werden, befolgen Sie die Anleitung zur uAMQP-Installation , um sie von der Quelle aus zu installieren.

Mitwirken

Beiträge und Vorschläge für dieses Projekt sind willkommen. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. Ausführliche Informationen finden Sie unter https://cla.microsoft.com.

Wenn Sie einen Pull Request (PR) übermitteln, überprüft ein CLA-Bot automatisch, ob Sie eine Lizenzvereinbarung bereitstellen und den PR entsprechend ergänzen müssen (z.B. mit einer Bezeichnung oder einem Kommentar). Führen Sie einfach die Anweisungen des Bots aus. Sie müssen dies nur einmal für alle Repositorys ausführen, die unsere CLA verwenden.

Für dieses Projekt gelten die Microsoft-Verhaltensregeln für Open Source (Microsoft Open Source Code of Conduct). Weitere Informationen finden Sie in den häufig gestellten Fragen zum Verhaltenskodex. Sie können sich auch an opencode@microsoft.com wenden, wenn Sie weitere Fragen oder Anmerkungen haben.