We are consuming events from another team which does not use NSB but azure function with azure service bus output binding to publish an event.
Our service on the other hand is using NSB. As the event does not contain NServiceBus.EnclosedMessageType header key/value, the endpoint does not know to which handler the message belongs.
To make it work, we wrote a mutator (implementing from IMutateIncomingTransportMessages) which sets the EnclosedMessageType manually. We know the type based on other header values respectively based on certain message body values.
Is that the way to go or do you have any other recommended way to achieve this?
Asking the publishing team to set NServiceBus.EnclosedType is not an option.
I have an additional question regarding this topic.
I use a Behavior< IIncomingPhysicalMessageContext > for the same thing. I noticed that the IIncomingPhysicalMessageContext can do a Send() or Publish().
Are those methods replacing the physical message in the pipeline or will the send/publish an additional message?
Currently I wrap the non-nsb message to a generic DataverseMessage in the Behavior< IIncomingPhysicalMessageContext >. Then I have a handler that converts the DataverseMessage to a specific NServiceBus Event or Command and do a Send() or Publish().
Would it be possible to do the work of the handler, in the behavior, so that I can remove the handler?
If you’re receiving messages from non-NSB endpoints, it could be due to misconfiguration or incorrect routing in your NServiceBus setup. Make sure your endpoint configurations and routing settings are correct to ensure only the intended messages are being processed. Also, check if external systems or legacy messaging frameworks are using the same queues, which could cause unintended message delivery. Enabling detailed logging in NServiceBus can help trace the source of these messages and identify where the issue is coming from. By reviewing these areas, you should be able to resolve the problem.
thanks for confirming the solution