When push notifications are sent to MFP server from backend external server does MFP saves these messages and the status of delivery (Passed/Failed)?
MFP cannot account for the success or failure of the message once it has passed to the vendor - APNS, GCM or MPNS. The messages are not stored, but may be queued until all are dispatched.
Related
I was running through FCM documentation and
- I would like to understand about what would happen when the subscribers come online after a longer offline period.
- Will FCM store all the push notifications received during the offline period
- Will FCM deliver all the messages once the subscribers have come online
If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device. If the device never gets connected again (for instance, if it was factory reset), the message eventually times out and is discarded from FCM storage. The default timeout is four weeks, unless the time_to_live flag is set.
Lifetime of a message
I have a Liberty server farm over which MobileFirst Platform 7.1 is deployed. I have deployed push notification adapters which is having a Tag based notification implementation. I have enabled the tracelogs using the below parameter in the server.xml file.
<logging traceSpecification="com.ibm.ws.webcontainer*=all:com.ibm.wsspi.webcontainer*=all:HTTPChannel=all"
traceFileName="trace.log"
maxFileSize="30"
maxFiles="20"
traceFormat="BASIC" />
How to confirm that the push notification has been sent to the GCM for the all numbers that are subscribed to a Tag using trace.log.
Thanks in advance
Adding "com.ibm.pushworks.*=all" to your trace specification will log messages regarding how Push is communicating with the GCF and APNS.
you can turn on Naming=allfor more info on this refer this or you can use
<logging traceSpecification="*=audit=enabled:com.worklight.integration.notification.*=finest=enabled" />
I configured the Operational analytics for the MobileFirst 7.0
Configured the JDNI as per the IBM document and created client side log profile in Admin Operation Console. But it always shows 0 data. Not load any client logs / server logs.
Log receiver adapter has been built and deployed in the operation console. Client has the method to push the logs to server via WL.Logger.send(). I see the client log console and logcat, the logs has been pushed to server. In server log also, i see the invoke success log for logReceiverAdapter call.
In Operation Analytics console JNDI, the Queue and Size has been set to 1.
This was identified to be a defect in the product and will be resolved as part of APAR #PI42509 WHEN USING SSL ON WEBSPHERE THE ANALYTICS DATA IS NOT RECEIVED BY THE ANALYTICS SERVER BECAUSE OF THE SSL CONFIGURATION USED
There is no local workaround.
Continue to follow up on the issue in the PMR (support ticket) you have opened.
Within the application the user can subscribe to notifications or unsubscribe. This events are handled by a Worklight adapter that register or delete in the database the users subscriptions.
But in case the app is uninstalled without unsubscribing, in the database will remain the user subscription.
How can this be handled?
Is there any way to notify Worklight of the application uninstall?
As explained in the Idan answer, the subscription will be removed by Worklight automatically after a not specific amount of time depending on the notification provider.
http://developer.android.com/google/gcm/adv.html#unreg
https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html Look for "General Provider Requirements" and "The Feedback Service"
For Apple how proceeds Worklight? Does it check each day the feedback service and then removes the corresponding notifications?
I have tested with Android and a trace appears in the WL Server console saying that the subscription has been removed "because the notification was rejected by the server (NotRegistered)".
This was after two hours since I uninstalled the application and I sent 23 notifications with the application uninstalled.
Is it possible to add a custom handler for this "event"?
Reading the documentation, in the WL.Server.createEventSource method, the "onDeviceUnsubscribe" property of the "options" parameters says:
"The name of the JavaScript function that is called when the device subscription is removed by a client request or by the cleanup task"
What is a cleanup task? My first thought was that this callback would be invoked in the use case we are discussing but I have tried it and when the notification is automatically removed this callback is not called.
Currently I'm sending SMS to my customers, when the customer installs the application I will send notifications instead of SMS but in case the customer uninstalls the application I need to know it for starting to send SMS again.
The Worklight Server cannot be notified (by you) that the application has been uninstalled - this is a user action that you do not have any control over.
That said, you do not need to worry about this, because this exact scenario is being handled for you.
This is the flow:
In case a push-enabled application has been uninstalled, and you are sending a notification... this notification arrives to the APNS/GCM/MPNS server, which then send the notification to the device, to be displayed in the app.
Because the app is no longer installed, the device OS will provide feedback to the APNS/GCM/MPNS server that the notification failed to display.
Eventually, what that will happen is that the APNS/GCM/MPNS server will notify the Worklight Server that the token is no longer valid and the subscription will be removed from the database.
Worklight cannot control when will the APNS/GCM/MPNS server notify the above, though. For more information, consult with the respective service documentation.
The additions to your edited question are not totally clear, but here goes:
APNS token invalidation - only Apple can tell you about it. It could take minutes, hours, days, weeks... there are all sort of scenarios, so no specific time frame can be guaranteed.
The cleanup task is likely a task done by Worklight Server to remove stale subscriptions. It runs every 1 hour and connects to APNS feedback service to retrieve a list of inactive devices. On receiving the list of devices, it removes the device subscriptions from the database.
onDeviceUnsubscribe - Once the device is unsubscribed onDeviceUnsubscribe will be triggered. The idea of this callback is to allow the developer to notify the enterprise backend system that the device is no longer able to receive push notifications so that the backend will no longer try to send them. This is where you could tell your backend system to send SMS instead. But, did you actually implement it (the callback)?
Live tiles are able to receive push notifications without the associated metro app needing to be running.
However I believe that the app must have run at least once in order for the app to acquire a notification channel and subscribe to a notification server, passing the channel to the server.
My question is -
What happens if the server cuts off the client? If the user turns off their computer I presume the server would start receiving delivery failure errors. The server might then cut off the client.
But what happens when the user turns their computer back on? Is the tile now disconnected until the user starts the app again and it resubscribes with the server for notifications?
Or is there a way for the tile to resubscribe automatically on start up without the app having to run?
The push notifications are not sent directly to the client; they're sent via the Windows Notification service in the cloud. This means your service will be able to just send them. The WNS service will do the right thing with notifications when the machine comes out of sleep / reconnects to the network.
http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx has a overview of the service side of notifications.
It's important to note that the tile channel expires after 30 days, and will need to be (programmatically) renewed. The guidance is that you should renew when the app runs to make sure it doesn't expire.
The only thing I can't seem to locate in the documentation is how many push notifications are queued on the client - I suspect that for a given tag notification, only one is kept.
Maybe another way to think about this is with the bad notification -- e.g a "new items" count. If you push this number while the device is disconnect from the network (off, driven over etc), then your service will succeed in sending the notification, and when that machine reconnects, it will seamlessly see the badge update.
You should handle that in your code that when your clients from the server went offline then you should remove them and disconnect them, the client side will only receive the cached values in the live tiles.
If they went back on, then you should also handle it in your server side to push the new notification data.
Just a quick tip: If you are using WCF as your service, you might want to check the Announcement Service Class there you can handle your clients online/offline scenarios.