Azure Service Bus - Topic Subscription Name

[DaleyKD]

BRAND new to Dapr (just started looking today).

Our current infrastructure has already set up a Service Bus Namespace with a single topic (also many queues; that's for later). Then in that topic, we have 8 subscriptions. These are named SIMILAR to what we call the microservice. Then, within each subscription, the $Default filter is removed, and the name of the event is added as a correlation filter.

I see where I can specify the consumerID (which appears to be the name of the subscription) via the component YAML, but how could I do all of this via code?

[brettveenstra]

I don't believe a Subscription filtering is available to do what you're asking. If you let Dapr manage the service bus setup (disableEntityManagement="false") , Dapr-ized applications that subscribe to the topic in your component file will automatically create a subscription.

If that is not acceptable, perhaps you can describe your use case a little further? Are you looking to only send a certain ContentType to Dapr for example?

[halspang]

@DaleyKD - I believe the consumerID defaults to your app ID, but I think that's all we really have. If all you want to do is filter messages, we do have the ability to do that, but I don't think we do on the correlation ID. I'd also love to hear more about your use case.

[ferryferry]

I think the thing @DaleyKD want to achieve is to set service bus subscription filters (SQL syntax or Correlation Filters - the names Microsoft assigned to the two different kind of filters you can apply on a service bus topic subscription) based on the DAPR yaml file.

We have something similar - we have one topic for all the application events, which come from different application domains; License management, email service, payment provider, EDI solution.

These applications all NEEDS to listen to each-other if they need to. For example, we want to trigger something in the payment provider when someone creates a new license in our license management tool. Or if we completed a payment in the payment provider, we want to send an e-mail to the customer.

Right now, we can have the sidecar hooked-up to a service bus topic subscription but it get's poked every time a new event comes in even if it's not interested in that event. It filters inside the DAPR sidecar by using message routes. Whereas if you set a subscription filter on the Azure Service Bus side, it will not even reach the sidecar because the topic decides to not forward the message to the subscription filter based on filter evaluation.

For this example specifying subscription filter cuts out a lot of overhead and saves resources on the sidecar by not poking the service for 90% of the messages which are not relevant to the service.

So basically our message topic serves as an integration point for all services (The central highway).

[eduards-vavere]

We have the same architecture. Any movement on this?