Information
Unsupported content This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Debugging Push Notification alerts


You can use the following forms to help debug Push Notifications on the BMC Remedy Action Request System (BMC Remedy AR System) server. These workflow forms must be installed before you can use them to debug Push Notifications. See Installing-workflows-for-Mobility-data-store for more information. 

The Mobility Message Queue: Web Server Information form, shown in the following figure, displays the configuration on the server that hosts the BMC Remedy ITSM - Mobility Incident Management application. To enable notifications to be sent, you must set the following values:

  • Set the Mobility Web Server Name to the Internet Protocol (IP) address of the web server that hosts the BMC Remedy ITSM - Mobility server.
  • Set the Mobility Web Server Port to the HTTP port number of the web server that hosts the BMC Remedy ITSM - Mobility server.

Mobility Message Queue: Web Server Information
Push Notification Web Server Info.png

The Mobility Message Queue form, shown in the following figure, displays the messages that the BMC Remedy AR System server has sent and those messages that are pending. The Object ID is the entry ID.

Warning

Note:

The Object ID for an incident is different from its incident number.

When a message is first added to the message queue, the Message Status is set to New. At some point, the message status changes to Sent. If the status of the messages is a status other than Sent, an issue has occurred on the BMC Remedy AR System server. As show in the following example of the form, several messages have been successfully sent but there is also some issue.

Mobility Message Queue
messagequeue.png

Following are example log snippets from the BMC Remedy ITSM - Mobility server. You can inspect these logs for troubleshooting purposes.

  • The following information is logged upon user logon:

    2012-02-02 00:58:24,879 INFO  [742D8FCE-911F-430D-BAF0-A28B04278EB7, Unknown, PushMessageHandler] - user = Allen, deviceToken = b07413cdd457c62acfa91a3e8100dbd323c37a1f95b76f421ddea3057d72fdd7, Thread ID = 341
  • The following information is logged if the device token for the user has changed:

    2012-02-02 00:58:24,879 INFO  [742D8FCE-911F-430D-BAF0-A28B04278EB7, Unknown, PushMessageHandler] - Device token has been changed. Old deviceToken = 0760110be78557c1665560468874cacdb4f6712c40b9499fe5227fa65ede4ba3, Thread ID = 341
  • If you see a log like the following example and there appears to be no error afterwards, you can assume that the message made it to Apple:

    2012-02-02 00:55:08,649 INFO  [PushMessageHandler] - Pushing alert  notification to Apple for Device  Token='0760110be78557c1665560468874cacdb4f6712c40b9499fe5227fa65ede4ba3',  payload='\{"aps":\{"alert":"An Incident Worklog has been added or  changed","sound":"default"\}\}', Thread ID = 74
    Warning

    Note

    Apple and Google state that message delivery is not guaranteed. Be sure to consider this before creating a defect that a message was not delivered.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Remedy ITSM - Mobility: Service Desk 7.6.07