‘UseEndpointOrientedTopology’ seems to be missing in the TransportExtensions. How do I do this when using the new package ?
How do I set the queue and topic creation topology when using Azure Service Bus transport with .net core
NServiceBus Azure Service Bus transport (the new transport) doesn’t have an explicit topology selection you have to make as a user. All configuration options are described in this article. The transport set reasonable defaults and and is very different in that way from the legacy ASB transport.
Is there something specific you’re looking for?
We’re trying to switch from RabbitMQ to Azure service bus. When using rabbitmq transport, all the exchanges, queues and bindings are created automatically by default topology. I was expecting something similar with azure service bus transport but found it missing for the new transport. (legacy azure service bus transport has something similar). Is there a way to achieve this with the new transport ? If there is, could you point me to a sample implementation ?
The new Azure Service Bus transport will create the required infrastructure if installers are enabled.
You can download the new ASB example to see it in action.
I’m not seeing Topics created even when the installers are enabled. It is a send only end point.
Here’s a link to the sample project. It works if I start the ‘subscriber’ first, whereas I do not see any infrastructure (topic creation) being setup if I start the Publisher first. I was expecting Nservicebus to scan for all the events and setup topics and wire things up.
Publisher endpoint is a send-only. Send-only endpoints do not create any infrastructure, only send/publish to the existing queues/topics. Hence the behaviour you’re seeing. When a full endpoint (not send-only) is executed, in your case
Subscriber, it create all the infrastructure. Either you’ll need to ensure infrastructure exists or execute an endpoint that will create it.
As a note, if
Publisher becomes a full endpoint (not send-only), it would still be needed for the
Subscriber to create a subscription before events will be received. Publishers do not do that, it’s the responsibility of the subscribers.
Hope this info helps.
Is it not enforcing a Publisher to write a test subscriber for all the events that it publishes ??
As an API, I should still be able to publish events even though there are no subscribers at this moment. It’s just that nobody is subscribed to these events.
In RabbitMQ transport, the send-only endpoint just creates the exchanges but not the queues. So that, we were still able to publish events even though there are no subscribers at the moment.
Just a thought !
That’s a valid point. I’ve raised an issue in GitHub.
You can subscribe to the issue here to track the updates.
Thank you for bringing this up.
Great ! Thank you for prompt replies. Appreciate it !!