Partager via


bibliothèque de client Azure Service Bus pour Python - version 7.11.4

Azure Service Bus est un service de messagerie géré dans le cloud hautes performances qui fournit une communication en temps réel et tolérante aux pannes entre les expéditeurs et les récepteurs distribués.

Service Bus fournit plusieurs mécanismes pour une communication asynchrone hautement fiable, comme la messagerie structurée premier entrée-premier sorti, les fonctionnalités de publication/d’abonnement et la possibilité de mettre facilement à l’échelle à mesure que vos besoins augmentent.

Utilisez la bibliothèque cliente Service Bus pour Python afin de communiquer entre les applications et les services et d’implémenter des modèles de messagerie asynchrone.

  • Créez des espaces de noms, des files d’attente, des rubriques et des abonnements Service Bus et modifiez leurs paramètres.
  • Envoyer et recevoir des messages dans vos canaux Service Bus.
  • Utilisez des verrous de message, des sessions et des fonctionnalités de lettres mortes pour implémenter des modèles de messagerie complexes.

| Code sourcePackage (PyPi) | Package (Conda) | Documentation de référence sur les | API | Documentation produitÉchantillons | Changelog

REMARQUE : Si vous utilisez la version 0.50 ou une version antérieure et que vous souhaitez migrer vers la dernière version de ce package, consultez notre guide de migration pour passer de Service Bus V0.50 à Service Bus V7.

Prise en main

Installer le package

Installez la bibliothèque cliente Azure Service Bus pour Python avec pip :

pip install azure-servicebus

Configuration requise :

Pour utiliser ce package, vous devez disposer des conditions suivantes :

Si vous avez besoin d’un espace de noms Azure Service Bus, vous pouvez le créer via le portail Azure. Si vous ne souhaitez pas utiliser l’interface utilisateur du portail graphique, vous pouvez utiliser Azure CLI via Cloud Shell ou l’interface azure CLI exécutée localement pour en créer une à l’aide de cette commande Azure CLI :

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

Authentifier le client

L’interaction avec Service Bus commence par une instance de la ServiceBusClient classe . Vous avez besoin d’un chaîne de connexion avec une clé SAS, ou d’un espace de noms et de l’une de ses clés de compte pour instancier l’objet client. Recherchez les exemples liés ci-dessous pour une démonstration de l’authentification via l’une ou l’autre approche.

Créer un client à partir de chaîne de connexion

  • Pour obtenir les informations d’identification requises, vous pouvez utiliser l’extrait de code Azure CLI (mis en forme pour Bash Shell) en haut de l’exemple lié pour remplir une variable d’environnement avec l’chaîne de connexion Service Bus (vous pouvez également trouver ces valeurs dans le portail Azure en suivant le guide pas à pas pour Obtenir une chaîne de connexion Service Bus).

Créez un client à l’aide de la bibliothèque azure-identity :

  • Ce constructeur accepte l’espace de noms complet de votre instance Service Bus et des informations d’identification qui implémentent le protocole TokenCredential. Des implémentations du TokenCredential protocole sont disponibles dans le package azure-identity. L’espace de noms complet est au format <yournamespace.servicebus.windows.net>.
  • Pour utiliser les types d’informations d’identification fournis par azure-identity, installez le package : pip install azure-identity
  • En outre, pour utiliser l’API asynchrone, vous devez d’abord installer un transport asynchrone, tel que aiohttp: pip install aiohttp
  • Lorsque vous utilisez Azure Active Directory, votre principal doit se voir attribuer un rôle qui autorise l’accès à Service Bus, tel que le rôle Propriétaire de données Azure Service Bus. Pour plus d’informations sur l’utilisation de l’autorisation Azure Active Directory avec Service Bus, reportez-vous à la documentation associée.

Remarque : le client peut être initialisé sans gestionnaire de contexte, mais doit être fermé manuellement via client.close() pour ne pas fuiter de ressources.

