I'm setting up a project in ASP.NET C# to manage the bounces and complaints notification when I send massive emails with Amazon SES.
I've read around that the best way, for large amount of messages, is SQS and not the simpler SNS on HTTP endpoint.
I've found some ready code by Amazon Team:
https://sesblog.amazon.com/post/TxJE1JNZ6T9JXK/Handling-Bounces-and-Complaints
I've understood that SQS service must be called by me, is not pushing like SNS, but I don't understand how I have to call it, which URL and how to build the request.
Sign in to the AWS Management Console and open the Amazon SQS console at https://console.aws.amazon.com/sqs/.
Create a Queue. http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSGettingStartedGuide/CreatingQueue.html
Select the queue to which you want to subscribe an Amazon SNS topic.
Select Subscribe Queue to SNS Topic from the Queue Actions drop-down list.
From the Choose a Topic drop-down list, select an Amazon SNS topic to subscribe the queue to and then click Subscribe.
In the Topic Subscription Result dialog box, click OK.
You can verify the results of the topic's queue subscription by publishing to the topic and viewing the message that the topic sends to the queue. For detailed steps, see Test it out by publishing a message to the topic and reading the message from the queue.
Related
I am developing C# applications, and I'd like to implement using of AWS SNS. I understand how to publish SNS from my C# app, but how can I subscribe/receive SNS in C#? Is it possible at all?
It would appear that you want to do message-passing between applications.
For this use-case, I would recommend using Amazon Simple Queue Service (Amazon SQS) rather than using Amazon Simple Notification Service (Amazon SNS).
Basically:
App1 sends a message to an Amazon SQS queue
App2 regularly polls (looks in) the queue to see if there is a message for it to process. If so, it grabs the message
Amazon SQS makes the message 'invisible' so no other worker will see it
When App2 has finished processing the message, it deletes the message from the queue
If App2 does not delete the message within a defined 'invisibility period', then the message will automatically 'reappear' on the queue so that it can be re-processed
This is a more-rigorous method of message-passing since it can handle situations where errors occur or where the target app is not currently running.
Amazon SNS, in contrast, simple sends the message to the desired destination (such as an HTTP endpoint), which will fail if the target app is not running.
I have several .Net 5.0 microservices with RabbitMQ as message broker. Right now I am switching to AWS SQS. Few services are listening the same message (this is done with Exchange in RabbitMQ). In AWS this could be implemented by subscribing SQS Queue to SNS topic. I created SNS fifo topic and SQS fifo queues, subscribed those queues to topic. When I publish message directly to queue everything works immediately, but when I publish message to SNS topic it takes more than 7 minutes to get message from queue subscribed to topic. Does anybody noticed such huge delay ? Maybe latency?
Btw, all the service are running on aws the same region.
Any ideas ? Will appreciate any advice!
thank you all for your comments and help! In my case lack of experience with sqs was the main problem. I found parameter in queue settings "Delivery delay" and set smaller value and now I receive messages immediately.
We have created Azure service bus queue and have a azure function - servicebus queue trigger subscribed to it. We now want this queue to convert to Topic as we will need multiple subscription to it. is there a way that we can convert queue to Topic without deleting queue and re creating this as a Topic. I understand that Azure function code which is in c# needs to be changed so it points to service bus topic.
Thanks,
Punit Singhi
Use the ForwardTo feature for forwarding a message to the topic entity.
I know I can call up the scheduled message in c#/code and delete a scheduled message like this
Scheduled messages can be removed by calling CancelScheduledMessageAsync(sequenceNumber)
But I can't seem to figure out how to do it with Service Bus Explorer or in the Azure dashboard. Is it possible with either?
It's possible to delete specific messages using QueueExplorer (I'm the author). It is a commercial tool, but if it's a one-of thing you can use free trial.
https://www.cogin.com/mq/
Btw. we are a bit lucky with scheduled messages, since Azure Service Bus API has that CancelScheduledMessageAsync function. It's more problematic for regular messages. All we can do, whether from some script or from QueueExplorer, is to start receiving all messages before the one we want deleted, and then "abandon" receive for all of those in front. It's not only slow, but increments their Delivery count and they could end up in dead letter queue. It would be great if Azure Service Bus would have "delete message" functionality in API.
Both Azure dashboard and Service Bus Explorer do not support this option.
For Service Bus Explorer you can raise a feature request here.
I am new to Azure Service Bus and would like to know if I can multiple subscribers to a queue or topic? In rabbit MQ I can have multiple subscribers to 1 publisher.
What I am trying to do is, I am using CQRS and when certain commands come into the system when the event is handled I want to push them into a message queue.
I want 2 subscribers to be able to get the messages from that queue, one for me to process internally. another one for process and send externally.
I am new to Azure Service Bus and would like to know if I can multiple
subscribers to a queue or topic?
Yes. This is possible with Azure Service Bus Topics. There can be multiple subscribers to a message sent to a topic. From this link:
In contrast to queues, in which each message is processed by a single
consumer, topics and subscriptions provide a one-to-many form of
communication, in a publish/subscribe pattern. Useful for scaling to
very large numbers of recipients, each published message is made
available to each subscription registered with the topic. Messages are
sent to a topic and delivered to one or more associated subscriptions,
depending on filter rules that can be set on a per-subscription basis.
The way it works is that you create a topic and then create multiple subscriptions in that topic. In each subscription, you can define message filtering rules. When a message is sent to a topic, Azure Service Bus matches that message against the filtering rules in each subscription and if a matching rule is found, then the message is sent to that subscription.
I wanted to add something to the discussion: from the following article it seems that each listener would have to create a different subscriber in azure before listening to the same topic. Basically a topic will have multiple subscribers (every subscription with a single listener) and so the service bus will know exactly how many subscribers will need to listen to the message before it can be completed.
https://medium.com/awesome-azure/azure-difference-between-azure-service-bus-queues-and-topics-comparison-azure-servicebus-queue-vs-topic-4cc97770b65