I've very basic architecture:
Web API queue message in a Queue and a Worker (back processing service) is dequeue and processing the message.
The problem is that the Web API doesn't know when the messaged has been processed by the Worker.
Can the Worker alert the Queue that the message has been process successfully and the Queue send back to the Web API "Process Complete Message" Event ?
One solution that I was thinking on:
After the Web API queued the message it checks every couple of second the message status:
If the message status is with "Peck-Lock" - the message is still been processing.
If the message not found on the Queue - the message has been processed (successfully or unsuccessfully it doesn't matter).
But there isn't a pre-made solution to this from Microsoft ?
Many architectures that need this type of reporting back are handled by a separate queue, going from the processor to the requester. That's why there's actually even a ReplyTo property on the BrokeredMessage object. The approach would be the requester would have it's own queues that it was watching as well. When it creates a message it sets the ReplyTo property and sends it on. When the worker processes the message it sends a completion message back to the requester using the queue path provided by the original message.
Depending on your needs you may have a single queue for your entire front end, or each instance may have it's own queue. Note that in a distributed system with machines that can be transient, having each Web API front end have its own queues can introduce some complexity.
Usually this is done when the requester needs to know something is completed so it can communicate that in some manner. For example, an web request comes in to do processing. The request is put on the queue and processed in the back end, and a completion message is returned back to the front end where it's picked up and a notification is sent to the user (in some cases via SignalR, which with a backplane in place you'd not have to worry about which front end server received the response message).
Other than communicating the completion either through direct communication to the requester, or via a queue, there is nothing that allows you to watch for a completion of a message from another machine. Checking the message status won't help you because that information won't change unless you are getting a new reference to the message regularly which will not scale well if you have a lot of messages your dealing with.