Simple vs. advanced API set about azure-service-bus-dotnet

[SeanFeldman]

Keep clients in the root namespace, and move sender/receivers to a separate namespace. We would like to keep the root namespace as simple as possible, allowing new customers to get started quickly without the need to learn too many concepts.

Remove static create methods from the clients, and instantiate them through constructors.

Some sort of connection pooling for clients, and allow customers to implement their own pooling algorithms for senders/receivers (this would come much later though).

👍

@jtaubensee are you omitting the following on purpose from client?

• Path
• AbandonAsync(Guid, IDictionary<String, Object>)
• DeadLetterAsync(Guid, string, string) / DeadLetterAsync(Guid, IDictionary<String, Object>)
• DeferAsync(Guid, IDictionary<String, Object>)
• FormatDeadLetterPath(String)

And the following:

• Batching
• Sessions
• PeekAsync(*)
• SendAsync(BrokeredMessage)
• SendBatchAsync(*)

will be handled with MessageSender/Receiver?

Limit clients to a message pump model (i.e. OnMessage), and reserve direct receive calls for the MessageReceiver.

Question I'd ask the team is you think for a persona that starts with ASB, is OnMessage pump a simpler concept than send/peek/receive individual message?

[jtaubensee]

Hey @SeanFeldman,

I think the goal is to start with the simplest API possible. And worst case scenario, we can always add something back in. I think the most important piece is that we establish, that the clients are the simple Service Bus programming model, and Sender/Receiver are for more advanced scenarios.

Regarding:

@jtaubensee are you omitting the following on purpose from client?
Yes, we are. At least to start with. These would still be available in the Sender/Receiver.

and for:

will be handled with MessageSender/Receiver?

• Batching - Sending batches will be supported with SendAsync(IList<BrokeredMessage> messages);, but receiving batches will not be supported as the only receive model is OnMessage.
• Sessions - The SessionHandler is in the clients
• Peek/Browse is reserved for the Sender/Receiver

Lastly, I think that for a simple console application, receive may be easier, but OnMessage is a much better way to go for any long running application. We often times see customers write their own receive pumps incorrectly.

[jtaubensee]

This was completed in #95 and the next steps of this are:

• #57 - Updating the MessageSender and MessageReceiver
• #98 - Message refactoring

[markbeij]

While upgrading my Azure Function from V1 to V2, I stumbled upon missing a method like to use:
BrokeredMessage.DeadLetterAsync(string, string). The idea of spitting simple and advanced API set is great, but how should I deal with this situation?
I used this function to be able to add Dead letter reason and description when the last attempt failed. If I don't do this, I get MaxDeliveryCountExceeded, which is not telling me much.
Hope to learn the right approach for this situation.

[SeanFeldman]

API is not missing. It has changed.
The new client no longer allows operations on Messages directly. Instead, you need to go through specific clients that have received those messages.

So to achieve that, you'd need something like this:
await queueClient.DeadLetterAsync(message.SystemProperties.LockToken, reason, description);

[markbeij]

Thanks, I will try that

[markbeij]

But how to get to the client from within an Azure Function?

I can't create another client object and pass the lock token in there like this:

[FunctionName("MyFunction")]
public static async Task Run([ServiceBusTrigger("mytopic", "mysubscription", Connection = "ConnectionString")]Message message, ILogger log)
{
    log.LogInformation($"C# ServiceBus topic trigger function processed message: {message}");

    var connection = new ServiceBusConnectionStringBuilder("sb://myendpoint", "mytopic/mysubscription", "MySharedAccessKey", "MySharedAccessKey");
    var client = new SubscriptionClient(connection, "mysubscription");
    await client.DeadLetterAsync(message.SystemProperties.LockToken, "deadLetterReason", "deadLetterErrorDescription");
}

I will get the following exception:

Microsoft.WindowsAzure.Storage.StorageException: 'Not Found'

[SeanFeldman]

@markbeij you cannot instantiate a new client, you have to use the same client used to receive the message. My assumption is that you have to declare it as an argument for your Function. But this is not ASB question thought, would you agree so? Rather, an Azure Functions question a different team would more than happy to answer 😉

Also, note that Functions are opinionated. You might not be able to complete or dead-letter because that's handled for you. Think of it as a MessageHandler on steroids. Documentation is here.