Azure-webjobs-sdk: ServiceBusTriggerAttribute is sealed? How do I derive?

[RonakThakkar]

Hi,

I found that ServiceBusTriggerAttribute is sealed class. I would like to derive from this class and create custom attribute which would automatically generate topicName and subscriptionName internally as per our product specification. I can then deliver this custom triggger to all developers in my team to use.

Could you please let me know the solution to this problem?
Is that possible for you to remove sealed for this class?
Can I remove the sealed attribute and create my own nuget package for this?

[mathewc]

All the attributes are sealed by design (Queue/Blob/Table/ServiceBus/etc.). Deriving from the attribute to customize behavior isn't the right solution.

For me to be able to help with the right solution, I need to understand the problem more. What do you mean generate topic/sub names? When does this need to happen? Can you detail the scenario more?

[RonakThakkar]

I would provide you an example of what I would like to achieve.

Currently ServiceBusTrigger takes topicName and subscriptionName as input.

Hence developers need to provide something like ServiceBusTrigger("business-command-topic", "CalculateCustomerSize").

Instead I would like my developers to use my custom attribute that internally handles this topicName and subscriptionName passing. Hence my developers should be able to use my custom attribute like CustomerBusinessTrigger as

public static void CalculateCustomerSize(CustomerBusinessTrigger Customer customer);
{
}

This would ensure consistency in my internal logic

I would like this CustomerBusinessTrigger to derive from ServiceBusTrigger attribute to take advantage of built-in features of ServiceBusTrigger attribute. Otherwise I would have to write all the logic on my own.

[mathewc]

.NET guidance is to seal attributes for good reasons. Are your topic/subscription names static? If so you could define constants for these, and the attributes would be [ServiceBusTrigger(CommandTopic, CalculateCustomerSize)]. Is that so bad? :)

[RonakThakkar]

I saw some samples using static / constants. This might work for me as of now, but it might become a bottleneck for me in future as I might have a lot of subscriptions (subscription for each function) under business topic. In that case I would like to group set of subscriptions into separate topic per module. But I would like this logic to be at one place so that I do not need to update the code at all the places when I decide to do so in future.

Am I allowed to download the source code from GitHub, make ServiceBusAttribute class public and then create my WebJobs SDK Nuget Packages which I can store locally and use internally in my product.

[mathewc]

The project is open source, so you're free to fork and modify as you see fit (within the license guidelines).

I've thought on this more, and there isn't any workaround currently for you that I can see. I'm also still very hesitant to unseal the core attributes. If we did it for ServiceBusAttribute, the same arguments would apply to BlobAttribute and the others - you could argue that they should be unsealed as well.

One final possibility: if it's the case that you want to control these values per assembly/JobHost, then you might be able to use JobHostConfiguration.INameResolver to control your naming. The way it works is, if you use %% delimited values in your attributes (e.g. [ServiceBus("%command%", "%subscription%")] those values will be resolved at binding time by calling into the INameResolver instance that you registered. Your custom logic will get the names "command" and "subscription" and you return the value to use. You could define/use constants for those %command% %subscription% strings if you wanted. The main difference between using INameResolver v.s. using constants is that you could pull the values from app settings, etc. dynamically.

[RonakThakkar]

Hi,

I tried using INameResolver but that solution is error prone and not Intuitive for my developers.

Also I ran into other use cases that require me to have this class Public. I created a new issue where I mentioned all those issues that I am facing.

https://github.com/Azure/azure-webjobs-sdk/issues/600

We tried to download code and build our own packages but that does not work.

I hope you understand that we are using Azure Service Bus extensively in our enterprise application and we are in tough time due to above scenarios.