Working with push requests

Generating push requests

Before push requests can be generated, your consolidated database must contain the push request columns required for server-initiated synchronization, and you must be able to obtain the values with a single database query. Push requests are generated automatically when you provide a database query in the request_cursor event that selects push request columns. For more information on push request requirements, see Push request requirements.

Example

The consolidated database contains a table named PushRequest, which contains push requests for a light weight poller. A remote device is identified on the MobiLink server as unique_device_ID. The server uses the following SQL script to request synchronization: 

INSERT INTO PushRequest (poll_key, subject, content) VALUES ('unique_device_ID', 'synchronize', 'ASAP');

Using this script to insert values is not enough to generate a push request. The values must be selected using a database query in the request_cursor event. To generate a push request, the server uses the following request_cursor event script: 

SELECT poll_key, subject, content FROM PushRequest;

The push request is generated when the unique_device_ID device polls the server for push notifications. The push notification subject is synchronize, and the content is ASAP.

Push request limitations

The following table lists the push request limitations for each column:

Column

Type

Limitation

Request ID

INTEGER

This value must be a unique primary key.

Poll key

VARCHAR

Only required when using light weight pollers.

There are no limitations on the poll key.

Gateway

VARCHAR

Only required when using gateways.

This value must be set to the name of an enabled gateway. You specify your own custom gateway name, or choose one of the following pre-configured gateway names:

  • Default-DeviceTracker
  • Default-SMTP
  • Default-SYNC
  • Default-UDP

See Using gateways as an alternative to light weight pollers.

Subject

VARCHAR

Avoid using non-alphanumeric characters when setting this value. Braces, chevrons, double quotations, parenthesis, single quotations, and square brackets are reserved for internal use, and should not be used in the subject column.

Content

VARCHAR

There are no limitations on the message content.

Address

VARCHAR

Only required when using gateways.

For UDP gateways, this value should be an IP address or hostname. Port number suffixes are supported in the following formats:

  • IP-address:port-number
  • hostname:port-number

For SMTP gateways, this value should be an email address.

For SYNC and device tracking gateways, this value should be the recipient name defined with the Listener -t+ option. See -t option.

Resend interval

VARCHAR

By default, this value is measured in minutes. You can specify S, M, and H for units of seconds, minutes, and hours, respectively. You can also combine units; for example, 1H 30M 10S informs the Notifier to resend the messages every one hour, thirty minutes, and ten seconds.

If this value is null or not specified, the default is to send exactly once, with no resend.

Time to live

VARCHAR

By default, this value is measured in minutes. You can specify S, M, and H for units of seconds, minutes, and hours, respectively. You can also combine units; for example, 3H 30M 10S informs the Notifier to stop resending messages three hours, thirty minutes, and ten seconds after the initial send.

If this value is null or not specified, the default is to send exactly once, with no resend.
Detecting push requests and sending push notifications

A Notifier detects a push request by frequently firing the request_cursor event. By default, a script is not specified for this event; you must provide a request_cursor event script so that the Notifier can detect push requests. In a typical application, a request_cursor event script is a SELECT statement. See request_cursor event.

The following example uses the ml_add_property system procedure to create a request_cursor event script for a custom Notifier named Simple. The SELECT statement informs the Notifier to detect push requests from a table named PushRequest. 

CALL ml_add_property('SIS', 'Notifier(Simple)', 'request_cursor',
    'SELECT poll_key, subject, content FROM PushRequest'
);
Note

You must select columns in the same order as they are specified in the push request. See Push request requirements.

For more information about setting up Notifier events, see MobiLink server settings for server-initiated synchronization.

Deleting push requests

The Notifier resends push notifications if the information about the notified device is never updated after being sent and satisfied according to your business rules. Once push requests are satisfied, you need to prevent the Notifier from detecting old push requests. You can delete the push requests using a synchronization script if the push notifications were sent for synchronization purposes.

You can use the request_delete event to delete push requests by their request ID, however, your push request must contain a request ID column, and you must enable delivery confirmation.

Note

Delivery confirmation is not available on Palm devices; However, you can delete push requests by implementing your own delivery-confirmation mechanism. For example, using your own synchronization logic, you can delete push requests when a specific synchronization occurs. For more information about disabling delivery confirmation on Windows devices, see Listener keywords for Windows.

See:

Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1