Azure WebJob verarbeitet mehrere Service-Bus-Warteschlangen, die in der Konfiguration festgelegt werden

Question

Ich arbeite derzeit an einer Lösung, bei der ein Web-Job eine Service-Bus-Warteschlange überwacht. Dies funktioniert gut, aber es muss leicht anpassbar sein, um eine beliebige Anzahl von Warteschlangen zu verwalten, die nur eine Liste von Warteschlangen in der Konfiguration ändern.

Zur Zeit kann ich sehen, dass ich das tun kann:

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

    } 

Und für eine andere Warteschlange würde ich brauche eine andere Methode hinzuzufügen:

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

    } 

Natürlich, ich will keine hinzufügen neue Methode jedes Mal, wenn ich eine neue Warteschlange sehen muss.

Wie würde ich einen WebJob verwenden, um jede Warteschlange zu überwachen, deren Name sich in meiner Konfiguration befindet? Ich meine eine Liste der Warteschlangennamen nicht nur eine in der Konfig.

Zum Beispiel weiß, dass ich mir ein QueueNameResolver verwenden kann wie folgt vorgehen: will

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

Aber ich wirklich mit nur einem WebJob ProcessQueueMessage Verfahren eine Liste der Warteschlangennamen verarbeiten.

Ich habe seit Ewigkeiten gesucht und bin fast am Punkt der Verwendung einer WorkerRole stattdessen.

Jede Hilfe wäre großartig.

Answer 1

Ich bin auch neugierig, warum Sie mehrere Warteschlangen werden nach der gleichen Methode behandelt haben - es könnte ein besseres Design-Muster und Ansatz für diese ... aber ...

Sie können dies erreichen, indem Verwenden Sie nicht das trigger-Attribut und starten Sie stattdessen den Web-Job-Host und verwenden Sie einen Code, der über die in Ihrer Konfigurationsdatei angegebenen Warteschlangen iteriert und einen Warteschlangenclient mit der gleichen OnMessage-Aktion für jeden einzelnen verbindet. Etwas wie folgt aus:

. 
. 
. 
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 
} 

Es gibt eine Reihe von zusätzlichen Optionen auf dem QueueClient und OnMessage Aufruf, wie Nachrichten behandelt werden sollte, aber dieser Ansatz funktionieren könnte.