Wenn dieses Ereignis bis zu drei Spalten in einer Ergebnismenge enthält, wird vom Notifier bestätigt, dass keine beständige Verbindung zwischen dem Server und dem Gerät besteht und dass ein Gerät den Notifier abfragen muss, bevor Push-Benachrichtigungen gesendet werden können. Der Notifier speichert die Ergebnismenge vor dem Senden von Push-Benachrichtigungen im Cache. Der MobiLink-Server identifiziert das Gerät mithilfe des Polling-Schlüssels, der bei jedem Abruf des Notifiers vom Gerät gesendet wird.

Die Ergebnismenge dieses Ereignisses muss folgende Spalten in der angegebenen Reihenfolge enthalten:

Wenn dieses Ereignis mehr als drei Spalten in einer Ergebnismenge enthält, bestätigt der Notifier, dass eine beständige Verbindung zwischen dem Server und dem Gerät besteht und sendet dann, wenn Push-Anforderungen erkannt werden, unter Verwendung eines Gateways Push-Benachrichtigungen.

Die Ergebnismenge dieses Ereignisses muss folgende Spalten in der angegebenen Reihenfolge enthalten:

• Voraussetzungen für Push-Anforderungen
• Notifier-Ereignisse
• MobiLink-Server-Einstellungen für serverinitiierte Synchronisation

Im folgenden Beispiel wird mithilfe der ml_add_property-Systemprozedur für einen benutzerdefinierten Notifier namens Simple ein request_cursor-Ereignisskript erstellt. Die Select-Anweisung weist den Notifier an, eine Tabelle namens PushRequest auf Push-Anforderungen zu prüfen.

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

Es wird empfohlen, eine WHERE-Klausel in das Skript einzubeziehen, um bereits gesendete Anforderungen herauszufiltern. Sie können z.B. eine Spalte für Push-Anforderungen hinzufügen, um den Zeitpunkt zu protokollieren, zu dem Sie eine Anforderung eingefügt haben, und dann eine WHERE-Klausel verwenden, um Anforderungen herauszufiltern, die vor der letzten Synchronisation eingefügt wurden.