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?
Related
i want to develop a Game using Azure Cloud but i am not sure which ressources i could use for it. Folowing is my problem:
There is one publisher which is providing some messages. I need to find a way to add subscriber on demand. That means whenever i need more subscriber i need to add them without changing any settings on the portal.
All subscriber needs to get the published message at the same time.
Received message from the publisher needs to be deleted for all subscriber at the same time.
Is there a ressource or a way which fits theese needs?
Thanks.
Azure SignalR Service is WebSocket Gateway service that covers all your requirements.
While you could always host your own server, the service supports scaling out.
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.
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.
I have an online service hosted on Azure, that asynchronously sends data to on-premise clients.
Each client is identified by an unique code.
Actually there is a single topic, with a subscription for each client which has a filter on the unique code, that is sent as a parameter in the message. No message will ever be broadcasted to all the clients.
I feel that using topic this way is wrong.
The alternative that comes to my mind is to use a dedicated queue for each client, that is created on first contact
Could this be a better approach?
Thanks
In my opinion using Topics and Subscriptions is the right way to go. Here's the reason why:
Currently the routing logic (which message needs to go to which subscription) is handled by Azure Service Bus based on the rules you have configured. If you go with queues, the routing logic will need to come to your hosted service. You'll need to ensure that the queue exists before sending each message. I think it will increase the complexity at your service level somehow.
Furthermore, topics and subscriptions would enable you to do build an audit trail kind of functionality (not sure if you're looking for this kind of functionality). You can create a separate subscription that has a rule to deliver all messages (True SQL Rule) to that subscription along with client specific subscription.
Creating a separate Queue for each client is not advisable. This is the problem solved by Topics.
If you have separate Queue for each client, then you need to send messages to multiple Queues from Server. This will become tedious when the number of clients increases.
Having a single Topic and multiple Subscriptions is easy to manage as the message will be sent only to a single Topic from Server.
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