Transport extensions for NServiceBus.Transport.AzureServiceBus

Hello everyone,

I’ve update package for Azure ServiceBus transport from NServiceBus.Azure.Transports.WindowsAzureServiceBus to NServiceBus.Transport.AzureServiceBus. I can’t find some settings that were in place in previous library.

  1. ForwardDeadLetteredMessagesTo() from AzureServiceBusQueueSettings
  2. LockDuration() from AzureServiceBusQueueSettings
  3. Sanitization() with UseStrategy method.

Where can I find them nowadays? How to setup things mentioned above?

Will appreciate any help.
Thanks

1 Like

Hi Petr,

The NServiceBus.Transport.AzureServiceBus package is a completely different transport. Unlike the legacy transport, NServiceBus.Azure.Transports.WindowsAzureServiceBus package, it has been designed with the guidelines of making the transport simpler and remove the features and configuration that no longer needed.

The old transport was overriding the settings whenever an endpoint would restart. That’s one of the reasons why it was important to set the settings via configuration API. With the new transport that’s not the case. The new transports sets reasonable and optimal values by default. Also, settings configured by customers will be respected and not modified.

  • ForwardDeadLetteredMessagesTo() - auto-forwarding can be configured per queue in a controlled manner (x-plat CLI, PowerShell, or ARM).
  • LockDuration() - maximum lock duration time is five minutes. The transport sets that by default.
  • Sanitization() is replaced with shorteners that can be registered for subscriptions and rules. See Entity Creation section of the transport configuration.

All configurations available for the transport are here: https://docs.particular.net/transports/azure-service-bus/configuration.

1 Like

Thanks for quick answer. It will be beneficial to have this information in official documentation. For example in migration guide. Thanks!

One more question about sanitization. As mentioned above I can use shorteners. Does it imply that I need to write this functions om my own? Does it worth to try to reuse ValidateAndHashIfNeeded class that has this logic already? Will this class be removed or changed to be easily used as a Shortener func? I don’t want to introduce a new shortener/hashing logic so newly created queues/topic/sub/rules names won’t correspond to the old one.

What is the way of doing that?

Hi Petr,

If you’ve used ValidateAndHashIfNeeded in your project before with the legacy ASB transport and entities were sanitized/shortened, you will need to apply the same shortening logic with the new transport to stay backwards compatible. With queues and topics it’s slightly different. The transport will throw if a queue is not a valid queue name. If it was sanitized in the past, you will need to use the sanitized name for your endpoint. It’s unlikely, as it would mean more than 260 characters long. Same goes for the topic. The default system topic name is bundle-1. Unless it was overwritten, you won’t have to do anything. In case it was, TopicName() configuration API will allow to set it to what your previous topic name was.

As a rule of thumb, if a setting is not available, then it’s not needed. The optimal defaults are applied.

Hello Sean,

It doesn’t fully answer my answer. I got from your message info about what and when I must perform but part “how” is still not clear. This hashing/shortening functions are in NServiceBus.Azure.Transports.WindowsAzureServiceBus nuget. Now I reference NServiceBus.Transport.AzureServiceBus nuget. What is the best approach from your opinion about reusing logic from ValidateAndHashIfNeeded ?

The code for ValidateAndHashIfNeeded is available in the public repository here.

Thanks for a link Sean! But it doesn’t completely answer my question. I will try to shape it differently.

Does the Particular company state that the official migration guide from old transport library to a new one includes step of coping some code from NServiceBus repository to private repository of a company?

Can you confirm that partial coping of sources from your repository and using it on a Production for gaining financial benefits is not breaking license agreement?

Per the document you’ve linked to, as long as you’re paying for the NServiceBus license or your code is open-source, you are not breaking the license agreement.

Note: the link to the EULA was broken. There’s a PR to update it in case you’d like to review the changes. The EULA URL is Non-Production License Agreement • Particular Software.

1 Like

Thanks a lot for your time Sean. I appreciate your help.

1 Like