Damit Push-Anforderungen generiert werden können, muss die konsolidierte Datenbank die für die serverinitiierte Synchronisation erforderlichen Push-Anforderungsspalten enthalten. Außerdem müssen Sie in der Lage sein, die Werte mit einer einzigen Datenbankabfrage zu erhalten. Push-Anforderungen werden automatisch generiert, wenn Sie im request_cursor-Ereignis eine Datenbankabfrage bereitstellen, die Push-Anforderungsspalten auswählt. Weitere Hinweise zum Einrichten der Voraussetzungen für Push-Anforderungen finden Sie unter Voraussetzungen für Push-Anforderungen.
Die konsolidierte Datenbank enthält die Tabelle PushRequest, die Push-Anforderungen für ein Lightweight-Polling-Modul umfasst. Ein entferntes Gerät wird auf dem MobiLink-Server als unique_device_ID identifiziert. Der Server verwendet folgendes SQL-Skript zum Anfordern der Synchronisation:
INSERT INTO PushRequest (poll_key, subject, content) VALUES ('unique_device_ID', 'synchronize', 'ASAP'); |
Die Verwendung dieses Skripts zum Einfügen von Werten ist nicht ausreichend, um eine Push-Anforderung zu generieren. Die Werte müssen mithilfe einer Datenbankabfrage im request_cursor-Ereignis ausgewählt werden. Zum Generieren einer Push-Anforderung verwendet der Server das folgende request_cursor-Ereignisskript:
SELECT poll_key, subject, content FROM PushRequest; |
Die Push-Anforderung wird generiert, wenn das unique_device_ID-Gerät Push-Benachrichtigungen vom Server abruft. Der Betreff der Push-Benachrichtigung ist synchronize und der Inhalt ist ASAP.
In der folgenden Tabelle sind die Einschränkungen für Push-Anforderungen für die einzelnen Spalten aufgelistet:
Spalte |
Typ |
Einschränkung |
---|---|---|
Anforderungs-ID |
INTEGER |
Dieser Wert muss ein eindeutiger Primärschlüssel sein. |
Polling-Schlüssel |
VARCHAR |
Nur erforderlich, wenn Lightweight-Polling-Module verwendet werden. Für den Polling-Schlüssel gibt es keine Einschränkungen. |
Gateway |
VARCHAR |
Nur erforderlich, wenn Gateways verwendet werden. Dieser Wert muss auf den Namen eines aktivierten Gateways gesetzt werden. Geben Sie Ihren eigenen benutzerdefinierten Gateway-Namen an oder wählen Sie einen der folgenden vorkonfigurierten Gateway-Namen aus:
Siehe Gateways als Alternative zu Lightweight-Polling-Modulen verwenden. |
Betreff |
VARCHAR |
Vermeiden Sie die Verwendung von nicht-alphanumerischen Zeichen bei der Einstellung dieses Werts. Geschweifte, runde und eckige Klammern, Anführungszeichen und Apostrophe sind für die interne Verwendung reserviert und dürfen in der Betreffspalte nicht verwendet werden. |
Inhalt |
VARCHAR |
Für den Nachrichteninhalt gibt es keine Einschränkungen. |
Adresse |
VARCHAR |
Nur erforderlich, wenn Gateways verwendet werden. Für UDP-Gateways muss dieser Wert eine IP-Adresse oder ein Hostname sein. Suffixe für Portnummern werden in folgenden Formaten unterstützt:
Für SMTP-Gateways muss dieser Wert eine E-Mail-Adresse sein. Für SYNC- und Device Tracking-Gateways muss dieser Wert der Empfängername sein, der mit der MobiLink Listener-Option -t+ angegeben wurde. Siehe dblsn-Option -t. |
Neusendeintervall |
VARCHAR |
Standardmäßig wird dieser Wert in Minuten gemessen. Sie können S, M und H für die Einheiten Sekunden, Minuten bzw. Stunden angeben. Sie können auch Einheiten kombinieren. Beispiel: Wenn dieser Wert NULL oder nicht angegeben ist, wird standardmäßig genau einmal gesendet, ohne Wiederholung. |
Restzeit |
VARCHAR |
Standardmäßig wird dieser Wert in Minuten gemessen. Sie können S, M und H für die Einheiten Sekunden, Minuten bzw. Stunden angeben. Sie können auch Einheiten kombinieren. Beispiel: Wenn dieser Wert NULL oder nicht angegeben ist, wird standardmäßig genau einmal gesendet, ohne Wiederholung. |
Ein Notifier erkennt Push-Anforderungen, indem er das request_cursor-Ereignis regelmäßig auslöst. Standardmäßig wird kein Skript für dieses Ereignis angegeben. Sie müssen ein request_cursor-Ereignisskript bereitstellen, sodass der Notifier Push-Anforderungen erkennen kann. In einer typischen Anwendung ist ein request_cursor-Ereignisskript eine SELECT-Anweisung. Siehe request_cursor-Ereignis.
Im folgenden Beispiel wird mithilfe der ml_add_property-Systemprozedur ein request_cursor-Ereignisskript für einen benutzerdefinierten Notifier namens Simple erstellt. Die SELECT-Anweisung informiert den Notifier darüber, dass Push-Anforderungen in einer Tabelle namens PushRequest zu finden sind.
CALL ml_add_property('SIS', 'Notifier(Simple)', 'request_cursor', 'SELECT poll_key, subject, content FROM PushRequest' ); |
Sie müssen Spalten in derselben Reihenfolge auswählen, in der sie in der Push-Anforderung angegeben sind. Siehe Voraussetzungen für Push-Anforderungen.
Weitere Hinweise zum Einrichten von Notifier-Ereignissen finden Sie unter MobiLink-Server-Einstellungen für serverinitiierte Synchronisation.
Der Notifier sendet Push-Benachrichtigungen erneut, wenn die Informationen zum benachrichtigten Gerät nie aktualisiert werden, nachdem sie gemäß den Geschäftsregeln gesendet und erfüllt wurden. Wenn die Push-Anforderungen erfüllt wurden, müssen Sie verhindern, dass der Notifier alte Push-Anforderungen findet. Wenn die Push-Benachrichtigungen zu Synchronisationszwecken gesendet wurden, können Sie die Push-Anforderungen mithilfe eines Synchronisationsskripts löschen.
Sie können Push-Anforderungen mithilfe des request_delete-Ereignisses anhand ihrer Anforderungs-ID löschen. Die Push-Anforderung muss jedoch eine Anforderungs-ID-Spalte enthalten und Sie müssen die Zustellungsbestätigung aktivieren.
Weitere Hinweise finden Sie unter:
![]() |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |