使用不同的接收器实例查看和完成消息 - Azure 服务总线

Question

Scenario

When business transactions are performed, we're supposed to make that data available to end clients.

Current Design

Our web app publishes transaction messages are added to a topic on the Azure Service Bus.

We expose APIs to clients through which they can consume the data from those transactions.

Upon calling these APIs, we read the messages from the Subscription and return it to the client.

Problem

We want a guaranteed delivery - we want to make sure the client acknowledges the delivery of the data. So we don't want to remove the message from the subscription immediately. We want to keep it until the client acknowledges it.

So we only want to do a "Peek" instead of "Receive".

So the client calls the first API, to get the data, where we do a Peek.

And once the client has received the packets, the client would call a second API, to acknowledge. At this point, we want to remove the message from the Subscription, making it Complete.

The current design of the Service Bus Message Receiver is that, a Complete can be performed only using the same Receiver instance that performed the Peek, as per the documentation, and we also observed the same when we tried it out.

Both the APIs, are two separate APIs and we cannot do the Peek and Complete using the same instance of the Receiver.

Thinking about options to somehow make the Receiver as a Singleton, across APIs within that App Service. However this will be a problem when the App Service scales out.

Is there a different way to achieve what we're trying to do here?

Answer 1

There is an option available in Azure Service Bus to defer messages. Once a message is deferred, it can be received with the help of it's sequence number.

The first client should receive the message and instead of completing it, it should defer it and return it.

The second client (which has sequence number) can receive the message from the Subscription. Refer here for more details.

Answer 2

Another option would be to not use a Service Bus Client on your backend and instead your clients could directly work with Service Bus using its Service REST API (assuming they can't use the AMQP client if I am understanding your scenario correctly).

There are APIs to

• Peek-Lock
• Renew Lock
• Unlock
• Delete (Complete)

You could also proxy these requests if you'd like using your backend itself or a service like APIM if you are already using it.

PS: Cross posting the answer for the same query on the MSDN forum