2017-06-26 1 views
4

J'ai plusieurs WebJobs avec des déclencheurs ServiceBus, et j'ai un MessageProcessor personnalisé pour faire un traitement après le traitement du message. Je voudrais pouvoir faire quelque chose de différent (en particulier, consigner une erreur au lieu d'un avertissement) si le message est sur sa dernière tentative, c'est-à-dire qu'il est sur le point d'être envoyé à la file d'attente. Le BrokeredMessage envoyé dans la fonction CompleteProcessingMessageAsync a le DeliveryCount, mais je ne vois pas un moyen de revenir à la file d'attente d'origine pour trouver le MaxDeliveryCount. Des idées? Les différentes files d'attente ont des MaxDeliveryCounts différents, donc la définition d'une constante n'est pas vraiment une option. La seule autre chose que je peux penser est de créer un travail séparé pour la file d'attente de lettres mortes de chaque file, mais j'aimerais pouvoir le faire au niveau de WebJob plutôt que pour chaque travail individuel.Azure Webjobs ServiceBusTrigger - effectue une fonction différente lorsque MaxDeliveryCount est atteint

public class CustomMessageProcessor : MessageProcessor 
{ 
    public CustomMessageProcessor(OnMessageOptions messageOptions) : base(messageOptions) 
    { 
    } 

    public override async Task CompleteProcessingMessageAsync(BrokeredMessage message, FunctionResult result, CancellationToken cancellationToken) 
    { 
     if (result.Succeeded) 
     { 
      if (!MessageOptions.AutoComplete) 
      { 
       cancellationToken.ThrowIfCancellationRequested(); 
       await message.CompleteAsync(); 
      } 
     } 
     else 
     { 
      cancellationToken.ThrowIfCancellationRequested(); 

      //some other processing 

      //If message.DeliveryCount < maxDeliveryCount 
      // log warning 
      //else 
      // log error 

      await message.AbandonAsync(); 
     } 
    } 
} 

Répondre

1

Vous devriez être en mesure d'obtenir Microsoft.ServiceBus.Messaging.QueueDescription de la file d'attente des parents, puis utilisez MaxDeliveryCount dehors. La seule chose est qu'obtenir la description de la file d'attente est une opération relativement coûteuse, donc je vous recommande de le faire une fois initialement, et mettre en cache la valeur pour chaque file d'attente.

+0

Mais comment puis-je savoir de quelle file provient le message? –

+0

@ anthony-keenan cela dépend - comment câbler votre processeur de message personnalisé? Savez-vous quelle instance de processeur lie à quelle file d'attente? Je n'ai pas d'expérience directe avec cette partie du SDK, mais je pense que lorsque les processeurs de messages personnalisés sont câblés (par exemple via un fournisseur de messagerie), vous devriez voir quelque chose comme "chemin de l'entité". instance de processeur, puis utiliser pour référencer une file d'attente dans une collection mise en cache/partagée. –

+0

Le processeur de messages personnalisé remplace celui qui fait partie de l'infrastructure Webjobs. Il est invoqué avant et après chaque message traité par webjob, malheureusement, il est global, pas spécifique à la file, et d'après ce que je peux voir le chemin de la file d'attente n'est pas sur le message sponsorisé, je ne peux pas rechercher la file d'attente. –

0

différentes files d'attente ont des MaxDeliveryCounts, donc définir une constante n'est pas vraiment une option

Comme Slava Asipenko mentionné que nous pourrions mettre MaxDeliveryCount pour la file d'attente servicebus.

comment puis-je travaille quelle file d'attente le message est venu de

On peut obtenir les propriétés du message pour connaître le nom de la file d'attente si représenterons-nous lors de l'envoi. Prenez Label par exemple:

var message = new BrokeredMessage(object); 
message.Label = "queue name"; 
client.Send(message); 
+0

Les messages que je suis en train de traiter sont en fait publiés via un sujet. Vous pouvez donc définir le nom du sujet du côté de l'envoi en tant qu'étiquette de message, mais le champ MaxDeliveryCount est spécifique à la file d'attente et vous ne saurez pas de quelle file il a été traité. Cela semble également désordonné, en changeant le côté d'envoi pour compenser une lacune de réception. –

+0

Nous pourrions également définir [MaxDeliveryCount] (https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.subscriptiondescription.maxdeliverycount?view=azure-dotnet#Microsoft_ServiceBus_Messaging_SubscriptionDescription_MaxDeliveryCount) pour la souscription. Nous pourrions également ajouter des propriétés pour le message, par exemple 'message.Properties [" subcriptionName "] =" nom d'abonnement "'; –