I am using async communication with messaging Queues in one of my personal project.
I am stuck at how can I notify my end user (who is my client basically - who is making request) once the operation has been completed .
I understand in some of the long job, we can notify trough email once its finish .
But what if in the case of normal operations like , let say my user is updating his profile , call goes to my backend service - backend service will push one message to update profile to messaging system and on the spot I will respond back to my client with some response. (actual update has not completed yet as it will be done via messaging queue - async way) .
Now here is the question how can I notify my end user that his profile is updated once the operation is completed via messaging queue .
I want to notify my user in the application itself , not via email or any other way . It should be real time notification just like response or something so by using that my client developer can show appropriate message.
updating is only example here , it can be anything .
Related
I need to implement push notifications for my asp.net core project.For a news service
it needs to work in such a manner that if the user is not online while a message is being sent out, then the message will arrive at the client when they are online thenext time.
All the articles I can find about this, are all slightly vague about this case, and just emphasises the "real-time" communication.
So would it be possible to have push notifications that could that wiht signalr?
it needs to work in such a manner that if the user is not online while a message is being sent out, then the message will arrive at the client when they are online thenext time.
To achieve your above requirement, you can try:
mapping user to the connection id(s) and persist that mapping, which would help find/get new connection id(s) based on user name or email etc readable info after user connect/reconnect to hub, then you can send unread message/data to specific user by specifying connection id(s).
Note: you can also send a message to a specific user by passing the user identifier to the User function in a hub method, please refer to this doc: https://learn.microsoft.com/en-us/aspnet/core/signalr/groups?view=aspnetcore-5.0#users-in-signalr
for unread messages, as #SamiKuhmonen mentioned, you can store/persist those messages in somewhere, and if you want to persist information after restarts or you would host hub on multi-servers/instances, in-memory store is not a good approach. You can try to store messages in database etc permanent, external storage.
define and use a flag to indicates if the message has been seen by user. After client received a message, then invoke a hub method to update that flag or delete that message from the store.
Let say user A subscribe event source push notification at device A at 10am and subscribe event source push at device B at 11am without unsubscribe. If my backend send the push message, both devices will receive the push message? I actually just want to send the message to the latest devices user have subscribed. Is there anyway to do this?
Like Idan suggested you can inspect push subscriptions in the database . Susbscriptions have an associated timestamp entry . With this you can determine the latest one for the user.
You can then use WL.Server.notifyDevice(userSubscription, device, options) or WL.Server.notifyDeviceSubscription(deviceSubscription, notificationOptions) to target a specific device.
If the user subscribed to two different event sources then yes, the user will receive notifications in both event sources...
There is no built-in mechanism that will prevent "duplicate" subscriptions (of the same user), so perhaps you could implement some sort of a cron job on your server to inspect the subscriptions table in the database and check that there are no duplicate subscriptions. If a duplicate subscription is found, delete the older one.
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'm trying to understand what I will need to build on my server for Push notifications to work successfully.
My thoughts were:
The phone sends the notify URL to my server
The server stores the information in a Database
A separate process or PHP script will query the database and open continuous looping process for each device. (Each socket will be querying a 3rd party API)
When there is a change detected in the API for that device a push notification will be sent to the device's notify url.
Is this the right method on what needs to be done. Isn't this going to eat up server resources or is it the expected outcome of Push a push notifications server?
I've produced a simple diagram on all this below:
First of all, let's separate the process in the main stages needed for PUSH.
Device subscription.
Send the PUSH
Process the notification on device.
Subscription
For the subscription, your device (more specifically, your App) must call the PUSH api,for enabling PUSH notifications. This call to the push API will give you a URL that uniquely identify the device where your application is installed and running. You should store this URL on your database, the same way you store a user's email, or a user's phone number. No special black magic here. You only use it when you need to send a communication to a user.
Send the PUSH
For the push stuff, the same approach as for email, or SMS messaging here: "One does not simply make an infinite loop and send a message if any change is detected". What you have to do is, just send the PUSH message when your application needs to. So you have the user to which you want to send a message, instead of opening a SMTP connection to send ane mail, just build the PUSH XML Message and call the URL associated with that user. Some things to consider here are:
Network reliability (you need to retry if you can't connect to the server).
Response error code-handling (you don't need to retry if the server tells you that the phone has uninstalled your application, for example).
Scalability. You don't want to send a PUSH message from your PHP code, because you don't know how long it will take for the task to be completed. You have to make this thing asynchronously. So just queue up all the push messages, you can create a separate process (windows service, nodeJS service, cron job, daemon, etc.) to send the PUSH, handle retries and errors and clean the queue.
Process the notification on Device
So now that you are this far, you need to handle the notification on the phone. It depends on the type of PUSH notification that you are sending:
Tile. You will update the image, text and counter of the application tile, if the user has put your application to the start screen. On client side you need nothing to so, as all these parameters are part of your PUSH request.
Toast. This one requires a title, text (limited to some 35 characters more or less) and a relative URL inside of your APP. Your application will be launched (like when you click on a Toast notification from Twitter, for example) using the URI that you specify in the payload. So a bit of data can be already injected here. You may/or may not make a request to your server for new data. It is up to you.
Raw. This one is pretty much silent. Is not seen by the user if your APP is not running. As you might guess, this kind of PUSH is useful to live update your running APP, instead of continuously polling your server, wasting user battery and bandwidth and wasting your server resources. You can send anything (raw bytes or strings) up to the max size of the payload allowed my Microsoft.
If yo have any more questions, don't hesitate to ask.
Bottom line: separate the PUSH sending, make it async, don't you ever forget that...
Your PHP script that continually pings the database for changes...THAT is what will eat up your system resources. Push notifications go hand in hand with Event Driven Programming. This means that ideally, your code shouldn't continuously ping your DB. Rather, when something happens (ie, an "event"), THEN your code does something...like contact your phone via push notification.
Your steps for push notifications are more or less correct, but are incomplete. Step 4: the server contacts the client via the notify url (which you have). Step 5 is that the client then contacts the server to actually pull down the information it needs. That is: The new information is not provided to the client via the notify url. Once the client has its new information, then the program continues as normal (populates a list, downloads skynet, etc.)
Your third step is very wasteful and not practical if your app is installed on more than a few devices.
Instead, each device should be subscribed to types of server updates it cares about. Your server's DB will have a mapping from each type of update you support to the list of notification channel URLs of devices that care about this update type.
When your server detects an update of type X, it would send a notification to all devices subscribed to that type of update.
I have to schedule a downtime in order to do some stuff on the production server. My customer wants me to send a push notification to all the subscribed users in order to notify them by the downtime.
Is that possible? If I want to do it even by code will it be possible?
I'm on worklight 6.0.0.0
Using the Worklight Console you can notify the users of your application taking advantage of the "Active, Notifying" setting. This will allow you to display a notification message on startup telling the customer of scheduled downtime. Even when the downtime occurs you can use the same mechanism and set the application to "disabled" with a notification message stating the application is currently down. Please look at the following documentation for more information:
Displaying a notification message on application startup:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fadmin%2Ft_displaying_a_notification_message_on_app_startup.html
Defining administrator messages from Worklight Console in multiple languages:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fadmin%2Ft_defining_multi-language_admin_notifications.html
Maybe you can use Wl.Server.sendMessage, you just need to send the applicationId and notificationOptions where you can pass only the message to send and this method will be send to all users, of if you want you can pass a kind of target for specify the users
I hope this help you
For more info check these links:
Tutorial: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-1/foundation/notifications/push-notifications-overview/push-notifications-in-hybrid-applications/tag-based-notifications-in-hybrid-applications/
Documentation: http://www-01.ibm.com/support/knowledgecenter/api/content/nl/es/SSZH4A_6.2.0/com.ibm.worklight.apiref.doc/html/refjavascript-server/html/WL.Server.html#sendMessage