Reputation: 924
I'm confused by the relationship between UnicastBusConfig, MsmqTransportConfig, and MSMQ queues in general. The docs state:
"The way that the bus at the subscriber subscribes to the publisher is by sending a message to the queue that has been configured in its section"
Am I correct in believing that each Subscriber must contain a MessageEndpointMapping back to the Endpoint (or queue) for each Publisher that could potentially publish messages that the Subscriber handles?
If that's the case, then how do you configure more than one MessageEndpointMapping for the same message type? You can't have duplicate values.
For example, given MyAssembly.IDoStuff, assume I have two Publishers that publish IDoStuff and one Subscriber:
<UnicastBusConfig>
<MessageEndpointMappings>
<add Messages="MyAssembly" Endpoint="Publisher1" />
<add Messages="MyAssembly" Endpoint="Publisher2" /> <-- runtime exception
</MessageEndpointMappings>
</UnicastBusConfig>
The business case for this is simple. Say the Subscriber is an FTP process that takes a file and FTP's it out. Obviously you'd want to consume that functionality from many places across the enterprise. So it makes sense to have an FTP Subscriber that handles ISendFile and then have each Publisher process that needs FTP functionality simply publish ISendFile messages. This is the exact scenario I'm running into - and I don't see a way around it.
Please advise - thanks!
Upvotes: 2
Views: 1519
Reputation: 5273
As Kijana mentioned on the nsb list one of the core assumptions with pub sub is that a publisher should have no knowledge of its subscribers. There could even be 0 subscribers, in your example that wouldn't work since then no ftp transfer would be performed. This is a sign that you should do a bus.Send(SendStuffUsingFtpCommand) instead. NServiceBus tries to lead you down that path by only allowing one logical publisher for a given message type. Technically this means one message mapping entry per message type only as you've noticed.
Upvotes: 4