I’m struggling to get my head around the naming of Azure resources (particularly topics and subscriptions) when using the Messaging Bridge. It seems there is no need to ensure that the Bridge defines the same topic name that the Azure endpoints do - possibly because of the use of Azure Service Bus’ auto-forwarding feature, and the fact that the Bridge appears to write directly to queues when moving published events from on-prem MSMQ to an Azure-hosted subscriber endpoint.
I see that things have changed in NServiceBus.Transport.AzureServiceBus in terms of topic naming, and I want to understand if we need to do anything with our bridge or if the two things are completely decoupled.
We are on v4 for now as we need to properly understand the current situation in order to formulate the migration to v5 (which seems like, at least in a greenfield situation, would be simpler overall).
What I found through experimentation with the MSMQ/ASB sample (thank you guys for providing that), is that with all ASB transports (in the bridge and any services) left with default topology settings, in Azure you get ASB queue-per-endpoint, plus subscriptions in a topic called “bundle-1”. Everything works, that’s fine.
Weirdly, if you tell the bridge to use Topology.Single("jam") for the ASB transport, then everything still works. I’m still struggling to wrap my head around that. Either I’ve made a mistake or it’s a happy coincidence resulting from the way the bridge knows the queue name for MSMQ->ASB movements, and the way auto-forwarding is used to get messages from subscriptions on topics to the relevant ASB queue.
However, if you change the endpoint itself to use a non-default topic name for it’s transport, say Topology.Single("donuts") then everything stops working. To fix it, you correct the bridge from “jam” to “donuts”. That’s fine if the bridge only bridges one ASB service, but if you want your bridge to continue this behaviour of using custom topic names for more services, you need to create more AzureServiceBusTransports (maybe even endpoint-per-transport). This is because the topic name comes from the transport setup, not the endpoint. In fact, from a code point of view in the bridge’s code, it would be simpler to just accept it’s topic-per-endpoint, named after the endpoint.
I don’t mind this in principle, but it would be good to know that’s not going to create a monster bridge that uses loads of resources and runs slowly. The docs do specifically state there should be no need to create multiple bridge applications so I’m betting it’s fine. It’s not like a normal endpoint.
I’m just checking that what I’ve observed from experimentation matches expectation. Of course all bets are off with v5 so it’s back to square one to work out how we get to that.
The bridge does not publish any messages. It only needs to know about topology for subscription purposes.
When you configure a publisher, this happens at the BridgeEndpoint level. The bridge subscribes to the event, and when it receives an event of that type, it shovels it across the bridge (a send rather than a publish) to the queue for that BridgeEndpoint.
With that in mind, if you are publishing events from MSMQ and subscribing to them in Azure Service Bus, then it does not matter how the topology is configured in the bridge.
If you have Azure Service Bus endpoints subscribing to events published by other Azure Service Bus endpoints, then they will need to have the same topology configured.
The only time the bridge needs to know about topology configuration is when you have MSMQ endpoints subscribing to events being published by Azure Service Bus endpoints. Then, the bridge topology configuration will need to match the one used by the Azure Service Bus endpoint that is publishing the event.
Be aware that when you start an Azure Service Bus endpoint (or a bridge connected to Azure Service Bus) it will create any subscriptions using its current configuration. If you change the configuration and restart the component, it creates the new subscriptions but does not delete the previous ones (it has no way of knowing what they were). This can make things look like they are magically working in certain scenarios, and they may continue to work until you move the system to a clean environment.