Azure Service Bus bibliothèque de client pour .NET - version 7.16.2

Article
10/11/2023

Azure Service Bus vous permet de créer des applications qui tirent parti des modèles de messagerie asynchrone à l’aide d’un service hautement fiable pour répartir les messages entre les producteurs et les consommateurs. Azure Service Bus fournit une messagerie répartie flexible entre le client et le serveur, ainsi qu’une messagerie FIFO (premier entré, premier sorti) structurée et des fonctionnalités de publication/abonnement avec un routage complexe. Si vous souhaitez en savoir plus sur Azure Service Bus, vous pouvez consulter : Qu’est-ce que Azure Service Bus ?

Utilisez la bibliothèque cliente pour Azure Service Bus pour :

Transférer des données métier : tirez parti de la messagerie pour un échange durable d’informations, comme les ventes ou les bons de commande, les journaux ou les mouvements d’inventaire.
Dissocier les applications : améliorez la fiabilité et la scalabilité des applications et des services, ce qui soulage les expéditeurs et les destinataires de la nécessité d’être en ligne en même temps.
Contrôler la façon dont les messages sont traités : prendre en charge les consommateurs concurrents traditionnels pour les messages à l’aide de files d’attente ou autoriser chaque consommateur à instance d’un message à l’aide de rubriques et d’abonnements.
Implémenter des workflows complexes : les sessions de messages prennent en charge les scénarios qui nécessitent un ordre de message ou un report de message.

Prise en main

Prérequis

Abonnement Microsoft Azure : Pour utiliser les services Azure, y compris Azure Service Bus, vous avez besoin d’un abonnement. Si vous n’avez pas de compte Azure existant, vous pouvez vous inscrire à un essai gratuit ou utiliser les avantages de votre abonné MSDN lorsque vous créez un compte.
Espace de noms Service Bus : Pour interagir avec Azure Service Bus, vous devez également disposer d’un espace de noms. Si vous n’êtes pas familiarisé avec la création de ressources Azure, vous pouvez suivre le guide pas à pas pour créer un espace de noms Service Bus à l’aide de la Portail Azure. Vous y trouverez également des instructions détaillées sur l’utilisation des modèles Azure CLI, Azure PowerShell ou Azure Resource Manager (ARM) pour créer une entité Service bus.
C# 8.0 : La bibliothèque cliente Azure Service Bus utilise les nouvelles fonctionnalités introduites dans C# 8.0. Pour tirer parti de la syntaxe C# 8.0, il est recommandé de compiler à l’aide du SDK .NET Core 3.0 ou version ultérieure avec une version de langage de latest.

Les utilisateurs de Visual Studio qui souhaitent tirer pleinement parti de la syntaxe C# 8.0 devront utiliser Visual Studio 2019 ou version ultérieure. Visual Studio 2019, y compris l’édition Community gratuite, est téléchargeable ici. Les utilisateurs de Visual Studio 2017 peuvent tirer parti de la syntaxe C# 8 en utilisant le package NuGet Microsoft.Net.Compilers et en définissant la version du langage, bien que l’expérience d’édition ne soit pas idéale.

Vous pouvez toujours utiliser la bibliothèque avec les versions précédentes du langage C#, mais vous devez gérer manuellement les membres asynchrones énumérables et asynchrones jetables au lieu de tirer parti de la nouvelle syntaxe. Vous pouvez toujours cibler n’importe quelle version de framework prise en charge par votre SDK .NET Core, y compris les versions antérieures de .NET Core ou du .NET Framework. Pour plus d’informations, consultez : comment spécifier des frameworks cibles.

Remarque importante : Pour générer ou exécuter les exemples et les exemples sans modification, l’utilisation de C# 8.0 est obligatoire. Vous pouvez toujours exécuter les exemples si vous décidez de les adapter à d’autres versions linguistiques.

Pour créer rapidement les ressources Service Bus nécessaires dans Azure et recevoir un chaîne de connexion pour celles-ci, vous pouvez déployer notre exemple de modèle en cliquant sur :

Installer le package

Installez la bibliothèque de client Azure Service Bus pour .NET avec NuGet :

