Using peak and lock patter inside Azure Trigger function for service bus topic in java(maven)

Question

Hello everyone,
How can I implement the Peek and Lock pattern within the ServiceBusTopicTrigger in Azure Functions without creating a new receiver for receiving messages? I have an Azure Function that successfully receives messages from the Service Bus Topic, but the problem is that the service automatically deletes the messages. I must process the messages based on the quantity and either complete or abandon them. How can I achieve this using the Peek and Lock pattern without creating a new receiver within the function?

// This is my azure function

public class ServiceBusTopicTriggerJava {

  /**
   * This function will be invoked when a new message is received at the Service Bus Topic.
   */
  @FunctionName("ServiceBusTopicTriggerJava")
  public void run(
      @ServiceBusTopicTrigger(
          name = "message",
          topicName = "aftopic",
          subscriptionName = "afSubscription",
          connection = "ServiceBusConnectionString"
      ) final List<Sales> message,
      final ExecutionContext context
  ) {
//log go here

  }


//This is my pojo data
@Data
@Builder
public class Sales {

  private String id;
  private String itemId;
  private String itemName;
  private double quantity;
  private double price;

}
// this is my message from service bus

[{"id":"6a2a7d07-1b0c-48db-9753-3f32d619ebd5","itemId":"123","itemName":"Item 123","quantity":35.0,"price":10.0}]

Answer 1

@Marko Bozic The default behavior is peek-lock itself, but it is tied to the successful execution of your function. If the function succeeds, the message is completed and otherwise is tried until the configured maxRetries value in host.json.

In C#, you can bind to the MessageReceiver instance but unfortunately this isn't possible for non-C# languages. Even if you were to build the receiver instance, you can't complete/abandon the message since the lock token isn't available to the function.

The workaround here would be to instead create a new message for failures into a different queue to schedule work for the future. This is like what dead lettering looks like except that you would use a queue managed by you instead of the dead letter sub queue.

Also, there is this issue that tracks this but hasn't seen any traction.