2017-02-14 2 views
0

У меня есть проект Azure WebJobs, который обрабатывает множество трудоемких задач, инициируемых действиями веб-сайта. Он работает нормально.Triggering WebJob-метод на основе свойства сообщения

Но отображение сообщения на вызов метода использует магические строки:

public class SomeClass 
{   
    public async Task ProcessMessage(
     [ QueueTrigger("%" + nameof(ContainerQueueConstants.FilteredVoterFiles) + "%") ] AgencyOutreachMessage 
      msg, 
     TextWriter azureLogWriter 
    ) 
    { 
     PhaseNames.SetNames("Exporting Data", "Job Completed"); 

     await ExecuteFromMessage(msg, azureLogWriter, Launch); 
    } 
} 

public class ContainerQueueConstants 
{ 
    public const string ImportFile = "import-file"; 
    public const string VoterTraits = "voter-traits"; 
    public const string Voter = "voter"; 
    public const string FilteredVoterFiles = "filtered-voter-files"; 
} 

Я хотел бы уйти от использования жестко закодированные строки для имен очередей. В идеале я хотел бы направить сообщение конкретному методу, основанному на значении свойства, содержащегося в сообщении.

Но я не уверен, что это возможно, по крайней мере, в версии 1.1.x SDK WebJobs.

Рекомендации или рекомендации оценены.

+0

Если вы хотите вызвать метод, основанный на свойстве в сообщении, почему бы не просто десериализовать сообщение, проверьте значение свойства и вызовите требуемый метод на основе значения свойства? Или я не понимаю, и вы хотите отслеживать несколько очередей, каждый из которых имеет другое имя очереди, которое вы не хотите жесткого кода? –

+0

Я бы хотел сделать последнее, Роб: контролировать несколько очередей, которые не имеют жестко названных имен. Ваша идея будет работать нормально, за исключением того, что по другим причинам я управляю каждой из текущих очередей, как Singletons, и если я выталкиваю все сообщения через одну очередь Singleton, они будут безответственно отложены. Хотя это может быть наилучшей альтернативой, все рассмотрено. –

+0

Есть ли причина, по которой вам нужно использовать QueueTriggerAttribute, а не просто создавать экземпляры N CloudQueue для мониторинга N разных очередей хранения? Или будет использоваться N различных экземпляров CloudQueue? Я также должен спросить, будет ли получающее приложение WebJob. –

ответ

2

Я предлагаю использовать экземпляры N CloudQueue для мониторинга N различных очередей хранения. Поскольку вы делаете это в WebJob, вы, вероятно, сделаете это как непрерывный webjob и должны сами выполнить опрос для каждой очереди. Вы также должны будете взять на себя ответственность за удаление успешно обработанных сообщений.

QueueTriggerAttribute имеет встроенную поддержку для бездействия. Я не верю, что есть автоматическая поддержка без надписей, если вы не используете QueueTriggerAttribute.

+0

Что такое поддержка оповещений? –

+0

Мертвая надпись - это концепция очереди для обработки ядовитых сообщений. Ядовитое сообщение - это сообщение, которое было отменено и безуспешно обработано определенное количество раз. Это отличная функция, которая хранит сообщения, которые не могут быть обработаны из жизни в вечном режиме чтения/сбоя/аренды expire/read/fail/lease expire ... loop. Когда вы используете QueueTriggerAttribute с запущенными WebJobs, сообщения, которые были доставлены X раз безуспешно, будут помещены в отдельную очередь под названием [queue name] -poison. Вы можете посмотреть и обработать эти сообщения позже. –

+0

Вы можете прочитать о ядовитых сообщениях и автоматическом бездействии с помощью QueueTriggerAttribute здесь: https://docs.microsoft.com/en-us/azure/app-service-web/websites-dotnet-webjobs-sdk-storage-queues-how -to # poison –

Смежные вопросы