dotnet add package Azure.Messaging.ServiceBus

Authentifier le client

Pour que la bibliothèque cliente Service Bus interagisse avec une file d’attente ou une rubrique, elle doit comprendre comment se connecter et autoriser avec elle. Le moyen le plus simple consiste à utiliser un chaîne de connexion, qui est créé automatiquement lors de la création d’un espace de noms Service Bus. Si vous n’êtes pas familiarisé avec les stratégies d’accès partagé dans Azure, vous pouvez suivre le guide pas à pas pour obtenir une chaîne de connexion Service Bus.

Une fois que vous avez un chaîne de connexion, vous pouvez authentifier votre client avec celui-ci.

// Create a ServiceBusClient that will authenticate using a connection string
string connectionString = "<connection_string>";
await using var client = new ServiceBusClient(connectionString);

Pour savoir comment s’authentifier à l’aide d’Azure.Identity, consultez cet exemple.

Pour obtenir des exemples d’authentification pour une application ASP.NET Core, consultez cet exemple.

Pour savoir comment initier la connexion avec un point de terminaison personnalisé, consultez cet exemple.

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

Un client Service Bus est l’interface principale pour les développeurs qui interagissent avec la bibliothèque cliente Service Bus. Il sert de passerelle à partir de laquelle toutes les interactions avec la bibliothèque se produisent.
Un expéditeur Service Bus est limité à une file d’attente ou une rubrique particulière, et est créé à l’aide du client Service Bus. L’expéditeur vous permet d’envoyer des messages à une file d’attente ou à une rubrique. Il permet également de planifier la remise des messages à une date spécifiée.
Un récepteur Service Bus est limité à une file d’attente ou un abonnement particulier et est créé à l’aide du client Service Bus. Le récepteur vous permet de recevoir des messages d’une file d’attente ou d’un abonnement. Il permet également de régler les messages après les avoir reçus. Il existe quatre façons de régler les messages :
- Terminé : entraîne la suppression du message de la file d’attente ou de la rubrique.
- Abandon : libère le verrou du récepteur sur le message, ce qui permet à d’autres récepteurs de recevoir le message.
- Différer : diffère la réception du message par des moyens normaux. Pour recevoir des messages différés, le numéro de séquence du message doit être conservé.
- DeadLetter : déplace le message dans la file d’attente lettres mortes. Cela empêchera la réception du message à nouveau. Pour recevoir des messages de la file d’attente lettres mortes, un récepteur limité à la file d’attente lettres mortes est nécessaire.
Un récepteur de session Service Bus est limité à une file d’attente ou un abonnement pour session particulier, et est créé à l’aide du client Service Bus. Le récepteur de session est presque identique au récepteur standard, à la différence près que les opérations de gestion de session sont exposées, qui s’appliquent uniquement aux entités activées pour la session. Ces opérations incluent l’obtention et la définition de l’état de session, ainsi que le renouvellement des verrous de session.
Un processeur Service Bus est limité à une file d’attente ou un abonnement particulier et est créé à l’aide du client Service Bus. Le ServiceBusProcessor peut être considéré comme une abstraction autour d’un ensemble de récepteurs. Il utilise un modèle de rappel pour autoriser la spécification du code lors de la réception d’un message et lorsqu’une exception se produit. Il offre l’achèvement automatique des messages traités, le renouvellement automatique des verrous de message et l’exécution simultanée des gestionnaires d’événements spécifiés par l’utilisateur. En raison de son ensemble de fonctionnalités, il doit s’agir de l’outil d’écriture d’applications qui reçoivent des entités Service Bus. ServiceBusReceiver est recommandé pour les scénarios plus complexes dans lesquels le processeur n’est pas en mesure de fournir le contrôle précis que l’on peut attendre lors de l’utilisation directe de ServiceBusReceiver.
Un processeur de session Service Bus est limité à une file d’attente ou un abonnement pour session particulier, et est créé à l’aide du client Service Bus. Le processeur de session est presque identique au processeur standard, à la différence près que les opérations de gestion de session sont exposées, qui s’appliquent uniquement aux entités activées pour la session.

