Notifier properties

MobiLink Synchronization User's Guide
  Server-Initiated Synchronization
    Set up the Notifier
      Configure the Notifier

Notifier properties

The following properties can be set in the Notifier properties file. The enable and request_cursor properties are required. All other Notifier properties are optional.

You can have multiple Notifiers running with one MobiLink server. To set up additional Notifiers, copy the properties for one Notifier and provide a different Notifier name and property values.

enable

Specify enable=yes to use a Notifier. You can define and use multiple Notifiers in one file.

For example, a Notifier called NotifierA is enabled with the following line:

Notifier(NotifierA).enable=yes

isolation

Isolation is an optional property that controls the isolation level of the Notifier's database connection. The default value is 1. You can use the following values:

Value	Isolation level
0	Read uncommitted
1	Read committed (the default)
2	Repeatable read
3	Serializable

For example, the isolation level is set for NotifierA with the following line:

Notifier(NotifierA).isolation=2

connect_string

By default, the Notifier uses ianywhere.ml.script.ServerContext to connect to the consolidated database. This means that it uses the connection string that was specified in the current dbmlsrv9 session's command line.

This is an optional property that can be used to override the default connection behavior. It is a JDBC connection string. You can use it to connect to any database, including the consolidated database. It may be useful to connect to another database when you want notification logic and data to be separate from your synchronization data.

For more information, see ServerContext interface.

For example, a Notifier called Simple is configured to use a DSN with the following line:

Notifier(Simple).connect_string = dsn=SIS_DB\
   ;uid=user;pwd=myPwd

poll_every

This property specifies the polling interval. If no unit is specified, the interval is in seconds. You can specify S, M, and H for units of seconds, minutes. and hours. You can also combine units, as in 1H 30M 10S.

If the Notifier loses the database connection, it will recover automatically after the polling interval.

This property is optional. The default is 30 seconds.

For example, a Notifier called Simple is configured to poll every three hours with the following line:

Notifier(Simple).poll_every = 3H

gui

This controls whether the Notifier dialog is open on the computer where the Notifier is running. This user interface allows users to temporarily change the polling interval, or poll immediately. It can also be used to shut down the Notifier without shutting down the MobiLink synchronization server. (Once stopped, the Notifier can only be restarted by shutting down and restarting the MobiLink synchronization server.)

This property is optional. The default is ON.

For example, the Notifier dialog is disabled for a Notifier called Simple with the following line:

Notifier(Simple).gui=off

begin_connection

This is a SQL statement that runs as a separate transaction after the Notifier connects to the database and before the first poll. For example, this property can be used to create temporary tables or variables.

If the Notifier loses its connection to the consolidated database, it will re-execute this transaction immediately after reconnecting.

You should not use this property to change isolation levels. To control isolation levels, use the isolation property.

For example, begin_connection is defined for a Notifier called Car Dealer with the following line. The backslash is a line continuation character.

Notifier(Car Dealer).begin_connection = \
   set temporary option blocking = 'off'

begin_poll

This is a SQL statement that is executed before each poll. Typical uses are to detect data change in the database and create push requests.

The statement is executed in a standalone transaction.

This property is optional. The default is NULL.

For example, the following SQL statement inserts rows into a table called PushRequest. Each row in this table represents a message to send to an address. The WHERE clause determines what push requests are inserted into the PushRequest table. The backslash is used as a line continuation character.

Notifier(NotifierA).begin_poll = \
INSERT INTO PushRequest \
( gateway, mluser, subject, content ) \
      SELECT 'MyGateway', DISTINCT mluser, \
       'sync', stream_param \
      FROM MLUserExtra, mluser_union, Dealer \
      WHERE
   MLUserExtra.mluser = mluser_union.name \
     AND( push_sync_status = 'waiting for request' \
           OR datediff( hour, last_status_change, \
        now() ) > 12 ) \
       AND ( mluser_union.publication_name is NULL \
           OR mluser_union.publication_name = \
        'FullSync' ) \
       AND \
         Dealer.last_modified > mluser_union.last_sync_time

shutdown_query

This is a SQL statement that is executed right after begin_poll. The result should contain only the value yes (or 1) or no (or 0). To shut down the Notifier, specify yes or 1. This statement is executed as a standalone transaction.

If you are storing the connection state in a table, then you can use the end_connection property to reset the state before the Notifier disconnects.

For example, shutdown_query is defined for a Notifier called Simple with the following line. The backslash is a line continuation character.

Notifier(Simple).shutdown_query = \
  SELECT COUNT(*) FROM NotifierShutdown \
  WHERE name='Simple'

request_cursor

This property determines what information is sent in the message, who receives the information, when, and where. You must set this property.

This property specifies a SQL statement for the Notifier to collect push requests from the consolidated database. The result set of this statement must contain five columns, and can optionally contain two other columns. These columns can have any name, but must be in the following order in the result set:

request id
gateway
subject
content
address
resend interval
time to live

For more information about these columns, see Push requests.

You might want to include a WHERE clause in your request_cursor to filter out requests that have been satisfied. For example, you can add a column to your push request table to track the time you inserted a request, and then use a WHERE clause to filter out requests that were inserted prior to the last time the user synchronized.

The statement is executed in a standalone transaction.

Following is an example of a request_cursor. The backslash is a line continuation character.

Notifier(Simple).request_cursor = \
SELECT \
    PushRequest.req_id, MLUserExtra.gateway, \
  PushRequest.subject, \
  PushRequest.content, MLUserExtra.address, \
  PushRequest.resend_minute, PushRequest.minute_to_live \
FROM PushRequest, mluser_union, MLUserExtra \
WHERE PushRequest.mluser = mluser_union.name \
 AND PushRequest.mluser = MLUserExtra.mluser \
   AND PushRequest.req_time > mluser_union.last_sync_time

request_delete

This is a SQL statement that specifies cleanup operations. The statement takes the request id as its only parameter. The placeholder for a parameter is a question mark (?).

Using the delete statement, the Notifier can automatically remove two forms of old request:

implicitly dropped requests requests that appeared previously, but disappeared from the current set of requests obtained from the query.
expired requests requests that have expired based on their resend attributes and the current time. Requests without resend attributes are considered expired even if they appear in the next request.

You can write the WHERE clause of request_delete in such a way that previous requests that have been handled by the Listener will not enter the next set of requests. For example, the Car Dealer sample uses request time and last synchronization time. This not only stops further messages for the same request, but also allows the Notifier to delete the implicitly dropped request.

This property is optional if you have provided another process to do the cleanup.

The statement is executed per request ID in a standalone transaction.

For example, the Notifier called Simple is configured to substitute a req_id previously obtained from request_cursor for the question mark (?):

Notifier(Simple).request_delete = \
   DELETE FROM PushRequest WHERE req_id = ?

end_poll

This is a SQL statement that is executed after each poll. Typical uses are to perform customized cleanup or track polling.

The statement is executed in a standalone transaction.

This property is optional. The default is NULL.

For example,

Notifier(Simple).end_poll = call reportAliveRequests( )

end_connection

This is a SQL statement that runs as a separate transaction just before a Notifier database connection is closed. For example, this property can be used to delete temporary storage such as SQL variables and temporary tables.

The statement is executed in a standalone transaction.

For example, end_connection is defined for the Simple Notifier with the following line. The backslash is a line continuation character.

Notifier(Simple).end_connection =   \
   DELETE FROM NotifierShutdown WHERE name = 'Simple'