Concepts clés

Une fois que vous avez initialisé un ServiceBusClient, vous pouvez interagir avec les types de ressources principaux au sein d’un espace de noms Service Bus, dont plusieurs peuvent exister et sur lesquels la transmission de messages réelle a lieu, l’espace de noms servant souvent de conteneur d’application :

  • File d’attente : autorise l’envoi et la réception de messages. Souvent utilisé pour la communication point à point.

  • Rubrique : Contrairement aux files d’attente, les rubriques sont mieux adaptées aux scénarios de publication/abonnement. Une rubrique peut être envoyée à, mais nécessite un abonnement, dont il peut y avoir plusieurs en parallèle, à utiliser.

  • Abonnement : mécanisme à utiliser à partir d’une rubrique. Chaque abonnement est indépendant et reçoit une copie de chaque message envoyé à la rubrique. Les règles et les filtres peuvent être utilisés pour personnaliser les messages reçus par un abonnement spécifique.

Pour plus d’informations sur ces ressources, consultez Qu’est-ce que Azure Service Bus ?.

Pour interagir avec ces ressources, vous devez être familiarisé avec les concepts suivants du Kit de développement logiciel (SDK) :

  • ServiceBusClient : il s’agit de l’objet qu’un utilisateur doit d’abord initialiser pour se connecter à un espace de noms Service Bus. Pour interagir avec une file d’attente, une rubrique ou un abonnement, vous devez générer un expéditeur ou un récepteur hors de ce client.

  • ServiceBusSender : pour envoyer des messages à une file d’attente ou une rubrique, vous devez utiliser la méthode correspondante get_queue_sender ou get_topic_sender hors d’un ServiceBusClient instance comme indiqué ici.

  • ServiceBusReceiver : pour recevoir des messages d’une file d’attente ou d’un abonnement, vous devez utiliser la méthode correspondante get_queue_receiver ou get_subscription_receiver hors d’un ServiceBusClient instance comme indiqué ici.

  • ServiceBusMessage : lors de l’envoi, il s’agit du type que vous allez construire pour contenir votre charge utile. Lors de la réception, c’est là que vous accéderez à la charge utile.

Sécurité des threads

Nous ne garantissons pas que ServiceBusClient, ServiceBusSender et ServiceBusReceiver sont thread-safe. Nous vous déconseillons de réutiliser ces instances entre les threads. Il appartient à l’application en cours d’exécution d’utiliser ces classes de manière thread-safe.

Exemples

Les sections suivantes fournissent plusieurs extraits de code couvrant certaines des tâches Service Bus les plus courantes, notamment :

Pour effectuer des tâches de gestion telles que la création et la suppression de files d’attente/rubriques/abonnements, utilisez la bibliothèque azure-mgmt-servicebus, disponible ici.

Vous trouverez d’autres exemples dans le répertoire d’exemples illustrant des scénarios Service Bus courants tels que l’envoi, la réception, la gestion des sessions et la gestion des messages.

Envoi de messages à une file d'attente

REMARQUE : consultez la documentation de référence ici.

Cet exemple envoie un seul message et un tableau de messages à une file d’attente supposée exister, créée via les commandes Portail Azure ou az.

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)

NOTE: Un message peut être planifié pour une remise différée à l’aide de la ServiceBusSender.schedule_messages() méthode ou en spécifiant avant d’appeler ServiceBusMessage.scheduled_enqueue_time_utcServiceBusSender.send_messages()

Pour plus d’informations sur la planification et l’annulation de planification, consultez un exemple ici.

Réception des messages d'une file d'attente

Pour recevoir à partir d’une file d’attente, vous pouvez effectuer une réception ad hoc via receiver.receive_messages() ou recevoir de manière permanente via le récepteur lui-même.

Recevoir des messages d’une file d’attente via une itération sur 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.

