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:

var builder = Host.CreateApplicationBuilder();
builder.UseWolverine(opts =>
{
    // One way or another, you're probably pulling the Azure Service Bus
    // connection string out of configuration
    var azureServiceBusConnectionString = builder
        .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; });
});

using var host = builder.Build();
await host.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.

Wolverine Control Queues

You can opt into using temporary Azure Service Bus queues for intra-node communication that Wolverine needs for leader election and background worker distribution. Using Azure Service Bus for this feature is more efficient than the built in database control queues that Wolverine uses otherwise, and is necessary for message storage options like RavenDb that do not have a built in control queue mechanism.

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

    // Connect to the broker in the simplest possible way
    opts.UseAzureServiceBus(azureServiceBusConnectionString)
        .AutoProvision()
        
        // This enables Wolverine to use temporary Azure Service Bus
        // queues created at runtime for communication between
        // Wolverine nodes
        .EnableWolverineControlQueues();

});

^{snippet source | anchor}

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}