Azure WebJob process multiple service bus queues that are set in configuration

Question

I am currently working on a solution where a webjob monitors a service bus queue. This works great but it needs to be easily adaptable to manage any number of queues just be changing a list of queues in the config.

Currently I can see that I can do this:

    public static void ProcessQueueMessage1([ServiceBusTrigger("queue1")] BrokeredMessage message, TextWriter log)
    {

    }

And for another queue I would need to add another method:

    public static void ProcessQueueMessage2([ServiceBusTrigger("queue2")] BrokeredMessage message, TextWriter log)
    {

    }

Obviously, I don't want to add a new method every time I need to watch a new queue.

How would I go about using a WebJob to monitor any queue who's name is in my config? I mean a list of queue names not just one in config.

For example, I know I can use a QueueNameResolver to do the following:

    public static void ProcessQueueMessage([ServiceBusTrigger("%nameInCofig%")] BrokeredMessage message, TextWriter log)
    {}

But I really want to process a list of queue names with only one WebJob ProcessQueueMessage method.

I have been searching for ages and am nearly at the point of using a WorkerRole instead.

Any help would be great.

Answer 1

I'm also curious why you've got multiple queues being handled by the same method - there might be a better design pattern and approach for this...but...

You could accomplish this by not using the trigger attribute and instead start up the web job host and use some code that iterates over the queues specified in your config file, wiring up a queue client with the same OnMessage action for each one. Something like this:

.
.
.
var factory = MessagingFactory.CreateFromConnectionString("");
foreach (var queue in queues)
{
    var client = _factory.CreateQueueClient(queue);
    client.OnMessage(OnMessageReceived, options);
}
.
.
.

public void OnMessageReceived(BrokeredMessage message)
{
     // do your work
}

There are a number of additional options on the QueueClient and OnMessage call for how messages should be handled, but this approach might work.