NOTE: Tout message reçu avec receive_mode=PEEK_LOCK (il s’agit de la valeur par défaut, avec l’autre RECEIVE_AND_DELETE la suppression du message de la file d’attente immédiatement à la réception) a un verrou qui doit être renouvelé via receiver.renew_message_lock avant d’expirer si le traitement prend plus de temps que la durée de verrouillage. Pour qu’une assistance effectue automatiquement cette opération en arrière-plan, consultez AutoLockRenewer . La durée de verrouillage est définie dans Azure sur la file d’attente ou la rubrique elle-même.

Recevoir des messages d’une file d’attente via ServiceBusReceiver.receive_messages()

NOTE:ServiceBusReceiver.receive_messages() reçoit une liste unique ou contrainte de messages par le biais d’un appel de méthode ad hoc, au lieu de recevoir perpétuellement du générateur. Elle retourne toujours une liste.

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))

Dans cet exemple, max_message_count déclare le nombre maximal de messages à recevoir avant d’atteindre un max_wait_time comme spécifié en secondes.

NOTE: Il convient également de noter que ServiceBusReceiver.peek_messages() est subtilement différent de la réception, car il ne verrouille pas les messages en cours d’accès, et donc ils ne peuvent pas être réglés.

Envoyer et recevoir un message à partir d’une file d’attente activée pour la session

REMARQUE : consultez la documentation de référence pour l’envoi et la réception de session.

Les sessions fournissent une sémantique premier entrant, premier sorti et un récepteur unique au-dessus d’une file d’attente ou d’un abonnement. Bien que la syntaxe de réception réelle soit la même, l’initialisation diffère légèrement.

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))

REMARQUE : Les messages reçus d’une session n’ont pas besoin que leurs verrous sont renouvelés comme un récepteur non-session ; au lieu de cela, la gestion des verrous se produit au niveau de la session avec un verrou de session qui peut être renouvelé avec receiver.session.renew_lock()

Utilisation des rubriques et des abonnements

REMARQUE : consultez la documentation de référence pour les rubriques et les abonnements.

Les rubriques et les abonnements offrent une alternative aux files d’attente pour l’envoi et la réception de messages. Consultez les documents ici pour obtenir des détails plus globaux et sur la façon dont ceux-ci diffèrent des files d’attente.

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))

Régler un message après réception

Lorsque vous recevez à partir d’une file d’attente, vous avez plusieurs actions que vous pouvez effectuer sur les messages que vous recevez.

REMARQUE : vous pouvez uniquement régler les ServiceBusReceivedMessage objets qui sont reçus en ServiceBusReceiveMode.PEEK_LOCK mode (il s’agit de la valeur par défaut). ServiceBusReceiveMode.RECEIVE_AND_DELETE le mode supprime le message de la file d’attente lors de la réception. ServiceBusReceivedMessage les messages retournés par peek_messages() ne peuvent pas être réglés, car le verrou de message n’est pas pris comme dans les méthodes de réception mentionnées ci-dessus.

Si le message a un verrou comme mentionné ci-dessus, le règlement échoue si le verrou de message a expiré. Si le traitement prend plus de temps que la durée de verrouillage, il doit être conservé via receiver.renew_message_lock avant d’expirer. La durée de verrouillage est définie dans Azure sur la file d’attente ou la rubrique elle-même. Pour qu’une assistance effectue automatiquement cette opération en arrière-plan, consultez AutoLockRenewer .

Terminé

Déclare le traitement du message terminé, en supprimant le message de la file d’attente.

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)

Arrêter

Abandonnez le traitement du message pour le moment, renvoyant le message immédiatement dans la file d’attente pour qu’il soit récupéré par un autre (ou le même) récepteur.

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

Transférez le message de la file d’attente principale dans une « sous-file d’attente de lettres mortes » spéciale où il est accessible à l’aide de la fonction avec le ServiceBusClient.get_<queue|subscription>_receiver paramètre sub_queue=ServiceBusSubQueue.DEAD_LETTER et consommé à partir de n’importe quel autre récepteur. (voir l’exemple ici)

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)

