Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Deutsch) » MobiLink - Serverinitiierte Synchronisation » Praktische Einführung in die serverinitiierte Synchronisation » Praktische Einführung: Serverinitiierte Synchronisation unter Verwendung von Gateways

 

Lektion 4: Notifier konfigurieren

In dieser Lektion konfigurieren Sie drei Notifier-Ereignisse, die beeinflussen, wie der Notifier Push-Anforderungen erstellt, die Anforderungen an den Listener sendet und abgelaufene Anforderungen löscht.

♦  So konfigurieren Sie die Eigenschaften und Ereignisse des Notifiers
  1. Stellen Sie mithilfe des MobiLink-Synchronisations-Plug-Ins eine Verbindung zur konsolidierten Datenbank her:

    1. Öffnen Sie Sybase Central.

    2. Klicken Sie im linken Fensterausschnitt auf MobiLink 11.

    3. Klicken Sie auf Modus » Admin.

    4. Klicken Sie auf Datei » Verbinden.

    5. Klicken Sie auf das Register Identifizierung.

    6. Im Feld ODBC-Datenquellenname geben Sie sis_cons ein.

    7. Klicken Sie auf OK.

  2. Klicken Sie im linken Fensterausschnitt auf Benachrichtigung.

  3. Klicken Sie auf Datei » Neu » Notifier.

  4. Geben Sie im Notifier-Feld CarDealerNotifier an und klicken Sie dann auf Fertig stellen.

  5. Geben Sie das begin_poll-Ereignisskript ein.

    Der Notifier erkennt Änderungen in der konsolidierten Datenbank und erstellt mithilfe des begin_poll-Ereignisses Push-Anforderungen. In diesem Fall füllt das begin_poll-Skript die PushRequest-Tabelle, sofern in der Tabelle Dealer Änderungen vorhanden sind und eine entfernte Datenbank nicht mehr auf dem neuesten Stand ist.

    1. Im rechten Fensterausschnitt wählen Sie CarDealerNotifier. Wählen Sie im Menü Datei die Option Eigenschaften.

    2. Klicken Sie auf das Register Ereignisse und wählen Sie begin_poll als Ereignis.

    3. Geben Sie das folgende Skript als begin_poll-Skript ein:

      --
      -- Insert the last consolidated database 
      -- modification date into @last_modified 
      --
      DECLARE @last_modified timestamp;
      SELECT MAX(last_modified) INTO @last_modified FROM Dealer;
      
      --
      -- Delete processed requests if the mluser is up-to-date
      --
      DELETE FROM PushRequest
          FROM PushRequest AS p, ml_user AS u, ml_subscription AS s
          WHERE p.status = 'processed'
              AND u.name = p.mluser
              AND u.user_id = s.user_id
              AND @last_modified <= GREATER(s.last_upload_time, s.last_download_time);
      
      --
      -- Insert new requests when a device is not up-to-date
      --
      INSERT INTO PushRequest(mluser, subject, content) 
      SELECT u.name, 'sync', 'ignored'
          FROM ml_user as u, ml_subscription as s
          WHERE u.name IN (SELECT name FROM ml_listening WHERE listening = 'y')
              AND u.user_id = s.user_id
              AND @last_modified > greater(s.last_upload_time, s.last_download_time)
              AND u.name NOT LIKE '%-dblsn'
              AND NOT EXISTS(SELECT * FROM PushRequest 
                  WHERE PushRequest.mluser = u.name
                      AND PushRequest.subject = 'sync')

    Im ersten größeren Abschnitt des begin_poll-Skripts werden verarbeitete Anforderungen aus der PushRequest-Tabelle entfernt, wenn ein Gerät aktualisiert wurde:

    @last_modified <= GREATER(s.last_upload_time, s.last_download_time)

    @last_modified ist das maximale Änderungsdatum in der Tabelle Dealer der konsolidierten Datenbank. Der Ausdruck 'greater(s.last_upload_time, s.last_download_time)' stellt den letzten Synchronisationszeitpunkt für eine entfernte Datenbank dar.

    Sie können Push-Anforderungen mit dem request_delete-Ereignis auch direkt löschen. Das begin_poll-Ereignis stellt in diesem Fall jedoch sicher, dass abgelaufene oder implizit gelöschte Anforderungen erst entfernt werden, nachdem eine entfernte Datenbank synchronisiert wurde.

    Der nächste Codeabschnitt prüft auf Änderungen in der Spalte last_modified der Tabelle Dealer und gibt eine Push-Anforderungen für alle aktiven Listener aus (aufgelistet in der Tabelle ml_listening), die nicht aktualisiert wurden:

    @last_modified > GREATER(s.last_upload_time, s.last_download_time)

    Beim Füllen der Tabelle PushRequest setzt das begin_poll-Skript den Betreff auf 'sync'.

  6. Geben Sie das request_cursor-Skript ein.

    Das request_cursor-Skript ruft Push-Anforderungen ab. Jede Push-Anforderung legt fest, welche Informationen in der Nachricht gesendet werden und welche entfernte Datenbank die Informationen empfängt.

    1. Wählen Sie das Register request_cursor für das Ereignis.

    2. Geben Sie den folgenden Code für das request_cursor-Skript in dem dafür vorgesehenen Bereich ein:

      SELECT
          p.req_id,
          'Default-DeviceTracker',
          p.subject,
          p.content,
          p.mluser,
          p.resend_interval,
          p.time_to_live
          FROM PushRequest AS p

    Die Tabelle PushRequest stellt dem request_cursor-Skript Zeilen bereit.

    Die Reihenfolge und die Werte in der request_cursor-Ergebnismenge sind wichtig. Der zweite Parameter legt z.B. das Standard-Gateway Default-DeviceTracker fest. Ein Device Tracking-Gateway protokolliert, wie Benutzer erreicht werden, und wählt automatisch UDP oder SMTP für die Verbindung mit entfernten Geräten aus.

  7. Geben Sie das request_delete-Skript ein.

    Das Notifier-Ereignis request_delete legt Bereinigungsvorgänge fest. Mit diesem Skript kann der Notifier automatisch implizit gelöschte und abgelaufene Anforderungen entfernen.

    1. Wählen Sie das Register request_delete für das Ereignis.

    2. Geben Sie den folgenden Code für das request_delete-Skript in dem dafür vorgesehenen Bereich ein:

      UPDATE PushRequest SET status='processed' WHERE req_id = ?

    Anstatt die Zeile zu löschen, aktualisiert dieses request_delete-Skript den Zustand einer Zeile in der PushRequest-Tabelle auf 'processed'.

  8. Klicken Sie auf OK, um die Notifier-Eigenschaften zu speichern.

Siehe auch