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

SQL Anywhere 11.0.1 » 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 = 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, 'sync', 'ignored'
          FROM ml_user as u, ml_subscription as s
          WHERE 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 NOT LIKE '%-dblsn'
              AND NOT EXISTS(SELECT * FROM PushRequest 
                  WHERE PushRequest.mluser =
                      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:

          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