Defer

Le report est subtilement différent des méthodes de règlement antérieures. Il empêche la réception directe du message à partir de la file d’attente en le mettant de côté afin qu’il soit reçu par numéro de séquence dans un appel à ServiceBusReceiver.receive_deferred_messages (voir l’exemple ici)

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)

Renouveler automatiquement les verrous de message ou de session

REMARQUE : consultez la documentation de référence pour le verrouillage automatique-renouvellement.

AutoLockRenewer est une méthode simple permettant de s’assurer que votre message ou session reste verrouillé même sur de longues périodes, si l’appel receiver.renew_message_lock/receiver.session.renew_lock n’est pas pratique ou n’est pas souhaité. En interne, il n’est pas beaucoup plus court que la création d’un chien de garde simultané pour effectuer le renouvellement de verrou si l’objet arrive à expiration. Il doit être utilisé comme suit :

  • Renouvellement automatique du verrouillage des messages
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()
  • Renouvellement automatique du verrouillage de session
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()

Si, pour une raison quelconque, le renouvellement automatique a été interrompu ou a échoué, cela peut être observé via la auto_renew_error propriété sur l’objet en cours de renouvellement, ou en ayant passé un rappel au paramètre lors de l’initialisation on_lock_renew_failure du renouvellement. Il se manifeste également lors de la tentative d’action (par exemple, la fin d’un message) sur l’objet spécifié.

Résolution des problèmes

Journalisation

  • Activez l’enregistreur azure.servicebus d’événements pour collecter des traces à partir de la bibliothèque.
  • Activez l’enregistreur uamqp d’événements pour collecter des traces à partir de la bibliothèque uAMQP sous-jacente.
  • Activez la trace au niveau du frame AMQP en définissant logging_enable=True lors de la création du client.
  • Dans certains cas, vous considérez que la uamqp journalisation est trop détaillée. Pour supprimer la journalisation inutile, ajoutez l’extrait de code suivant en haut de votre code :
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)

Délais d’expiration

Il existe différents délais d’expiration qu’un utilisateur doit connaître dans la bibliothèque.

  • Fermeture du lien côté service de 10 minutes : une liaison, une fois ouverte, est fermée après 10 minutes d’inactivité pour protéger le service contre les fuites de ressources. Cela doit être en grande partie transparent pour un utilisateur, mais si vous remarquez qu’une reconnexion se produit après une telle durée, c’est pourquoi. L’exécution de toutes les opérations, y compris les opérations de gestion, sur le lien étend ce délai d’expiration.
  • max_wait_time : fourni lors de la création d’un récepteur ou lors de l’appel receive_messages()de , heure après laquelle la réception des messages s’arrête après l’absence de trafic. Cela s’applique à la fonction impérative receive_messages() ainsi qu’à la longueur pendant laquelle une réception de style générateur s’exécutera avant de quitter s’il n’y a aucun message. Le passage de None (valeur par défaut) attendra indéfiniment, jusqu’au seuil de 10 minutes si aucune autre action n’est effectuée.

NOTE: Si le traitement d’un message ou d’une session est suffisamment long pour provoquer des délais d’expiration, comme alternative à l’appel receiver.renew_message_lock/receiver.session.renew_lock manuel, vous pouvez tirer parti AutoLockRenewer des fonctionnalités ci-dessus.

Exceptions courantes

