I'm adding service bus message queues to an integration platform when sending data to the third party applications.
Requirement:
If the third party application is down/network issue/data issue, the process should stop processing the queue. It should hold the entire queue until the 3rd party system is up or data issue fixed.
If the processing get failed, need to send an email but the message should not moved to the dead letter queue.
The message should retain at the same point until it can proceed. So that entire queue is on hold state.
Is there any way of handing this flow using Azure service bus Message Queues? or any alternative ways of achieving this?
Regards,
Normally, I believe it would be best if the integration platform could be "paused" during the failure and re-activated once the downstream issues are fixed. This could either be a manual process or an automated one if possible.
That being said, Service Bus does provide the ability to suspend entities (queues, topics, subscriptions). Once aware of a problem, you could disable receiving on the entity the integration platform is listening on. This could be automated as well.
Related
We're cleaning up some Azure resources and have come across a service bus that seems to have activity, but doesn't have any queues or topics. My understanding is that without one or the other of these, you can't send or receive messages. Is there any way to track down where the requests are coming from?
Incoming requests is not just messages. It could also be management operations such as getting namespace information.
Your best bet is to open a support case to understand what's being invoked.
Using Azure Service Bus - Topics, I want to implement a solution wherein messages are sent/notified to end consumers once the producer sends the message to Topic (like Queues).
I understand that Topics work as Pub/Sub model wherein subscribers need to read messages from subscriptions. But I'm looking for a workaround that works some what similar to Queue (where it triggers a web job / service when any message is received).
I have few thoughts like
1. Using Auto-Forwarding in subscriptions to forward messages to Queues but again I think if this kills the purpose of Topics
2. Schedule a job to process these requests but again I think if I'm delaying the process
First, I want to know if Service Bus Topic is right option to go with? Next, If possible to implement a workaround what is the best/better way?
PS: I have to send messages which has information - I guess I can't use Relays
Just to be clear, Queues and Topics in Service Bus are different. As you noted, Topics are useful in publish/subscribe scenarios.
Since you are looking for something that gets triggered, Azure functions might be what you need.
Azure Functions supports trigger and output bindings for Service Bus
queues and topics
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus
I think that #William is right, you can use/attach other process to the subscription to make what you trying to do.
he mentioned Azure Functions which is a good tool and I want to suggest Azure Logic Apps as well in case you want to take some decisions based in the message that you received.
With Azure Logic Apps you can create a logic Workflow and integrate many services using connectors provided by this tool.
You will find more in:
https://learn.microsoft.com/en-us/azure/connectors/connectors-create-api-servicebus
And for answer your question
First, I want to know if Service Bus Topic is right option to go with?
The quick answer is yes, using messaging patterns is the best way to create reliable solutions.
In your case you want as well notify another system after receiving a message.
The only thing that you need to be aware is, whenever you did not receive the notification what you'll do? you need to think about this scenario.
From discussion above.
Azure functions with Queues/Topics
Regardless of queues or topics. you can trigger azure function with both. This function will process the message . Now you can create two methods in same function SendEmail(), sendPhoneNotifcation() and parrellize the tasks using C# task parallel library. So same function will do both tasks in parallel.
Every time you get a message , your function is triggered. Process the message and notify user. The benefit is this function will scale automatically if you have large number of message coming through queue.
Similar past question of mine: Azure Service Bus Queue: Can I manage/cancel scheduled messages? - accepted answer here details how to cancel scheduled messages.
I'm wondering now if there's a way to view scheduled messages using the AMQP APIs. The Azure UI (and this method https://learn.microsoft.com/en-gb/java/api/com.microsoft.azure.management.servicebus._message_count_details?view=azure-java-stable) offer message counts but I can't see anything that lets me actually view those messages.
Is this a limitation of the service bus/Azure architecture? Or is there an API that will allow it? My goal would be to build a nice UI that displays scheduled tasks, and ideally I'd like to do that without maintaining that list of tasks myself outside of Azure if possible.
As of today, all messages can be peeked, but there's no way to peek those based on message status. There's an open issue on GitHub for the broker to add this feature. You can leave use-case scenario to help product team to have an idea why a feature as such would help customers.
Adding some information I found useful while reading about this.
Azure Service Bus Queues allows browsing/peeking scheduled messages.
Azure Service Bus Subscriptions does not support this feature yet.
Read More
View Example
could you give me some advice to establish an architecture for the next scenario using the Azure services?
From Central Server, I need to be able to send messages only if the Agent i is online.
I need to receive confirmation to know if a message was delivered or not
The communication is One-way Central Server to Agent i
Can be multiple agents in the future
The correct order of messages must be guaranteed
i is any agent 1 to x
I was thinking to use Azure Service Bus, but I'm not sure if this is the best strategy. I could to have a queue for each agent, but according what I saw in the examples, I can not receive confirmation when a message was delivered, In addition I didn't see any function to know if a receiver is online or not.
Thanks!
Your scenario is more towards real-time acknowledgement and it would be difficult using service bus. Have your considered "Azure SignalR Service" for this?
Our application consist of 7 microservices that have some intercommunication. Currently we're using simple storage queues that a microservice publish events to (the number of events is relative low). Then we have a azurefunction for each queue that might call another microservices. This is working fine for us right now the services uses about 20 queues with a corresponding function.
Now we need to handle an blobstorage event, and I did some googling and a started to get really confused. Suddenly there was a lot of questions:
Should we switch to Azure Event Grid
It handles blobstorage without any limitations (functions blobstorage trigger has some)
It allows for multiple subscribers (storage queues does not)
It has a lot of fuz - maybe this is the new recommended way
I like the idea of one central thing, but it reminds me a bit about biztalk...
Should I switch to Azure Service Bus
It has a nice tool (ServiceBusExplorer) for monitoring the queues and listners, and I could to a repost of any failed events
It visulizes my azure functions subscribers nicely
Should I continue with only storage queues
A bit difficult to monitor, but it works nice
I'll be really thankful for any advice or insights to this question.
Thanks
EventGrid is great when you have notifications floating to multiple subscribers. Is that the case for you?
An example would be deferring messages. With queues you can defer a message, not with EventGrid. Whenever to choose Storage Queues or Service Bus depends on the specific requirement that you have. Do you need de-duplication? Or ordered delivery? If you do, Service Bus is the way. Otherwise Storage Queues is enough.
First of All, I would like to recommend these two articles, it will clarify most of your doubts about these services:
Choose between Azure services that deliver messages
Storage queues and Service Bus queues compared
Regarding Event Grid, it acts like a bridge between the publisher and the subscriber, where publisher will send messages and forget whether it has been processed or not, and the Event Grid will handle the retry if the receiver\subscriber does not acknowledge that it was processed successfully.
As you mentioned, storage queues has limitations, as such blob triggered functions, and maybe Service Bus, but it will depend on your design requirements. I would like to point out some things you might consider before moving to Event Grid.
Storage queues & Service Bus does not care about your message schema, in Event Grid you have to create a custom event based on their schema to wrap your event, so the publisher and subscriber has to understand Event Grid for that, not that is a big deal, but now you have both sides coupled to Event Grid.
If you want to send the event straight to your micro-service, you have to implement the subscription validation in your service, otherwise the service won't be able to receive the events
Event Grid only retry the delivery of your messages for 24 hours, if your service is down or not process the message correctly for longer than 24h, it will make the event dead. Currently, there is no way to query dead messages. Storage Queues and Service Bus are configurable how long you keep the message and it can be kept for many days.
Your service web-hook must acknowledge the receipt(http 200 or 202) of an event within 60 seconds, otherwise it will consider failed. If your operation is longer that that, you should send it to a queue and handle the locking from your service.
Probably there are more limitations, but these are the ones I remember right now that might change anytime soon, I think Event Grid is a great technology still on early days, and there is much to improve, I would recommencement only as a hub for Azure management events, I don't think it is ready for use as an application integrator.
Regarding your comment for queue manager, for Service Bus your have the Service Bus Explorer, and for Azure Storage you have the Azure Storage Explorer, where you can check the messages in the queue, is not the same as Service Bus, but helps.
It very much depends on how are you consuming the queue messages, you can take a look at this comparison: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted
If you don't need ordering and if you don't have a strong limit on message volume, size or TTL, you can stick to storage queues.