Pour plus de concepts et une discussion plus approfondie, consultez Fonctionnalités avancées Service Bus.

Durée de vie du client

Les ServiceBusClientexpéditeurs, les récepteurs et les processeurs peuvent être mis en cache et utilisés en tant que singleton pendant la durée de vie de l’application, ce qui est une bonne pratique lorsque des messages sont envoyés ou reçus régulièrement. Ils sont responsables de la gestion efficace de l’utilisation du réseau, du processeur et de la mémoire, en travaillant pour maintenir une utilisation faible pendant les périodes d’inactivité.

Ces types sont jetables et appellent DisposeAsync ou CloseAsync est nécessaire pour garantir que les ressources réseau et autres objets non managés sont correctement nettoyés. Il est important de noter que lorsqu’une ServiceBusClient instance est supprimée, elle ferme et nettoie automatiquement tous les expéditeurs, récepteurs et processeurs qui ont été créés à l’aide de celle-ci.

Sécurité des threads

Nous garantissons que toutes les méthodes de instance client sont thread-safe et indépendantes les unes des autres (instructions). Cela garantit que la recommandation de réutilisation des instances clientes est toujours sécurisée, même entre les threads.

Concepts supplémentaires

Options | du clientDiagnostics | Moqueur

Exemples

Bibliothèque de client Azure Service Bus pour .NET

Envoyer et recevoir un message

L’envoi de messages est effectué à l’aide de ServiceBusSender. La réception est effectuée à l’aide de ServiceBusReceiver.

string connectionString = "<connection_string>";
string queueName = "<queue_name>";
// since ServiceBusClient implements IAsyncDisposable we create it with "await using"
await using var client = new ServiceBusClient(connectionString);

// create the sender
ServiceBusSender sender = client.CreateSender(queueName);

// create a message that we can send. UTF-8 encoding is used when providing a string.
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

// send the message
await sender.SendMessageAsync(message);

// create a receiver that we can use to receive the message
ServiceBusReceiver receiver = client.CreateReceiver(queueName);

// the received message is a different type as it contains some service set properties
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

// get the message body as a string
string body = receivedMessage.Body.ToString();
Console.WriteLine(body);

Envoi d’un lot de messages

Il existe deux façons d’envoyer plusieurs messages à la fois. La première façon de procéder utilise le traitement par lots sécurisé. Avec le traitement par lots sécurisé, vous pouvez créer un ServiceBusMessageBatch objet, qui vous permettra d’essayer d’ajouter des messages un par un au lot à l’aide de la TryAdd méthode . Si le message ne peut pas tenir dans le lot, TryAdd retourne false.

// add the messages that we plan to send to a local queue
Queue<ServiceBusMessage> messages = new Queue<ServiceBusMessage>();
messages.Enqueue(new ServiceBusMessage("First message"));
messages.Enqueue(new ServiceBusMessage("Second message"));
messages.Enqueue(new ServiceBusMessage("Third message"));

// create a message batch that we can send
// total number of messages to be sent to the Service Bus queue
int messageCount = messages.Count;

// while all messages are not sent to the Service Bus queue
while (messages.Count > 0)
{
    // start a new batch
    using ServiceBusMessageBatch messageBatch = await sender.CreateMessageBatchAsync();

    // add the first message to the batch
    if (messageBatch.TryAddMessage(messages.Peek()))
    {
        // dequeue the message from the .NET queue once the message is added to the batch
        messages.Dequeue();
    }
    else
    {
        // if the first message can't fit, then it is too large for the batch
        throw new Exception($"Message {messageCount - messages.Count} is too large and cannot be sent.");
    }

    // add as many messages as possible to the current batch
    while (messages.Count > 0 && messageBatch.TryAddMessage(messages.Peek()))
    {
        // dequeue the message from the .NET queue as it has been added to the batch
        messages.Dequeue();
    }

    // now, send the batch
    await sender.SendMessagesAsync(messageBatch);

    // if there are any remaining messages in the .NET queue, the while loop repeats
}

