This tutorial guides you through the basic steps for using the new MobiLink plug-in. This new plug-in allow an administrator to setup and configure virtually every aspect of a synchronization system from start to finish.
For more information about MobiLink plug-in for Sybase Central, refer to the online documentation: Getting Started with MobiLink | MobiLink Plug-in for Sybase Central.
SQL Anywhere 10.0
You can run this sample under Windows only.
To create a synchronization model
Shut down any SQL Anywhere databases that are running on your computer and start Sybase Central. From the Start menu, choose Programs | SQL Anywhere 10 | Sybase Central.
In the tasks list on the left pane, click Create a synchronization model to start the synchronization wizard.
On the Welcome screen , you are asked to create a name for your synchronization model, as well as specify a location where the model is to be stored.
This is an important change from the previous method of designing a MobiLink environment. In MobiLink 10, you configure synchronization offline within an XML file which has an .mlsm extension. Once the configuration is complete, you deploy this model to your consolidated database. In MobiLink 9.0.2, the configuration was completed directly against your consolidated database.
Enter the same SA10Demo, as well as a location for the model to be stored. For the folder name, choose C:\Temp\MLplugin.
Click Next. If you are asked to create a new directory, click Yes.
The Primary Key Requirements page appears. This page outlines many of the key requirements of any MobiLink environment. Select all the options, and then click Next.
The Consolidated Database Schema page asks you to choose a consolidated database. This consolidated database will be used to generate a list of tables to synchronize with MobiLink. No changes are made to this database. It is simply used as a reference at this point. Click Choose a consolidated database.
For this tutorial, use the SQL Anywhere 10 Demo database, although the data source could be any one of the supported databases such as Oracle, SQL Anywhere, IBM DB2, or Sybase Adaptive Server Enterprise.
In the ODBC Data Source Name field, type SQL Anywhere 10 Demo and then click OK.
At this point, the SQL Anywhere 10 demo database should be started and the schema is read into the MobiLink plug-in.
If a window appears that asks you to install the MobiLink system tables, click No.
When you return to the Consolidated Database Schema page, click Next.
The MobiLink plug-in has the ability to create a new UltraLite or SQL Anywhere database based on an existing consolidated database schema. It also has the ability to map column and tables between an existing remote and consolidated database. The latter method can be useful when you are starting out with an existing mobile application that needs to be mapped to an enterprise database.
On the Remote Database Schema page, if you choose Yes, then MobiLink maps the columns and tables between these two databases. Later in the design view, you will verify and alter these mappings.
For this tutorial, choose No and let MobiLink generate a new remote database. Click Next.
The New Remote Database Schema page allows you to choose the tables that will be generated in the remote database. By default, synchronization will be set up for the tables that are selected, however in the design view you can choose to alter the settings for each of the tables.
Select all the tables and click Next.
The Download Type page allows you to define the type of download that is used by MobiLink. You only need to choose the download type and not the upload type because MobiLink has the ability to process data changes from the remote database transaction log, whereas on the consolidated database it does not have access to the transaction log so another method of gathering changes is required.
Choose Timestamp-based download.
The timestamp method is the most useful general technique for efficient synchronization. This technique involves tracking the last time that each user synchronized, and downloading only the rows that have changed since that last synchronization.
You will notice at this point that the Finish button is enabled. If you were to choose this now, the MobiLink plug-in would use the most common settings for your synchronization model.
For timestamp-based downloads, MobiLink maintains a timestamp value indicating when each MobiLink user last downloaded data. This value is called the last download timestamp.
At the consolidated database, a column will need to be added that holds the most recent time the row was modified. The column is typically a timestamp column and will usually be named last_modified.
The MobiLink plug-in will automatically ad this column to the existing tables or to a shadow table, which can be joined to the primary table. SQL Anywhere automatically has the ability to update and manage the columns. For all other supported consolidated database systems, the MobiLink plug-in will generate triggers to manage this column.
Select Use timestamp columns in synchronized tables, and then click Next.
In MobiLink, you write download_delete_cursor scripts to delete rows from your remote database. You must write one of these scripts for each table in the remote database from which you want to delete rows during synchronization.
You cannot just delete rows from the consolidated database and have them disappear from the remote databases. You need to keep track of the primary keys for deleted rows, so that you can select those primary keys with your download_delete_cursor script.
The Download Deletes page allows you to choose whether or not to download delete statements. It also allows you to define a method for tracking deletions on the consolidated database.
Based on the options chose, the MobiLink plug-in automatically adds all required tables, columns, and triggers for managing deletes.
Select Use shadow tables to record row deletions.
Each MobiLink remote database can contain a different subset of the data in the consolidate database. This means that synchronization scripts can be written so that data is partitioned among remote databases.
This partitioning can be disjoint, or it can contain overlaps. For example, if each employee has their own set of customers, with no shared customers, then the partitioning is disjoint. If there are shared customers who appear in more than one remote database, then the partitioning contains overlaps.
For this tutorial, you will not partition data.
Select Yes, download the same data to each remote, and then click Next.
Conflicts arise during the upload of rows to the consolidated database. If two users modify the same row on different mobile databases, a conflict is detected when the second row arrives at the MobiLink synchronization server. Using synchronization scripts you can detect and resolve conflicts.
The Upload Conflict Detection page allows you to choose whether you want MobiLink to detect conflicts. For this tutorial, do not detect conflicts.
Select No conflict detection, and then click Next.
The Publication, Script Version and Description page allows you to give a unique name to your publication and script version. It will also allow you to type a description for your synchronization model.
A publication identifies synchronized data in UltraLite or SQL Anywhere remote databases.
Scripts are organized into groups called script versions. By specifying a particular version, MobiLink clients can select which set of synchronization scripts will be used to process the upload an prepare the download.
Script versions allow you to organize your scripts into sets, which are run under different circumstances. This ability provides flexibility and is especially useful in the following circumstances:
Customizing applications Using a different set of scripts to process information from different types of remote users. For example, you could write a different set of scripts for use when managers synchronize their databases than would be used for other people in the organization. Although you could achieve the same functionality with one set of scripts, these scripts would be more complicated.
Upgrading applications When you want to upgrade a database application, new scripts may be needed because the new version of your application may handle data differently. New scripts are almost always necessary when the remote database changes. It is usually impossible to upgrade al users simultaneously. MobiLink clients can request that a new set of scripts be used during synchronization. Since both old and new scripts can coexist on the server, all users can synchronize no matter which version of your application they are using.
Maintaining multiple applications A single MobiLink synchronization server may need to synchronize two entirely different applications. For example, some employees may use a sales application, whereas others require an application designed for inventory control. When two applications require different sets of data, you can create two versions of the synchronization scripts, one version for each application.
Setting properties for the script version You can set properties for your script version that can be referenced from classes in .NET or Java synchronization logic.
Use the default settings and click Next.
The wizard reminds you where the model will be saved (C:\Temp\MLplugin\SA10Demo.mlsm). Click Finish to generate the model.
Using Design View
Now that you have generated a synchronization model, you can take the settings defined in the configuration wizard and tweak them as required. You can also view and edit the synchronization scripts that the plug-in has generated.
We will also notice that the tasks in the left pane have changed now that we have created the synchronization model.
To use Design View
The first page you will see is the Mappings tab. On this tab, you can see the tables that will be created in the remote database and the corresponding consolidated database mapping. You will notice that all tables have the same configuration; however, you want want to modify this on a table-by-table basis. You can do this by clicking on a cell and choosing the appropriate option.
As an example, you can make the employees table download to remote only, rather than bi-directional.
Click the arrow in the Dir. column for the Employee table.
Change it to:
Alternatively, if you choose to enable conflict detection on the Customers table, you can change the option from None to Column Based. Notice that if you change this option, the Conflict Resolution column also changes to reflect how the conflict is set to be resolved.
We will not synchronize the Products table, so let's remove if from the model.
Right-click on Products and select Delete from the popup menu.
From the design view, you have the ability to view and alter the column mappings for each individual table.
Click the Customers table in the Table Mappings view.
You will notice that the bottom right pane changes to the column mappings for this table. From this pane you can choose to de-select columns, which means that they will not be synchronized. You can also choose any of the cells under the consolidated column. This would alter the column mappings, which would be useful if you are mapping an existing remote database to an existing consolidated database.
Save the changes to the synchronization model by clicking the Save button on the toolbar.
The primary phases of synchronization are the upload and download transactions. Within these transactions, MobiLink will execute various events that can be defined using SQL, Java or .NET. The upload transaction applies changes uploaded from a remote database. The download transaction is a two-part process. For each table, deletes are downloaded, and then update/insert rows (upserts) are downloaded. The end_download event ends the download transaction.
The MobiLink plug-in has automatically generated all of the events that are required for synchronization to complete successfully based on the configurations that have been chosen so far. The events generated are done so in SQL, but if required they can be altered to use .NET or Java.
Click the Events tab.
In this pane, you can view and alter all of the event scripts that the MobiLink plug-in has generated.
Click the Group dropdown list and choose Contacts.
You should see download_cursor and download_delete_cursor scripts for the Contacts table that will define the data to be downloaded for this table. You will also see an upload_insert, upload_delete and upload_update scripts that will define the data to be uploaded to the server.
Choose Employees from the Group dropdown list.
You made this table download only. Based on this fact, the MobiLink plug-in has removed all the upload events and has left only the download cursors.
Click the Authentication tab.
This tab allows you to define the custom authentication that the MobiLink server will use for each incoming user. Some of the common authentication types are POP3, IMAP and LDAP.
Click the Notification tab.
Notifiers and Listeners allow a subset of useful Notification services. On this tab, you identify a table for server-initiated synchronization, and your download_cursor script is automatically used to determine what data is used for notification purposes. When data identified in your download cursor changes, a Notification is sent. The Deployment wizard generates a corresponding Listener options file.
Consolidated database deployment
Remote database and synchronization client setup
MobiLink synchronization server setup
Using the Deployment Wizard
Once the model has been configured, the next step is to deploy the model. Deployment consists of three steps:
To use the deployment wizard
Click Deploy the synchronization model in the Task pane.
On the Welcome page, you have the option to deploy one or more of the three steps. Subsequently, this page will allow you to deploy updates to an existing system based on previous configurations.
Use the default settings and click Next.
On the Consolidated Database Deployment Destination page, you can choose to deploy the consolidated database synchronization setup to a file that is run later or directly to the database.
For this tutorial, choose both options. Click Choose a consolidated database and then choose SQL Anywhere 10 Demo in the ODBC Data Source Name field. Click OK to start and connect to the database.
Click Next. If asked to create a new directory, click Yes.
A message appears instructing you to manually add MobiLink system setup to the consolidated database. Click OK.
Open a Command Prompt and run the following command:
Close the Command Prompt and go back to Sybase Central.
The Remote Database Deployment page allows you to choose the type of remote database that is created. The options you have available are SQL Anywhere, UltraLite, or an existing SQL Anywhere/UltraLite database.
Choose New SQL Anywhere database and click Next.
On the New SQL Anywhere Remote Database page, you can choose to create a new remote database or create a setup file that is run later. Select both options and click Next. If asked to create a new directory, click Yes.
On the MobiLink user page, you can choose a MobiLink user to be defined in the MobiLink server. This user will be used in the generation of the remote database for MobiLink authentication.
Enter the user name mluser1 and click Next.
On the Synchronization Stream Parameters page, the Finish button is re-enabled. Although you could continue with the wizard to configure other options, if the Finish button is selected, defaults will be used.
Use the default settings. Click Finish.
At this point the consolidated database and MobiLink synchronization server are configured, and the remote database and synchronization client are set up. Click Close when the operation completes successfully.
This concludes the MobiLink plug-in tutorial.
Remove the folder C:\Temp\MLplugin and all its contents.