Azure Service Bus transport works with the Messaging namespaces and operates on four types of entities: queues, topics, subscriptions, and rules. Entities have their paths and names derived from NServiceBus endpoint and event names. Entities have path and name rules applied to:
- Allowed characters
- Maximum length
When entity name does not follow the rules, an exception is raised by the broker and transport fails to start. Paths and names need to be validated and adhere to the Azure Service Bus service rules.
|Entity Type||Valid Characters||Path / Name Maximum Length|
|Queue||Letters, numbers, periods (||260|
|Topic||Letters, numbers, periods (||260|
|Subscription||Letters, numbers, periods (||50|
|Rule||Letters, numbers, periods (||50|
When sanitization strategy is specified, the validation settings can be overridden. The validation settings determine how entity names are validated. They should correspond to the validation rules in the configured Azure Service Bus namespace. The rules implementations vary depending on the namespace type, and are changing over time (in some cases without notice and update of the relevant MSDN documentation). The default settings align with the recently created Standard namespaces.
Sanitization is an operation that is performed on an entity path or name to ensure the broker can operate on the entity, and no exception is thrown. Sanitization can be performed manually or by the Azure Service Bus transport.
To perform manual sanitization, inspect entity name for invalid characters and number of characters. For automated sanitization, the transport allows configuration outlined below.
All entities treated the same for allowed characters. Only letters, numbers, periods (
.), hyphens (
-), and underscores (
_) were allowed. Maximum length was predefined by the transport.
In Version 6.4.x Naming Conventions were added to allow custom sanitization of queues, topics, and subscriptions.
When implementing custom sanitization, consider factors such as readability and discover-ability. Things to consider:
- Truncated long entity names could conflict.
- Hashed entity names could lead to difficult names to use during production troubleshooting or debugging.
- Sanitized entity names stay in the system and cannot be replaced until no longer used.
- Composition strategy needs to work in conjunction with custom sanitization.
HierarchyCompositionis used, the generated path must be shared with the custom sanitization strategy and be exempted from sanitization.
- Define endpoint name as short and meaningful.
- Avoid message definitions in deep-nested namespaces.
- Keep event names descriptive and short.