La deuxième méthode utilise la SendMessagesAsync surcharge qui accepte un IEnumerable de ServiceBusMessage. Avec cette méthode, nous allons essayer d’ajuster tous les messages fournis dans un même lot de messages que nous allons envoyer au service. Si les messages sont trop volumineux pour être inclus dans un seul lot, l’opération lève une exception.

IList<ServiceBusMessage> messages = new List<ServiceBusMessage>();
messages.Add(new ServiceBusMessage("First"));
messages.Add(new ServiceBusMessage("Second"));
// send the messages
await sender.SendMessagesAsync(messages);

Réception d’un lot de messages

// create a receiver that we can use to receive the messages
ServiceBusReceiver receiver = client.CreateReceiver(queueName);

// the received message is a different type as it contains some service set properties
// a batch of messages (maximum of 2 in this case) are received
IReadOnlyList<ServiceBusReceivedMessage> receivedMessages = await receiver.ReceiveMessagesAsync(maxMessages: 2);

// go through each of the messages received
foreach (ServiceBusReceivedMessage receivedMessage in receivedMessages)
{
    // get the message body as a string
    string body = receivedMessage.Body.ToString();
}

Terminer un message

Pour supprimer un message d’une file d’attente ou d’un abonnement, nous pouvons appeler la CompleteMessageAsync méthode .

string connectionString = "<connection_string>";
string queueName = "<queue_name>";
// since ServiceBusClient implements IAsyncDisposable we create it with "await using"
await using var client = new ServiceBusClient(connectionString);

// create the sender
ServiceBusSender sender = client.CreateSender(queueName);

// create a message that we can send
ServiceBusMessage message = new ServiceBusMessage("Hello world!");

// send the message
await sender.SendMessageAsync(message);

// create a receiver that we can use to receive and settle the message
ServiceBusReceiver receiver = client.CreateReceiver(queueName);

// the received message is a different type as it contains some service set properties
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

// complete the message, thereby deleting it from the service
await receiver.CompleteMessageAsync(receivedMessage);

Abandonner un message

L’abandon d’un message libère le verrou de notre récepteur, ce qui permet à ce destinataire ou à d’autres destinataires de recevoir le message.

ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

// abandon the message, thereby releasing the lock and allowing it to be received again by this or other receivers
await receiver.AbandonMessageAsync(receivedMessage);

Différer un message

Le report d’un message empêche sa réception à nouveau à l’aide des ReceiveMessageAsync méthodes ou ReceiveMessagesAsync . Au lieu de cela, il existe des méthodes distinctes et ReceiveDeferredMessageAsyncReceiveDeferredMessagesAsync pour recevoir des messages différés.

ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

// defer the message, thereby preventing the message from being received again without using
// the received deferred message API.
await receiver.DeferMessageAsync(receivedMessage);

// receive the deferred message by specifying the service set sequence number of the original
// received message
ServiceBusReceivedMessage deferredMessage = await receiver.ReceiveDeferredMessageAsync(receivedMessage.SequenceNumber);

Lettre morte un message

La mise en lettres mortes d’un message est similaire à un report avec une main différence étant que les messages seront automatiquement lettre morte par le service une fois qu’ils ont été reçus un certain nombre de fois. Les applications peuvent choisir de lettres mortes manuellement en fonction de leurs besoins. Lorsqu’un message est lettre morte, il est en fait déplacé vers une sous-file d’attente de la file d’attente d’origine. Notez que le ServiceBusReceiver est utilisé pour recevoir des messages de la sous-file d’attente de lettres mortes, que la file d’attente main soit activée ou non pour la session.

ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();

// Dead-letter the message, thereby preventing the message from being received again without receiving from the dead letter queue.
// We can optionally pass a dead letter reason and dead letter description to further describe the reason for dead-lettering the message.
await receiver.DeadLetterMessageAsync(receivedMessage, "sample reason", "sample description");

// receive the dead lettered message with receiver scoped to the dead letter queue.
ServiceBusReceiver dlqReceiver = client.CreateReceiver(queueName, new ServiceBusReceiverOptions
{
    SubQueue = SubQueue.DeadLetter
});
ServiceBusReceivedMessage dlqMessage = await dlqReceiver.ReceiveMessageAsync();

