2015-02-23 3 views
1

Я участвую в многоуровневом проекте, одна часть которого потребляет поток «событий» из сторонней системы. Поставщик публикует их через тему Azure Service Bus Topic - они предоставляют, управление & управляет шиной. Нам просто предоставляются идентификатор URI, TopicName и Subscription.WebJob ServiceBus Разрешения для темы

Наш подход состоял в том, чтобы собрать Webjob, используя предоставленный ServiceBusTrigger в SDK, чтобы обрабатывать прослушивание новых сообщений &, запуская обработку их в нашу систему. Тем не менее, мы, похоже, попали в блокпост, так как работа постоянно не читается из темы. Работа терпит неудачу с неопределенным Timeout Exception:

Unhandled Exception: System.TimeoutException: The timeout elapsed upon attempting to obtain a token while accessing 'https://****-sb.accesscontrol.windows.net/WRAPv0.9/'. 
---> System.IdentityModel.Tokens.SecurityTokenException: The token provider was unable to provide a security token while accessing 'https://****-sb.accesscontrol.windows.net/WRAPv0.9/'. 
Token provider returned message: 'The operation has timed out'. 

Но дальше, след включает в себя:

[ERR] at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) 
[ERR] at Microsoft.ServiceBus.NamespaceManager.OnEndTopicExists(IAsyncResult result) 
[ERR] at Microsoft.ServiceBus.NamespaceManager.EndTopicExists(IAsyncResult result) 

поставщик впоследствии подтвердил, что единственное разрешение/утверждают, что подписка на Топик Listen

Может ли кто-нибудь подтвердить, какие требования к разрешению для ServiceBusTrigger?

И как +1, исходя из предположения, что, по какой-либо причине, необходимо больше Listen (т.е. потребности Manage), кому-то хотелось бы предложить альтернативный подход? Кажется, стыдно потерять инфраструктуру WebJob (проект уже имеет 3 других задания) - особенно потеря функций, таких как async & одновременная обработка сообщений из темы

ответ

5

Чтобы закрыть это, мы внесли предлагаемое изменение в SDK WebJobs (запрос на передачу здесь: https://github.com/Azure/azure-webjobs-sdk/pull/528). Это будет в следующем выпуске. Вот пример того, как Вы определяете AccessRights за атрибут:

public static void JobFunction(
    [ServiceBusTrigger("inputqueue", AccessRights.Listen)] string message, 
    [ServiceBus("outputqueue", AccessRights.Send)] out string message) 
{ 
    . . . 
} 

Если не указано, по умолчанию будет «Управление». При настройке на что-либо, кроме управления, SDK не будет пытаться создавать какие-либо ресурсы SB. Я полагаю, это отвечает вашим потребностям?

+0

Спасибо Мэтью. Мы продвинулись вперед, внедряя собственную оболочку по темам на данный момент, но она далека от совершенства, поскольку у нас, очевидно, нет интеграции с панелью мониторинга, и некоторые вопросительные знаки над грациозным отключением. Мы обязательно рассмотрим это в ближайшем будущем, как только это исправление исчезнет в стабильном выпуске. – Ian

1

SDK делает следующий вызов, который потребует разрешения на управление , Microsoft.Azure.WebJobs.ServiceBus.Listeners.NamespaceManagerExtensions. Один из вариантов, если вы не можете установить эти разрешения, - это не использовать SDK для триггеров служебной шины, а использовать его для всего остального.

+0

Спасибо за подтверждение Pranav - Я буду смотреть, чтобы положить что-то вместе, используя 'MessageClient.OnMessageAsync()' обратного вызов Я бы сказал, что есть довольно убедительные бизнес-прецеденты для поддержки сценария Vendor-Client где Поставщик предоставляет только Слушание данной теме (или очереди). Я предполагаю, что одним из вариантов было бы добавить флаг Enum в атрибут trigger ('MessageBusTriggerConnectionType.Managed' /' .Listener') - по умолчанию для Managed сохранить текущее поведение, но если он установлен в Listener, пропустите любые вызовы Topic Description/CreateIfNotExists – Ian

+0

Благодарим вас за предложение. Я верну его в команду. –

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