Endpoint Config/Names

nservicebus

(Phil Sandler) #1

I am converting my first endpoint to use code configuration + an instance-mapping xml file. Using MSMQ and NSB 6.x.

We previously had the build swap out a unicast bus config file based on environment, so we could change the publisher’s endpoint (queue) name AND the server name per environment. This was useful, as in some cases we would use a suffix on the endpoint name that represented the environment (e.g. “Accounts_QA”).

With the code + instance mapping method, it looks like the registered publisher name needs to match the endpoint name in the mapping:

routing.RegisterPublisher(typeof(IMyEvent).Assembly, “Accounts”);

<endpoints>
  <endpoint name="Accounts">
    <instance machine="MyVM"/>
  </endpoint>
</endpoints>

That said, I do see a reference to a “queue” option in this doc: https://docs.particular.net/samples/routing/instance-mapping-file/?version=core_7

<endpoints>
  <endpoint name="Accounts">
    <instance machine="MyVM" queue="Accounts_QA"/>
  </endpoint>
</endpoints>

Is this the correct way to do the equivalent of:

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Messages="MyAssembly" Endpoint="Accounts_QA@MyVM" />
  </MessageEndpointMappings>
</UnicastBusConfig>

Thanks,

Phil


(Daniel Marbach) #2

Good day Phil

If you have two environments on the same machine it is indeed possible to use the queue name attribute to define the routing to another queue that is not derived by the endpoint name convention. So while it should work I’d be curious to understand a bit more the use case you are doing this. Would you mind elaborating it?

Regards
Daniel


(Phil Sandler) #3

There was a time a few years ago when it was more convenient to double up (non-production) environments on a single VM than to request a new VM. The operational bottlenecks were resolved, but we never went back and split the endpoints onto new machines (everything worked without issue, so we didn’t bother).

Thanks Daniel!

Phil