// The reason and the description that we specified when dead-lettering the message will be available in the received dead letter message.
string reason = dlqMessage.DeadLetterReason;
string description = dlqMessage.DeadLetterErrorDescription;

Pour plus d’informations, consultez la vue d’ensemble des files d’attente de lettres mortes ServiceBus.

Utilisation du processeur

Le ServiceBusProcessor peut être considéré comme une abstraction autour d’un ensemble de récepteurs. Il utilise un modèle de rappel pour autoriser la spécification du code lors de la réception d’un message et lorsqu’une exception se produit. Il offre l’achèvement automatique des messages traités, le renouvellement automatique des verrous de message et l’exécution simultanée des gestionnaires d’événements spécifiés par l’utilisateur. En raison de son ensemble de fonctionnalités, il doit s’agir de l’outil d’écriture d’applications qui reçoivent des entités Service Bus. ServiceBusReceiver est recommandé pour les scénarios plus complexes dans lesquels le processeur n’est pas en mesure de fournir le contrôle précis que l’on peut attendre lors de l’utilisation directe de ServiceBusReceiver.

string connectionString = "<connection_string>";
string queueName = "<queue_name>";
// since ServiceBusClient implements IAsyncDisposable we create it with "await using"
await using var client = new ServiceBusClient(connectionString);

// create the sender
ServiceBusSender sender = client.CreateSender(queueName);

// create a set of messages that we can send
ServiceBusMessage[] messages = new ServiceBusMessage[]
{
    new ServiceBusMessage("First"),
    new ServiceBusMessage("Second")
};

// send the message batch
await sender.SendMessagesAsync(messages);

// create the options to use for configuring the processor
var options = new ServiceBusProcessorOptions
{
    // By default or when AutoCompleteMessages is set to true, the processor will complete the message after executing the message handler
    // Set AutoCompleteMessages to false to [settle messages](/azure/service-bus-messaging/message-transfers-locks-settlement#peeklock) on your own.
    // In both cases, if the message handler throws an exception without settling the message, the processor will abandon the message.
    AutoCompleteMessages = false,

    // I can also allow for multi-threading
    MaxConcurrentCalls = 2
};

// create a processor that we can use to process the messages
await using ServiceBusProcessor processor = client.CreateProcessor(queueName, options);

// configure the message and error handler to use
processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

async Task MessageHandler(ProcessMessageEventArgs args)
{
    string body = args.Message.Body.ToString();
    Console.WriteLine(body);

    // we can evaluate application logic and use that to determine how to settle the message.
    await args.CompleteMessageAsync(args.Message);
}

Task ErrorHandler(ProcessErrorEventArgs args)
{
    // the error source tells me at what point in the processing an error occurred
    Console.WriteLine(args.ErrorSource);
    // the fully qualified namespace is available
    Console.WriteLine(args.FullyQualifiedNamespace);
    // as well as the entity path
    Console.WriteLine(args.EntityPath);
    Console.WriteLine(args.Exception.ToString());
    return Task.CompletedTask;
}

// start processing
await processor.StartProcessingAsync();

// since the processing happens in the background, we add a Console.ReadKey to allow the processing to continue until a key is pressed.
Console.ReadKey();

Authentification avec Azure.Identity

La bibliothèque Azure Identity fournit une prise en charge facile d’Azure Active Directory pour l’authentification.

// Create a ServiceBusClient that will authenticate through Active Directory
string fullyQualifiedNamespace = "yournamespace.servicebus.windows.net";
await using var client = new ServiceBusClient(fullyQualifiedNamespace, new DefaultAzureCredential());

Utilisation des sessions

Les sessions fournissent un mécanisme de regroupement des messages associés. Pour utiliser des sessions, vous devez utiliser une entité prenant en charge la session.

Inscription avec ASP.NET Core injection de dépendances

Pour injecter ServiceBusClient en tant que dépendance dans une application ASP.NET Core, installez l’intégration de la bibliothèque de client Azure pour ASP.NET Core package.

