The forwarding topology was introduced to take advantage of the broker-style native capabilities of Azure Service Bus. It is the recommended topology for new projects. The new Azure Service Bus transport is only compatible with the forwarding topology.
Before migrating to the new Azure Service Bus transport, a system using the endpoint-oriented topology must be migrated to the forwarding topology. The migration approach described here allows migration of individual endpoints to the forwarding topology in any order, and avoids a big-bang style migration.
Before migrating endpoints to the forwarding topology, all endpoints must have migration mode enabled. To enable migration mode:
- Pick an endpoint that is using the endpoint-oriented topology. That is, any endpoint configured with
- Update the
NServiceBus.NuGet package reference to Version 9.1 or higher.
Azure. Transports. WindowsAzureServiceBus
- Enable migration mode by calling
topologyis the object returned by
transport.. Leave all the other configuration as-is.
After applying the above steps to one or more endpoints, they should be deployed to production. This cycle should be repeated until all endpoints using the endpoint-oriented topology have migration mode enabled.
ServiceControl should now be upgraded to Version 3.5.0 or later and both ServiceControl and Monitoring instances should be updated to latest. The migration mode is enabled automatically.
After all the endpoints have been running in production for some time with migration mode enabled, they can be migrated to the forwarding topology by switching to the new Azure Service Bus transport as described in the next section.
When all endpoints using the legacy transport are running in migration mode, they can be migrated to the new transport. Before that is done, their compatibility with the new transport should be verified, as described in the compatibility guide. To migrate from the legacy transport:
- Uninstall the
Azure. Transports. WindowsAzureServiceBus
- Install the
- Delete any non-compiling code such as
transport.and remove any routing configuration code described in "Publishers name configuration".
- If more advanced configuration options have been used with the legacy transport, switch those over to the new configuration options where possible. For configuration options that are not available in the new transport, defaults selected specifically for the new transport will be applied.
After applying the above steps to one or more endpoints, they should be deployed to production. This cycle should be repeated until all endpoints have been migrated to the new transport.
ServiceControl and Monitoring instances should now be switched switched to
Azure Service Bus transport using ServiceControl Management Utility.
After all the endpoints have been running in production for some time using the forwarding topology, the endpoint-oriented topology topics with their subscriptions can be removed.
To understand this section better, refer to the topologies documentation for details on how the endpoint-oriented and forwarding topologies operate.
Migration mode has no impact on commands, it only affects events. It does not change how events are published. It only changes how events are subscribed to. Endpoints running in migration mode will continue to publish events using endpoint specific topics. Subscribers running in migration mode change the way they subscribe to events. Subscribers running in migration mode will no longer fetch messages from subscriptions. Instead, they will perform the following:
- Create forwarding topology subscription entities if not yet present; a
bundle-1topic for all events, a subscription per subscriber endpoint, and a SQL filter per event type (in green). A subscription will auto-forward an event to the endpoint's queue.
- Create a
migrationtopic, if not yet present, that performs de-duplication and auto-forwards events to the
bundle-1topic (in red).
- Auto-forward all events arriving at
subscriptions from the endpoint specific topic
migrationtopic (in grey).
Below is an example of a publisher with two events,
EventB, and a subscriber consuming those events. When an endpoint is running in migration mode, the topology is as follows:
Q: Why is the
migration topic required? A: When an instance of a publisher is been migrated to the forwarding topology, and another instance is still in migration, all events published by the endpoint still in migration need to be de-duplicated. The
migration topic ensures events are de-duplicated regardless of which instance published them.
Q: What should be migrated first, subscribers or publishers? A: The order of migration doesn't matter. A publisher could also be a subscriber and the other way around.
Q: Can I add a new endpoint while in migration mode? A: Yes.
Q: Are commands affected by migration mode? A: No. Commands work the same way in both topologies and are not affected by migration.