Les API Service Bus génèrent les exceptions suivantes dans azure.servicebus.exceptions :

  • ServiceBusConnectionError : Une erreur s’est produite dans la connexion au service. Cela peut être dû à un problème réseau temporaire ou à un problème de service. Il est recommandé de réessayer.
  • ServiceBusAuthorizationError : Une erreur s’est produite lors de l’autorisation de la connexion au service. Cela peut être dû au fait que les informations d’identification ne disposent pas de l’autorisation appropriée pour effectuer l’opération. Il est recommandé de case activée l’autorisation des informations d’identification.
  • ServiceBusAuthenticationError : Une erreur s’est produite lors de l’authentification de la connexion au service. Cela peut être dû au fait que les informations d’identification étaient incorrectes. Il est recommandé de case activée les informations d’identification.
  • OperationTimeoutError : Cela indique que le service n’a pas répondu à une opération dans le délai prévu. Cela peut être dû à un problème réseau temporaire ou à un problème de service. Le service a peut-être réussi ou non la demande ; le status n’est pas connu. Il est recommandé d’essayer de vérifier l’état actuel et de réessayer si nécessaire.
  • MessageSizeExceededError : Cela indique que le contenu du message est supérieur à la taille de trame service bus. Cela peut se produire lorsque trop de messages Service Bus sont envoyés dans un lot ou que le contenu transmis dans le corps d’un Message est trop volumineux. Il est recommandé de réduire le nombre de messages envoyés dans un lot ou la taille du contenu passé dans un seul ServiceBusMessage.
  • MessageAlreadySettled : Cela indique l’échec du règlement du message. Cela peut se produire lors de la tentative de règlement d’un message déjà réglé.
  • MessageLockLostError : Le verrou sur le message a expiré et il a été relâché dans la file d’attente. Il devra être reçu à nouveau pour le régler. Vous devez être conscient de la durée de verrouillage d’un message et continuer à renouveler le verrou avant l’expiration en cas de temps de traitement long. AutoLockRenewer peut vous aider à maintenir le verrouillage du message automatiquement renouvelé.
  • SessionLockLostError : Le verrou de la session a expiré. Tous les messages non réglés qui ont été reçus ne peuvent plus être réglés. Il est recommandé de se reconnecter à la session si nécessaire, si nécessaire, recevez à nouveau des messages. Vous devez être conscient de la durée de verrouillage d’une session et continuer à renouveler le verrou avant l’expiration en cas de temps de traitement long. AutoLockRenewer pourrait vous aider à maintenir le verrouillage de la session automatiquement renouvelé.
  • MessageNotFoundError : Essayez de recevoir un message avec un numéro de séquence particulier. Ce message est introuvable. Vérifiez que le message n’a pas déjà été reçu. Vérifiez la file d'attente de lettres mortes pour voir si le message a été désactivé.
  • MessagingEntityNotFoundError : L’entité associée à l’opération n’existe pas ou elle a été supprimée. Vérifiez que l’entité existe.
  • MessagingEntityDisabledError : Demande d’une opération d’exécution sur une entité désactivée. Activez l’entité.
  • ServiceBusQuotaExceededError : L’entité de messagerie a atteint sa taille maximale autorisée ou le nombre maximal de connexions à un espace de noms a été dépassé. Créez de l’espace dans l’entité en recevant des messages à partir de l’entité ou de ses files d’attente secondaires.
  • ServiceBusServerBusyError : Le service ne peut pas traiter la demande pour l’instant. Le client peut attendre pendant une période de temps, puis recommencer l'opération.
  • ServiceBusCommunicationError : Le client n’est pas en mesure d’établir une connexion à Service Bus. Assurez-vous que le nom d'hôte fourni est correct et que l'hôte est accessible. Si votre code s’exécute dans un environnement avec un pare-feu/proxy, assurez-vous que le trafic vers le domaine Service Bus/l’adresse IP et les ports n’est pas bloqué.
  • SessionCannotBeLockedError : Essayez de vous connecter à une session avec un ID de session spécifique, mais la session est actuellement verrouillée par un autre client. Assurez-vous que la session est déverrouillée par les autres clients.
  • AutoLockRenewFailed : Une tentative de renouvellement d’un verrou sur un message ou une session en arrière-plan a échoué. Cela peut se produire lorsque le récepteur utilisé par AutoLockRenewer est fermé ou que le verrou du renouvelable a expiré. Il est recommandé de réinscrire le message ou la session renouvelable en recevant le message ou de vous reconnecter à l’entité de session.
  • AutoLockRenewTimeout : Le temps alloué au renouvellement du message ou du verrou de session s’est écoulé. Vous pouvez réinscrire l’objet qui souhaite que le verrouillage automatique soit renouvelé ou prolonger le délai d’expiration à l’avance.
  • ServiceBusError : Toutes les autres erreurs liées à Service Bus. Il s’agit de la classe d’erreur racine de toutes les erreurs décrites ci-dessus.

