# Azure Service Bus Topology Options


This sample shows how to leverage topology options to layout the topic topology used within the Application configuration. The sample uses the generic host for convenient loading of configuration via the built-in configuration provider model. The `appsettings.json` is used for demonstration purposes and technically the options could be loaded from other sources.

## Prerequisites

An environment variable named `AzureServiceBus_ConnectionString` with the connection string for the Azure Service Bus namespace.

## Code walk-through

The sample contains three executable projects:

* `Publisher`: an NServiceBus endpoint that publishes `EventOne` to topic `event-one` and `EventTwo` to `event-two`.
* `Subscriber`: an NServiceBus endpoint subscribing to the `EventOne` and `EventTwo` event published by the `Publisher`.

### Configuration from options

With the generic host's ability to load configuration sections, it is a matter of loading the topology options from the section in the Application configuration as shown below:

<!-- snippet: OptionsLoading -->

```cs
var section = builder.Configuration.GetSection("AzureServiceBus");
var topologyOptions = section.GetSection("Topology").Get<TopologyOptions>()!;
var topology = TopicTopology.FromOptions(topologyOptions);

var transport = new AzureServiceBusTransport(section["ConnectionString"]!, topology)
{
    Topology =
    {
        // Validation is already done by the generic host so we can disable in the transport
        OptionsValidator = new TopologyOptionsDisableValidationValidator()
    }
};

endpointConfiguration.UseTransport(transport);
```

<!-- endsnippet -->

In this example, the publisher overrides the default topic destination to a custom convention instead of using the default fullname of the event type:

<!-- snippet: PublisherAppsettings -->

```json
"AzureServiceBus": {
    "ConnectionString": "Endpoint=sb://...;SharedAccessKeyName=...;SharedAccessKey=...",
    "Topology": {
        "PublishedEventToTopicsMap": {
            "Shared.EventOne": "event-one",
            "Shared.EventTwo": "event-two"
        }
    }
}
```

<!-- endsnippet -->

The subscriber needs to override the subscription mapping accordingly:

<!-- snippet: SubscriberAppsettings -->

```json
"AzureServiceBus": {
    "ConnectionString": "Endpoint=sb://...;SharedAccessKeyName=...;SharedAccessKey=...",
    "Topology": {
        "SubscribedEventToTopicsMap": {
            "Shared.EventOne": ["event-one"],
            "Shared.EventTwo": ["event-two"]
        }
    }
}
```

<!-- endsnippet -->



### Validation

The transport provides integration with Microsoft.Extensions.Options and has a built-in options validator. With the generic host, it is possible to register the validator to make sure the configuration loaded fulfills the requirements of the broker (e.g. topic name length) and is self-consistent.

<!-- snippet: OptionsValidation -->

```cs
services.AddSingleton<IValidateOptions<TopologyOptions>, TopologyOptionsValidator>();
services.AddOptions<TopologyOptions>().Bind(configuration.GetSection("AzureServiceBus:Topology")).ValidateOnStart();
```

<!-- endsnippet -->

## Running the sample

1. First, run the `Subscriber` project by itself. This will create all the necessary publish/subscribe infrastructure in Azure Service Bus.
2. Run the projects normally so that all endpoints start.
3. The `Publisher` endpoint continuously publishes two events with a short pause in between.
    * The endpoint in the `Subscriber` window receives both `EventOne` and `EventTwo`.