NServiceBus for dummies who want to be smarties 3… third post on how to do some more stuff with NServiceBus.
But where do the messages go?
Well, where did you tell the framework to send them?
The answer to this question is deferred until the last meaningful moment, i.e. the moment when the generic host starts up and reads its app.config.
How do I receive messages?
The answer is simple: use the MsmqTransportConfig section to tell NServiceBus where this service can be reached. If the specified queue does not exist, it will be created. E.g. like so:
|
1 2 3 4 |
<MsmqTransportConfig InputQueue="client" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5" /> |
How do I send messages?
This question is a bit harder to answer. First, it can be specified in the UnicastBusConfig/MessageEndpointMappings element, for each message type, or for an entire assembly at a time. E.g. like so:
|
1 2 3 4 5 6 |
<UnicastBusConfig> <MessageEndpointMappings> <add Messages="Messages" Endpoint="someService" /> <add Messages="MessagesRootNamespace.SomeSpecificMessage, Messages" Endpoint="anotherService" /> </MessageEndpointMappings> </UnicastBusConfig> |
In the example above, I have configured that all messages from the assembly Messages except SomeSpecificMessage will be routed to someService, whereas SomeSpecificMessage has its own destination in the queue anotherService.
Note that this section is not required if the service is a publisher, because then it will know where to send messages because other services have subscribed, and in the process they leave the name of the queue where they can be found.
Conclusion
That concludes today’s “NServiceBus for dummies who want to be smarties”. This was about where messages go. Next post will be an example with a simple infrastructure for an ASP.NET MVC backend running on NServiceBus, accepting subscriptions from other services. It’s going to be hot!