Am using sensu server with Elastic cache and have a huge list of clients that they are tiring to send a message but during the keepalive or any notification am using handlers using SNS topic.
But I have differentiated the client but adding Subscriber so that i can identify what is prod and non-prod but notification am not able to split with diff SNS topics using multiple handlers.
Related
Ejabberd newbie here. I hope this question makes sense.
We had a need to setup our own XMPP server so that customers on web and a Bria client can utilize it. I was able to get the basics up and running using ejabberd.
All users will be in the 'xmpp.exampledomain.com'
We also have a custom SMS gateway we built (which is really a server which can accept json APIs).
So what I am trying to accomplish:
Our platform would create a 'normal' xmpp user so the user can login to ejabberd.
This user can add roster contacts of other 'normal' xmpp users.
If this user wants to send messages via SMS, we would instruct them to add roster contacts (i assume) with the format 12125551234#sms.exampledomain.com. (adding the contact works currently)
If a user sends a message to this "SMS" contact, have ejabberd call our custom SMS gateway via a json API instead of attempting to deliver via normal xmpp.
Is this even possible?
For inbound from the SMS Gateway server, can call the ejabberd API send message function, so inbound is fairly easy.
I appreciate any suggestions
thanks
What you want was called a "transport" in the old days of IRC, ICQ, AIM and MSN. They were programs that you installed next to ejabberd (or other Jabber servers). Example usage:
you download a transport for ICQ
configure it to have access to ICQ,
and then configure ejabberd to connect to that transport, and allow users to contact it at address icq.example.com.
There are very old tutorials for your curiosity:
https://www.ejabberd.im/tutorials-transports/index.html
I don't know if the old "SMS-Jabber transports" will work nowadays. Searching revelaed few results:
https://www.jethrocarr.com/2013/06/03/smstoxmpp/
https://sourceforge.net/projects/jabbersms/
https://www.jabber.cz/wiki/SMS_transport
Alternatively, as you mentioned you already have a SMS program, if you can get your hands on Erlang or Elixir, you can write an ejabberd module that registers at sms.example.com, and forwards XMPP messages as json API...
I need advice after looking a lot about receive push/toast notifications regardless of the status of the application (closed or open).
The application communicates with a NodeJS API.
The idea is that a user logs in once to the application and then can receive notifications (depending on his account): i the user restarts his system for example, at startup he receives notifications without having to open the application (like the Mail application for example).
Most tutorials on MSDN use Azure and I don' use this. I would like to know if you have tips or links (tutorials, ...) for doing this in an UWP (or WinRT) application.
Thanks in advance for your help.
Regards
You can send push notifications from your NodeJS api via Windows Notification Service. This service has nothing to do with azure but when using Azure Notifications Hub it will be easier to get it implemented, but again this is not required;
In essence:
- register your app in dev center
- obtain a client id and client secret to use WNS in the dev center
- When your app launch it obtains a push notification channel uri and sends this to your backend. Your backend need to save all the URI's for the different devices
- When you have a notification select the uri's of the devices you want to send the push notification to
- post a xml message (based on what you want to update, tile, toast, badge or raw) to the URI's. To be able to post you need to authenticatie with the client id and client secret
more detailed read: https://msdn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview#
I'm reverse engineering some code that sends a message to an Amazon SQS queue. I know the name of the queue, and can find it in the my AWS console. However, I don't know what is subscribed to the queue. I'd like to see how the message is being processed. Is there an easy way to find that? I can't see anything in the console, or in the CLI... I was hoping for something comparable to rabbitmqctl, which can show you a list of subscribers.
You don't subscribe to an SQS queue. SQS queues have listeners that poll (usually long-poll) the queue for messages.
Anybody anywhere with valid, authorized credentials possessing the permission to receive messages from the can poll it (or not poll it) at any time.
Queues don't have subscribers -- topics, like in SNS -- have subscribers, where messages are broadcast to all subscribers each time a message is published.
There are several Cloudwatch metrics for SQS queues that you can use to determine whether the queue is being polled, but the interactions between listeners and queues is a different model than some other message queue platforms, where listeners to the queue maintain a persistent connection (and can therefore potentially be enumerated). An SQS listener connects, receives any available messages up to the max allowed or requested, disconnects¹, processes the messag(es), then reconnects to delete the messages (otherwise the messages eventually become visible for another listener to receive... or the same listener... SQS has no concept of "who" is listening, because everything works over HTTP which is, of course, stateless.
¹Of course, with HTTP keep-alive, the listener may not technically disconnect the TCP connection to the SQS API endpoint, but there is no state preserved when this happens and SQS has no sense that the listener is "still connected."
We are running a Node.JS app on Bluemix that uses the mqlight service.
Are the messages really being queued in case there are no receivers? Is it possible for a receiver to fetch messages that were sent before it connected?
Are messages really being queued in case messages are being sent faster than they are handled?
Using the Time-To-Live property of messages, messages can be persisted on the destination topic until a subscriber connects. This will allow you to buffer messages whilst they are no subscribers.
Full details for this property are available here.
I regularly spin up and spin down elastic beanstalk environments which have my team's email set as the notification address. Is there a way I can automatically confirm subscription to all of the SNS topics that are created instead of having to manually click a link in an email every time (and miss a few)?
It seems you are programmatically creating environments. You may consider automatically confirming subscriptions using the SNS ConfirmSubscription API
http://docs.aws.amazon.com/sns/latest/APIReference/API_ConfirmSubscription.html
Also another option is to create your own topic and subscribe your email to it. Then reuse the topic for all your environments using the "Notification Topic ARN" option setting instead of providing an email address when launching a new beanstalk environment. That way you subscribe the topic once and then forget about it.
There is no good way that I know of to do this. The easiest way I can think of would be instead of subscribing an email to the topic, subscribe an SQS queue, and then have a separate process reading from that SQS queue and sending emails to your team email address. It's not pretty, but it will work, and you won't lose any messages.
There is no need to create a new SNS topic for each environment.
For example, when configuring notifications using configuration options, using this option:
Notification Topic ARN – [...] You can also set this option to use an
existing SNS topic for notifications. A topic that you attach to your
environment by using this option is not deleted when you change this
option or terminate the environment.
Then for each new environment the mailing-list is only receiving this type of e-mail for which there is no need to confirm subscription:
This is a publish notification test for environment
'your-new-environment-name', to verify permissions to attach an SNS topic
to the environment.
-- If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe:
https://sns.eu-west-1.amazonaws.com/unsubscribe.html?some_key..