Sorry if it seems like a simple question, but I'm new to the NServiceBus framework and I'm still trying to figure out everything. We have a WCF service that accepts some data, that we will be redirecting to one or several of our clients. Each client has their own environment hosted on Azure.
To give a concrete example, let's say that I receive a whole bunch of orders, and I want to distribute these orders among my dispatch-clients, based on some criteria. Let's say that I have 3 clients, and based on their rating, client A receives 5 orders to dispatch, client B should receive 4 and client C only 1 of the 10 orders I have to process.
I have some kind of intelligent mechanism behind my WCF service that does the hocus pocus on which client should receive which orders, but once I have decided who gets what, I want to dispatch the correct orders to the correct endpoints in the form of commands.
Each client has the same configuration: an endpoint listening to the same commands/events/messages. I want to get to a point in which I have stored the exact connectionstring for the transport for a specific client in a data store, and I can just query it, and send the relevant orders to their queue.
In the examples I find around the web, this information is embedded in the config and therefore kind of static, while I want to have access to this information and add dispatch clients with minimal impact. Any ideas on how to do this?
Thanks in advance!
NSB version 6 introduced a new mechanism for advanced message routing, which may be what you are looking for:
http://docs.particular.net/nservicebus/messaging/routing
Prior to version 6, you have the ability to specify the receiving endpoint name at runtime:
bus.Send("myendpoint", new MyMessage());
This works fine for commands, but events might be a little more tricky since the other endpoints subscribe to you, and you as the publisher generally are unaware they exist. For this situation you could use message versioning as a workaround. You would setup a base event type such as:
public interface BaseOrderEvent { ... }
Then for each client specific event, you could make a new event type:
public interface Client1OrderEvent : BaseOrderEvent { ... }
Finally in your publishing code, you publish the client specific event via a simple switch statement or possibly using reflection.
Not the most elegant solution, but it could be a workaround if you only have a few clients this would apply to. Overall I think the version 6 message routing features look more promising, if that's an option for you.