[Cover] [Previous Section] [Next Section] [Index]
Current chapter: Creating HDML Services that "Push" Information
Section 41 out of 67 total sections , Section 10 out of 11 sections in this chapter

Debugging notifications

Following are some general steps for debugging notifications:

  1. Make sure the expiration time (TTL) for the notification is long enough.

    2. Note that the expiration time is specified in seconds. To specify the longest TTL allowed by the UP.Link server, specify a TTL of 0.

  2. If you are sending secure notifications, make sure the notification URLs match the URL specified by your certificate.

    3. The Common-name of the certificate must match exactly, or be an immediate subdomain of, the domain that hosts the notification alert and pull URLs.

  3. Check the HTTP response code returned by the UP.Link server.

    4. When you post a notification request, the UP.Link server generates a response with an HTTP code, indicating whether the UP.Link server accepted or rejected the notification.

    If you are using the COM library with C++, the notification request function (e.g. PostAlert or PostPrefetch) returns the response code from the UP.Link server. If you are using the COM library with Basic or Perl, you can examine the response by calling NtfnGetLastResult and NtfnGetErrorDetail. To examine the response with the UNIX C++ library, check the value returned by the PostAlert() or PostPrefetch() call and use GetErrorDetail().

    For a description of status codes returned by the UP.Link server, see Checking codes returned by the UP.Link server.

  4. Request notification status information from the UP.Link server.

    5. UP.SDK notification utilities and APIs allow you to request information on the status of individual notifications: you can determine whether a notification has been delivered, expired, or deemed undeliverable. To check the notification status with the COM library, use NtfnGetStatus; with the UNIX C++ library, use GetNtfnStatus().

  5. Use the Web interface to check notification status on the UP.Link server.

    6. If you have login access to the UP.Link server, you can also use a Web interface to check the status of notifications. For instructions, Checking notification status on the UP.Link server.


Checking codes returned by the UP.Link server

When the UP.Link server receives a notification request, it returns one of the HTTP status codes in the table below. How you get this status code depends on the tool or API you are using to send notification requests:

IMPORTANT     If a notification call returns a -1 error value, this indicates a general I/O failure has occurred. The most common cause of this error is that a corporate firewall is blocking the destination notification port.

HTTP Code  Description 
200  

The notification status request was accepted by the UP.Link server.  

204  

The notification addition request succeeded: the notification was added by the UP.Link server. 

The notification deletion request succeeded: the notification was deleted by the UP.Link server.  

400  

The notification failed because one of the following was missing or invalid: 

  • Subscriber ID: the subscriber ID must be valid 
  • URL: the URL must be valid and accessible to the UP.Link server. If you are sending a secure notification, it must match the URL of your certificate (for more information, see Sending secure notifications with invalid URLs) 
  • Notification type: it should be either alert, prefetch, or cacheop. 
  • TTL: should specify an integer number of seconds 
  • Alert type: an alert type is required. Consult the documentation of the notification tool or library you are using to make sure that you have specified the correct format. See the UP.SDK Tools and APIs Reference for complete documentation of the notification tools and libraries. 
  • Alert title: titles are required for alert notifications; make sure the title is shorter than 256 characters 

The most frequent cause for the 400 status code is an invalid subscriber ID.  

Before you retry the notification request, make sure all of the data described above are correct. 

403  

The notification request failed: your application does not have permission to make requests to the specified UP.Link server.  

To determine requirements for issuing notifications on an UP.Link server, consult with the UP.Link server administrator. 

404  

The notification deletion or status request failed. The specified notification is not pending on the UP.Link server. This could be because of any of the following: 

  • The notification was already delivered  
  • The notification was already expired  
  • The notification was already deemed undeliverable  
503  

The notification request failed: the request was valid and authorized. However, the UP.Link server was unable to accept the notification for delivery. Wait and retry the request after a while. 

IMPORTANT     The description of the 204 HTTP status code ("Empty Request") might imply to you that your request to add or delete a notification has failed. However, it actually means the request has succeeded.

UP.SDK APIs allow you to request more detailed error information when the UP.Link returns an error code:

For more information on these methods, see the "COM Notification Library Reference" and "C++ Notification Library Reference" chapters of the UP.SDK Tools and APIs Reference.


Checking notification status on the UP.Link server

If you have login access to the UP.Link server that you are sending notifications to, you can easily determine the disposition of individual notifications on the UP.Link server. For example, you can determine how long it has been since the UP.Link server received a notification and whether the notification has been successfully delivered.

If you register as an Unwired Planet developer, you can request a username and password which will allow you to log in Unwired Planet's Developer Support UP.Link server (updev.uplanet.com). For instructions on getting a username and password, see the Unwired Planet's Developer Support Web pages.

This is useful for debugging notifications. In particular, if your application appears to be sending notifications successfully, but the UP.Phone does not appear to be receiving them, you should check the notification status on the UP.Link server.

To the check the status of pending or recently delivered notifications on an UP.Link server:

  1. Use a Web browser to log in to the provisioning pages of the UP.Link server.

    2. To log in to the provisioning pages of an UP.Link server, you need a username and a password from the UP.Link server administrator.

  2. Find the profile of the subscriber to whom you sent the notification.

    3. The UP.Link server provisioning pages allow you to search for individual subscribers. For instructions on searching for subscribers, see the UP.Simulator chapter of the UP.SDK Tools and APIs Reference.

  3. Click the Notifications link at the bottom of the Subscriber Profile page.

    4. The Subscriber Notifications list appears.

The following table describes the fields in the Subscriber Notifications list.

Field  Description 

Type 

The type of notification. One of the following values: 

prefetch  

alert 

cacheop 

Service ID 

For trusted services, such as UP.Mail, the IP address of the service originating the notification. 

Date of Post 

The date when the notification was posted to the UP.Link server. 

Time of Post 

The time when the notification was posted to the UP.Link server. 

Date of Expiry 

The date when the notification is due to expire. 

Time of Expiry 

The time when the notification is due to expire. 

Status 

The status of the notification. One of the following values: 

delivered: the specified alert URL or pulled digest has been downloaded to the UP.Phone 

pending: the specified alert URL or pulled digest has been not yet been downloaded to the UP.Phone 

undeliverable: the Messenger was unable to deliver the notification 

expired: the Messenger was unable to deliver the notification before its expiration period elapsed 

FIGURE  5-10.     Subscriber notifications page

IMPORTANT     By default, the UP.Link server maintains the status of a notification in its database for 48 hours after the notification expires, is delivered, or is deemed undeliverable. This period is configurable by the UP.Link server operator.


More tips for debugging notifications

The following sections describe some common problems with notifications.


Sending secure notifications with invalid URLs

If you send a secure notification that specifies a URL that is not valid for your certificate--for example, if the notification URL is http://mycompany.com but the Common-Name for your certificate is ntfn.www.mycompany.com, the following can happen:

[Cover] [Previous Section] [Next Section] [Index]
Current chapter: Creating HDML Services that "Push" Information
Section 41 out of 67 total sections , Section 10 out of 11 sections in this chapter

Copyright © 1999, Unwired Planet, Inc. All rights reserved.