This polling event accepts SQL script and is fired to detect push requests. You must configure this event.

Fetching push requests when using a light weight poller (recommended)

When this event contains up to three columns in a result set, the Notifier acknowledges that there is no persistent connection between the server and the device, and that a device must poll the Notifier before push notifications can be sent. The Notifier caches the result set before sending push notifications. The MobiLink server identifies the device by the poll key, which is sent by the device every time the device polls the Notifier.

The result set of this event must contain the following columns in the specified order:

Fetching push requests when using a gateway

When this event contains more than three columns in a result set, the Notifier acknowledges that a persistent connection exists between the server and the device, and then sends push notifications using a gateway when push requests are detected.

The result set of this event must contain the following columns in the specified order:

See also

• Push request requirements
• Notifier events
• MobiLink server settings for server-initiated synchronization

Example

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

It is recommended that you include a WHERE clause in your script to filter out requests that have already been sent. For example, you can add a push request column to track the moment you inserted a request, and then use a WHERE clause in this event to filter out requests that were inserted prior to the last time the user synchronized.