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

SQL Anywhere 11.0.1 (Français) » MobiLink - Server-Initiated Synchronization » Server-initiated synchronization tutorials » Tutorial: Server-initiated synchronization using gateways

 

Lesson 4: Configure the Notifier

In this lesson you configure three Notifier events to influence how the Notifier creates push requests, transmits the requests to remote Listeners, and deletes expired requests.

♦  To configure the Notifier properties and events
  1. Connect to the consolidated database using the MobiLink Synchronization plug-in:

    1. Open Sybase Central.

    2. In the left pane, click MobiLink 11.

    3. Click Mode » Admin.

    4. Click File » Connect.

    5. Click the Identification tab.

    6. In the ODBC Data Source name field, type sis_cons.

    7. Click OK.

  2. In the left-pane, click the Notification folder.

  3. Click File » New » Notifier.

  4. Specify CarDealerNotifier in the Notifier field, and then click Finish.

  5. Enter the begin_poll event script.

    The Notifier detects changes in the consolidated database and creates push requests using the begin_poll event. In this case, the begin_poll script populates the PushRequest table if changes occur in the Dealer table and when a remote database is not up-to-date.

    1. In the right pane, select the CarDealerNotifier. From the File menu, choose Properties.

    2. Click the Events tab and choose begin_poll for the event.

    3. Enter the following for the begin_poll script:

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

    In the first major section of the begin_poll script, processed requests from the PushRequest table are eliminated if a device is up to date:

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

    @last_modified is the maximum modification date in the consolidated database Dealer table. The expression greater( s.last_upload_time, s.last_download_time) represents the last synchronization time for a remote database.

    You can also delete push requests directly using the request_delete event. However, the begin_poll event, in this case, ensures that expired or implicitly dropped requests are not eliminated before a remote database synchronizes.

    The next section of code checks for changes in the last_modified column of the Dealer table and issues push requests for all active Listeners (listed in the ml_listening table) that are not up to date:

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

    When populating the PushRequest table, the begin_poll script sets the subject to 'sync'.

  6. Enter the request_cursor script.

    The request_cursor script fetches push requests. Each push request determines what information is sent in the message, and which remote databases receive the information.

    1. Choose request_cursor for the event.

    2. Enter the following code for the request_cursor script in the space provided:

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

    The PushRequest table supplies rows to the request_cursor script.

    The order and values in the request_cursor result set is significant. The second parameter, for example, defines the default gateway Default-DeviceTracker. A device tracking gateway keeps track of how to reach users and automatically selects UDP or SMTP to connect to remote devices.

  7. Enter the request_delete script.

    The request_delete Notifier event specifies cleanup operations. Using this script, the Notifier can automatically remove implicitly dropped and expired requests.

    1. Choose request_delete for the event.

    2. Enter the following for the request_delete script in the space provided:

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

    Instead of deleting the row, this request_delete script updates the status of a row in the PushRequest table to 'processed'.

  8. Click OK to save the Notifier properties.

See also