Consultez la documentation de référence sur les exceptions pour obtenir des descriptions détaillées de nos types d’exceptions courants.

Étapes suivantes

Autres exemples de code

Vous trouverez d’autres exemples dans le répertoire d’exemples illustrant des scénarios Service Bus courants tels que l’envoi, la réception, la gestion des sessions et la gestion des messages.

Documentation complémentaire

Pour obtenir une documentation plus complète sur le service Service Bus, consultez la documentation Service Bus sur docs.microsoft.com.

Fonctionnalités de gestion et documentation

Pour les utilisateurs qui souhaitent effectuer des opérations de gestion sur ServiceBus (création d’une file d’attente/rubrique/etc., modification des règles de filtre, énumération d’entités), consultez la documentation azure-mgmt-servicebus pour la documentation sur les API. Vous trouverez également des exemples d’utilisation terse ici.

Prise en charge du transport et de la compatibilité descendante Pure Python AMQP

La bibliothèque cliente Azure Service Bus est désormais basée sur une implémentation pure de Python AMQP. uAMQP a été supprimé en tant que dépendance requise.

À utiliser uAMQP comme transport sous-jacent :

  1. Installez uamqp avec pip.
$ pip install uamqp
  1. Passer pendant la uamqp_transport=True construction du client.
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
)

Remarque : l’attribut message surServiceBusMessageBatch//ServiceBusMessageServiceBusReceivedMessage , qui exposait précédemment le uamqp.Message, a été déprécié. Les objets « hérités » retournés par message l’attribut ont été introduits pour faciliter la transition.

Génération d’une roue uAMQP à partir de la source

azure-servicebus dépend de l’uAMQP pour l’implémentation du protocole AMQP. Les roues uAMQP sont fournies pour la plupart des principaux systèmes d’exploitation et sont installées automatiquement lors de l’installation azure-servicebusde . Si uAMQP est destiné à être utilisé comme implémentation du protocole AMQP sous-jacent pour azure-servicebus, les roues uAMQP sont disponibles pour la plupart des principaux systèmes d’exploitation.

Si vous exécutez sur une plateforme pour laquelle les roues uAMQP ne sont pas fournies, suivez si vous avez l’intention d’utiliser uAMQP et que vous exécutez sur une plateforme pour laquelle les roues uAMQP ne sont pas fournies, suivez les instructions d’installation d’uAMQP pour l’installation à partir de la source.

Contribution

Ce projet accepte les contributions et les suggestions. La plupart des contributions vous demandent d’accepter un contrat de licence de contribution (CLA) déclarant que vous avez le droit de nous accorder, et que vous nous accordez réellement, les droits d’utilisation de votre contribution. Pour plus d’informations, visitez https://cla.microsoft.com.

Quand vous envoyez une demande de tirage (pull request), un bot CLA détermine automatiquement si vous devez fournir un contrat CLA et agrémenter la demande de tirage de façon appropriée (par exemple, avec une étiquette ou un commentaire). Suivez simplement les instructions fournies par le bot. Vous ne devez effectuer cette opération qu’une seule fois sur tous les dépôts utilisant notre contrat CLA.

Ce projet a adopté le Code de conduite Open Source de Microsoft. Pour plus d’informations, consultez les Questions fréquentes (FAQ) sur le code de conduite ou envoyez vos questions ou vos commentaires à opencode@microsoft.com.