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 about push request requirements, see Push request requirements.

Assume that a remote device is identified on your MobiLink server as unique_device_ID, and your consolidated database contains a table named PushRequest, which was created using the following SQL statement:

CREATE TABLE PushRequest (
    req_id INTEGER DEFAULT AUTOINCREMENT PRIMARY KEY,
    poll_key VARCHAR(128),
    subject VARCHAR(128),
    content VARCHAR(128)
)

In this example, you can execute the following SQL statement on the consolidated database to prepare a push request:

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

Using the above script to insert values into the PushRequest table does not generate a push request by itself. You must set up a database query in the request_cursor event on the MobiLink server so that the inserted values can be selected and a push request can be generated.

In this example, you can define the following SQL statement for the request_cursor event script on your MobiLink server:

SELECT poll_key, subject, content FROM PushRequest;

A push request is generated when the unique_device_ID device polls the server for push notifications and the request_cursor event detects data in the PushRequest table. When sent to the device, the push notification subject is defined as synchronize, and the content is defined as ASAP.

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

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'
);

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

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.

See:

• Push request requirements
• request_delete event
• MobiLink server settings for server-initiated synchronization

• Tutorial: Configuring server-initiated synchronization using light weight polling
• Tutorial: Configuring server-initiated synchronization using gateways