I am using RabbitMQ as message broker. I want the messages from the queue to the consumer are sent by the Http POST method.
What I want is that when a message (body of the post formatted in JSON) is ready in the queue, it is sent to the consumer through HTPP post instead of AMQP.
Are there any plugins or something else?
I searched, but I only found HTTP API to publish a message, to manage the queues and to send GET req to the queues (but I do not want to do this).
Thanks
Related
We plan to have a REST API exposed by Apigee Edge. The client-facing endpoints will be managed by Apigee. Another REST service will be hosted behind the Apigee. When the Apigee endpoint is invoked, we plan to store the request in Kafka so that it can be processed asynchronously. After the server has processed it, we intend to Push a message to the client application that made the request.
Is this a common practice?
Does Apigee have a feature to remember the client such as its websocket so that the notification can be pushed?
First and foremost, Apigee is a Gateway for synchroneous APIs. There is no default way to do "come back" to a request that has been processed earlier. So: No, this is not common practice.
A more common practice would be to add an asynchroneous callout to "another REST service behind Apigee", meaning that Apigee returns a response immediately without waiting for the target to complete. That backend service would then implement the callback on its own, possibly via some other Apigee proxy.
In your specific case, the pattern you're implementing is basically a message queue, utilizing Kafka as the message broker. In such patterns, it's best practice to have the message receiver send a reply message as soon as it finished its work.
Regarding websockets, Apigee doesn't support it at the moment (see https://community.apigee.com/questions/60513/apigee-as-websocket-proxy.html).
I've set up a SNS webhook -- an endpoint that subscribes to a topic. Whenever my app publishes to the topic (users), the topic successfully forwards the data as a POST request to my webhook endpoint (/users).
However, after sending the request, my endpoint continues to receive the same request over and over again. Does anyone know why SNS after successfully making a request to my endpoint continues to send the same request? Upon receiving the request, does my endpoint need to tell my topic that the data has been received? Would I do this with the SNS SDK?
Ok so this was my mistake. I was using express (node) and in the endpoint that was the SNS webhook, I did not return with a response. Adding this line of code as the final line in the endpoint fixed my issue:
return res.status(200).json({success: true});
I want to send message from Amazon Simple Notification Service(SNS) to the http endpoint. There is no proper solid documentation on how to do that. Though I had read Amazon SNS documentation still I could not get entire picture.
Can anyone give me simple example on how Amazon SNS and http endpoint work together?
There good documentation for what you asking: http://docs.aws.amazon.com/sns/latest/dg/sns-dg.pdf
Look at the page #147, it describes what steps you need to do for sending messages to HTTP(s) endpoint.
Also check this example which describes how to create topic, subscribe endpoint, confirm subscription and start to receive notification messages from SNS (uses Java SDK): https://github.com/mfine/AmazonSNSExample
General picture is:
On the publisher side:
create topic and subscribe some endpoint to receive messages. After subscribing endpoint to topic, the endpoint will receive SubscriptionConfirmation message.
start publish to topic so your endpoints will receive notification messages
On the subscriber side (your endpoint should be able to handle at least confirm subscription request and notification messages):
confirm subscription: make HTTP GET request to the "SubscribeURL" URL which comes inside the body of the confirm subscription request. Before you confirm subscription your endpoint will not receive any messages from SNS
receive notification messages and do what you want
We're running an ASP.net MVC4.5 web app, and we have this api end point that does the following:
Send Email using SendGrid (normal sync code)
Send Notification using Azure Notification Services (normal sync code)
Trigger another endpoint in a 3rd party soap service (we're using azure storage queues here and a workrole, because the 3rd party endpoint is unpredictable and i might need to retry the call)
My question is, would it be an overkill to use azure storage queues for (1) and (2), I'm having second thoughts because, SendGrid for example, when sending an email using their SDK, I suspect that the email sending action happens instantaneously when im calling their email send endpoint, they are probably using some sort of queues as well and polling from it to send the messages.
This goes for the notification hubs for example, the message is added to their queues as well, so would it make sense to implement azure queues for those?
I have an existing SQS with X number of messages. I add new SNS HTTP subscription for it. Will my HTTP service receive all of the existing messages from the queue?
Thanks!
No only the new messages get sent.