dotnet add package Microsoft.Extensions.Azure

Inscrivez ensuite le client dans lequel vos services sont configurés. Pour ASP.NET Core applications, il s’agit souvent directement de Program.cs la StartupConfigureServices méthode ou :

public void ConfigureServices(IServiceCollection services)
{
    services.AddAzureClients(builder =>
    {
        builder.AddServiceBusClient("<< SERVICE BUS CONNECTION STRING >>");
    });

    // Register other services, controllers, and other infrastructure.
}

Pour les applications qui préfèrent utiliser des informations d’identification partagées Azure.Identity pour leurs clients, l’inscription est légèrement différente :

public void ConfigureServices(IServiceCollection services)
 {
     services.AddAzureClients(builder =>
     {
         // This will register the ServiceBusClient using an Azure Identity credential.
         builder.AddServiceBusClientWithNamespace("<< YOUR NAMESPACE >>.servicebus.windows.net");

         // By default, DefaultAzureCredential is used, which is likely desired for most
         // scenarios. If you need to restrict to a specific credential instance, you could
         // register that instance as the default credential instead.
         builder.UseCredential(new ManagedIdentityCredential());
     });

     // Register other services, controllers, and other infrastructure.
 }

Il est également possible d’inscrire des sous-clients, tels que ServiceBusSender et ServiceBusReceiver avec DI à l’aide du instance inscrit ServiceBusClient . Par exemple, pour inscrire un expéditeur pour chaque file d’attente qui appartient à l’espace de noms :

public async Task ConfigureServicesAsync(IServiceCollection services)
{
    // Query the available queues for the Service Bus namespace.
    var adminClient = new ServiceBusAdministrationClient("<< SERVICE BUS CONNECTION STRING >>");
    var queueNames = new List<string>();

    // Because the result is async, they need to be captured to a standard list to avoid async
    // calls when registering.  Failure to do so results in an error with the services collection.
    await foreach (var queue in adminClient.GetQueuesAsync())
    {
        queueNames.Add(queue.Name);
    }

    // After registering the ServiceBusClient, register a named factory for each
    // queue.  This allows them to be lazily created and managed as singleton instances.

    services.AddAzureClients(builder =>
    {
        builder.AddServiceBusClient("<< SERVICE BUS CONNECTION STRING >>");

        foreach (var queueName in queueNames)
        {
            builder.AddClient<ServiceBusSender, ServiceBusClientOptions>((_, _, provider) =>
                provider
                    .GetService<ServiceBusClient>()
                    .CreateSender(queueName)
            )
            .WithName(queueName);
        }
    });

    // Register other services, controllers, and other infrastructure.
}

Étant donné que les expéditeurs sont nommés pour leur file d’attente associée, lors de l’injection, vous ne les liez pas directement. Au lieu de cela, vous allez lier à une fabrique qui peut être utilisée pour récupérer l’expéditeur nommé :

public class ServiceBusSendingController : ControllerBase
{
    private readonly ServiceBusSender _sender;

    public ServiceBusSendingController(IAzureClientFactory<ServiceBusSender> serviceBusSenderFactory)
    {
        // Though the method is called "CreateClient", the factory will manage the sender as a
        // singleton, creating a new instance only on the first use.
        _sender = serviceBusSenderFactory.CreateClient("<< QUEUE NAME >>");
    }
}

Pour plus d’informations et d’exemples, consultez Injection de dépendances avec le Kit de développement logiciel (SDK) Azure pour .NET.

Dépannage

Reportez-vous au Guide de résolution des problèmes de Service Bus.

Étapes suivantes

Au-delà des scénarios d’introduction décrits, la bibliothèque cliente Azure Service Bus offre une prise en charge de scénarios supplémentaires pour vous aider à tirer parti de l’ensemble complet des fonctionnalités du service Azure Service Bus. Pour vous aider à explorer certains de ces scénarios, la bibliothèque cliente Service Bus propose un projet d’exemples qui servira d’illustration pour les scénarios courants. Pour plus d’informations, consultez les exemples lisez-moi .

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.

Pour plus d’informations, consultez notre guide de contribution .

Impressions