Azure-webjobs-sdk: Add ServiceBus QueueClient binding

[mathewc]

In the new .NET Core ServiceBus SDK, the BrokeredMessage type was removed and changed to Message. As part of that SB SDK change, all the message operations (Complete, Abandon, etc.) no longer live as methods hanging off the message. Since BrokeredMessage contained all these queue operations, we never added a binding to bind to a SB queue directly it seems.

Therefore, we need to add direct QueueClient binding capabilities, similar to the way our Azure Storage Queue binding allows you to bind to a CloudQueue:

public static void ProcessWorkItem(
    [QueueTrigger("test")] WorkItem workItem,
    [Queue("test")] CloudQueue queue)
{
    Console.WriteLine($"Processed work item {workItem.ID}");
}

For ServiceBus that would then be:

public static async Task ProcessWorkItem(
    [ServiceBusTrigger("test-items")] WorkItem item,
    [ServiceBus("test-items")] QueueClient queueClient,
    string messageId
    ILogger log)
{
    log.LogInformation($"Processing ServiceBus message (Id={messageId})");
}

This queue binding allows you to bind to any queue, and is generally useful both for SB triggered functions as well as other functions, e.g. if you need to bind to a queue to write messages as part of processing a storage blob. In addition to allowing binding to a queue using the attribute, we should also support a direct binding to the queue for the triggering message:

public static async Task ProcessWorkItem(
    [ServiceBusTrigger("test-items")] Message message,
    QueueClient queueClient,
    string messageId,
    ILogger log)
{
    log.LogInformation($"Processing ServiceBus message (Id={messageId})");
}

The direct binding to the client for the triggering message isn't something that is strictly required - our Azure Storage queue binding doesn't support it. However, I think it'd be a good addition for both bindings, since it allows you to bind to the client for the triggering message without repeating the queue details via the attribute.

[ryancrawcour]

Agree that the change from BrokeredMessage to Message and losing access to methods like Abandon(), Complete(), Deadletter() has caused some problems with some current scenarios. So putting this back in would be awesome!

[ryancrawcour]

The docs for QueueClient say to use MessageSender or MessageReceiver for advanced set of functionality.

Would it make sense to (also) expose access to MessageReceiver and MessageSender?

We need to support Topics and Queues.
AFAIK for Topics support we might need to have MessageReceiver exposed.

[ryancrawcour]

QueueClient.CompleteAsync method (and others like AbandonAsync, DeadletterAsync etc.) require a locktoken …

This property used to exist on BrokeredMessage, but I see has since moved to Message.SystemPropertiesCollection.LockToken so we'd need to expose a way to get at this LockToken in order to be able to use these methods on QueueClient.

[mathewc]

Will also consider adding binding support for MessageSender/MessageReceiver.

Regarding access to the lockToken. We'll provide a way to bind to the lockToken for the message directly, as is done for the string messageId param in the sample code above.

[SeanFeldman]

I see has since moved to Message.SystemPropertiesCollection.LockToken

Message.SystemProperties.LockToken

The docs for QueueClient say to use MessageSender or MessageReceiver for advanced set of functionality.

I'm not sure if using anything other than MessageSender and MessageReceiver would provide additional benefits.

1. Entity specific clients (QueueClient, SubscriptionClient) cannot handle entities other than the ones they are designed for.
2. Entity specific clients are for convinience such as message pump and do not expose other Receive methods.

[SeanFeldman]

When adding support for clients (all the extenders/implementors of IClientEntity), please add support for configuration to register ServiceBusPlugin plugins as well.

[mathewc]

Guys - I have a PR for this here: https://github.com/Azure/azure-webjobs-sdk/pull/1753

I ended up adding bindings for MessageReceiver/MessageSender. It'd be good if @SeanFeldman @ryancrawcour could take a look.

[ryancrawcour]

Looks good to me @mathewc

[ryancrawcour]

I'll pass a link to this to the dev that ran in to the issue and get their input too.

[SeanFeldman]

@mathewc I've briefly looked at PR. It doesn't look like the trigger will be supporting transactional processing. Or is this going to be added later?

[mathewc]

Any new features around transactions would be orthogonal to this. We're not tracking that - recommend you log a new issue with details on the scenarios you'd like to have enabled, thanks.

[SeanFeldman]

@mathewc it's there, patiently awaiting for almost two years 🙂 #788