Using Azure Service Bus

TIP

Wolverine.AzureServiceBus is able to support inline, buffered, or durable endpoints.

Wolverine supports Azure Service Bus as a messaging transport through the WolverineFx.AzureServiceBus nuget.

Connecting to the Broker

After referencing the Nuget package, the next step to using Azure Service Bus within your Wolverine application is to connect to the service broker using the UseAzureServiceBus() extension method as shown below in this basic usage:

using var host = await Host.CreateDefaultBuilder()
    .UseWolverine((context, opts) =>
    {
        // One way or another, you're probably pulling the Azure Service Bus
        // connection string out of configuration
        var azureServiceBusConnectionString = context
            .Configuration
            .GetConnectionString("azure-service-bus");

        // Connect to the broker in the simplest possible way
        opts.UseAzureServiceBus(azureServiceBusConnectionString)

            // Let Wolverine try to initialize any missing queues
            // on the first usage at runtime
            .AutoProvision()

            // Direct Wolverine to purge all queues on application startup.
            // This is probably only helpful for testing
            .AutoPurgeOnStartup();

        // Or if you need some further specification...
        opts.UseAzureServiceBus(azureServiceBusConnectionString,
            azure => { azure.RetryOptions.Mode = ServiceBusRetryMode.Exponential; });
    }).StartAsync();

^{snippet source | anchor}

The advanced configuration for the broker is the ServiceBusClientOptions class from the Azure.Messaging.ServiceBus library.

For security purposes, there are overloads of UseAzureServiceBus() that will also accept and opt into Azure Service Bus authentication with:

1. TokenCredential
2. AzureNamedKeyCredential
3. AzureSasCredential

Request/Reply

Request/reply mechanics (IMessageBus.InvokeAsync<T>()) are possible with the Azure Service Bus transport if Wolverine has the ability to auto-provision a specific response queue for each node. That queue would be named like wolverine.response.[application node id] if you happen to notice that in the Azure Portal.

And also see the next section.

Disabling System Queues

If your application will not have permissions to create temporary queues in Azure Service Bus, you will probably want to disable system queues to avoid having some annoying error messages popping up. That's easy enough though:

var host = await Host.CreateDefaultBuilder()
    .UseWolverine(opts =>
    {
        opts.UseAzureServiceBusTesting()
            .AutoProvision().AutoPurgeOnStartup()
            .SystemQueuesAreEnabled(false);

        opts.ListenToAzureServiceBusQueue("send_and_receive");

        opts.PublishAllMessages().ToAzureServiceBusQueue("send_and_receive");
    }).StartAsync();

^{snippet source | anchor}