Rebus Azure ServiceBus - Отсутствует MessageID для сообщения, полученного из внешней службы

Question

Я создаю доказательство концепции с использованием Rebus по отношению к Azure Service Bus, однако у меня есть небольшая проблема, анализирующая сообщение, которое помещается очередь из внешнего источника.

Я получаю сообщение об ошибке:

Received message with empty or absent 'rbs2-msg-id' header!

Я смотрел через GitHub и заметил это перечисление о том, как кто-то был подобный вопрос для RabbitMQ, и было рекомендовано использовать декоратора:

https://github.com/rebus-org/Rebus/issues/508

Однако я не уверен, как это сделать только для идентификатора сообщения.

Один из вариантов я пошел вниз, на самом деле изменения кода Rebus.AzureTransport сделать это:

var messageId = headers.GetValueOrNull(Headers.MessageId); 

if (string.IsNullOrEmpty(messageId)) 
{ 
    messageId = Guid.NewGuid().ToString(); 
    headers[Headers.MessageId] = messageId; 
} 

Но предпочел бы альтернативу!

Другая вещь, которую я заметил, это то, что BrokeredMessage ставится на БАМ, как это:

var message = new BrokeredMessage("<xml>This is a test message: " + DateTime.Now+ "</xml>"); 

Это не сериализации правильно, когда принимается по Ребус. Я получаю следующее сообщение об ошибке:

Unhandled exception 1 while handling message with ID db13880d-124c-4ed5-993e-96faeca0f140: System.Collections.Generic.KeyNotFoundException: Could not find the key 'rbs2-content-type'

Переопределяя Serialiser, то underdying сообщение встретив как:

@strin3http://schemas.microsoft.com/2003/10/Serialization/?6This is a test message: 06/12/2016 07:44:21

, так что я не уверен, что я делаю неправильно.

Заранее спасибо.

Answer 1

Ну ... как говорят сообщения об ошибках, входящее сообщение не содержит достаточной информации, чтобы Rebus мог его обработать.

Кроме того, для транспортировки автобуса Azure Service Bus требуется, чтобы содержимое сообщения было отправлено как Stream во избежание стоимости включения содержащихся в базе данных байтов в структуре XML (что делает драйвер Azure Service Bus по умолчанию) ,

Если бы я был вами, я бы, вероятно, не использовал Rebus для получения сообщений из очереди, не содержащей сообщений, отправленных Rebus. Или я мог бы это сделать - но только если входящие сообщения были очень легко адаптированы для привязки к формату Rebus.

Это может быть немного громоздким, хотя для того, чтобы это произошло, потому что - как вы правильно заметили - для этого требуются определенные заголовки, которые служат подсказками для Rebus о том, как отслеживать его между попытками обработки, как десериализации его, где ответить, если bus.Reply называется, и т.д. Так что я до сих пор, возможно, в конечном итоге не делать это в любом случае :)

Я предлагаю вам сделать что-то вроде этого:

while(true) 
{ 
    var message = GetNextMessageOrNullFromQueue(); 

    if (message == null) continue; 

    UnwrapMessageAndSendWithRebusToRebusQueue(message); 
} 

этот способ кодирования самостоятельно получать петлю для получения сообщений в форме Azure Service Bus, настроенных в соответствии с запросами, делегирование фактической обработки (возможно, также десериализация из XML-текста в объекты?) до конечной точки Rebus.

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