# Azure Service Bus Topology Options

<!-- Version variant: asbs_5; default: [/samples/azure-service-bus-netstandard/options/index.md](/samples/azure-service-bus-netstandard/options/index.md) -->


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 -->

> [!NOTE]
> While in the vast majority of cases there is a one-to-one correspondence between event types and topic names, `SubscribedEventToTopicsMap` maps arrays of topics in order to support [event inheritance](/transports/azure-service-bus/topology.md#subscription-rule-matching-interface-based-inheritance). Due to a limitation of the .NET configuration infrastructure, it is not possible to provide a converter that simplifies the syntax in a way similar to when [loading the topology configuration directly from json](/transports/azure-service-bus/configuration.md#entity-creation-topology-mapping-options).

### 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`.