I’m new to NServiceBus and I’m looking to learn how to use EXISTING ASB resources (queue, topic/subscription) with NServiceBus. In the documentation I’m seeing routing to “endpoints”. Do I just need to use topic name, queue name etc for the endpoint names? And what would would this look like on a receiver’s end? My organization wouldn’t want to use installers.
Hi,
I’m not sure what you mean by “we don’t want to use installers”?
NServiceBus Endpoints are basically hosts to one or more Message Handlers that all share the same configuration, SLA, etc. A message handler is code that literally processes a single message type. You don’t have to install NServiceBus, only pull in the required NuGet packages. Not sure if you are familiar with this, since you asked about installation. But I could be mistaken. If you need more info on how NServiceBus works, I can recommend our tutorial.
NServiceBus endpoints also share serialization. Without configuration, you’ll use XML, but you can also use json or many other serializers. Although NServiceBus uses default serializers (we usually don’t build them ourselves), it does require the json/xml/whatever to be in a specific format. If it’s not, NServiceBus won’t be able to deserialize the message.
Next to that, we expect certain headers. If those don’t exist, NServiceBus might also fail picking up and processing the message.
If you make sure these conditions are met, you should be able to send messages from anywhere to NServiceBus.
There are several samples available that show how native integration is done.
I hope that helps?
Hi Dennis, my apologies that I wasn’t clear, allow me to try again. What I meant about not wanting to use installers is to be able to create my own messaging entities/topology for the transport behorehand (Azure service bus in my example) instead of using Installers • NServiceBus • Particular Docs or the operational scripting. My organization would like to use ARM templates and I’d like to understand apart from the endpoints, what other entities are needed (for ex, error, audit, DB tables etc if I do want to use these features) for the “ForwardingTopology” and how to route the data/messages to these custom entities when an error occurs, audit is to be written to and so on without using the NServiceBus’s default setup. Also, will command message types also use the forwardingTopology or these messages will just be queue to queue?
When your organization doesn’t want to use the operational scripting we provide, then you need to build the same topology using ARM (by the way, why ARM and not biceps?).
Before I dive deeper into answering the question of how much of the topology does your organization need to be fixed? Do you allow runtime subscription of events or is the goal to run entirely without manage rights on Azure Service Bus?
Regards,
Daniel
Hi @danielmarbach, thanks for your response. I believe the approved infra for us is terraform(which hooks up to ARM bts) for creating the topology.
Goal at this time is to run entirely without making runtime changes to ASB, I’m assuming you’re trying to get at whether will be adding subscription filters at runtime, we will be adding them to ASB within terraform or azure. Will we need to disable autosubscribe to achieve this?
However, I would also be curious to know if runtime subscription of events is possible without enabling installers so we that we can also consider that as an option.
Since I posted this originally, I’ve been able to do a POC with the following setup without using the installers -
- a queue per command
- a single topic
- a subscription for each subscriber with a default falsefilter + eventtype filter which forwards to #4
- a queue per subscriber
- an error queue
- an audit queue
- we’re planning on using sqlpersistence for outbox so will include the outbox create sql script from in our deployment process.
Is there anything that I missed?
Thanks
Thanks for coming back with additional information.
Yes, presently you would have to. Otherwise, AutoSubscribe would try to create rules on the subscription. I have raised an issue in the transport to improve the story slightly, since there is a new RuleManager that would allow setting up rules without manage rights. Unfortunately, the way we setup rules today is incompatible with the new rule manager.
You can create topics, queues and subscriptions and then let the transport at runtime manage the rules. That should be possible without the installers but requires as mentioned above manage rights. So it is not possible to run just with Receive and Send rights. If you use other means of connecting to the broker you would need to make sure the role has access to manage rules.
Not sure why you need a queue per command. NServiceBus has the concept of a logical endpoint. A logical endpoint is mapped to a queue. At runtime you can have many instances of the same endpoint run as competing consumers against a queue. An endpoint can be both a receiver for commands and a subscriber for events. How you split that up is an architectural choice of yours (of course we have opinions that we are happy to share but for this discussion I believe that is out of scope).
So to answer your question what you would need is:
A single topic
A queue per endpoint
A subscription per endpoint that forwards to the queue
Per subscription a false filter plus the event type filters the endpoint subscribes to
An error queue
An audit queue
FYI we are working on a 3.1 release of the transport that will allow hierarchies of topics to overcome some of the limitations of the single topic design for large systems. As soon as that is ready I’m happy to share the refreshed documentation pages with you.
Regards,
Daniel
Ok. I was asking because using pure ARM would be painful 
1 Like
Thanks for the update and for answering all my questions in detail! Much appreciated @danielmarbach
1 Like
Hello, is cross namespace sends to native receiver supported from nservicebus? Working with an external team’s ASB namespace(queue) that we need to send messages to.
Currently, there is no built-in support (*) within the transport to do cross namespace routing. The message bridge can help you in that scenario.
Using multiple instances of the same transport, differentiated by some distinguishing factor (e.g. Azure Service Bus namespaces, or SQL Server database instances)
You can set up a bridge that forwards messages to the other namespace.
Regards,
Daniel
(*) Azure Storage Queues has that built-in and in theory we could build something similar into the transport, but we have seen it can complicate the transport significantly. Maybe if you can detail on how many cases this functionality would be useful for you and what requirements you have, we can re-initiate the discussion and I will raise an issue in the transport repository.