- The Business Case
- Synchronization Issues
- MobiLink Synchronization
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Synchronization Issues
As is typical with most software projects, what may first sound simple is actually quite complex. If your application is complex enough to require a relational database on the client, it probably also means that your enterprise database is handling quite a bit of data (such as the databases behind Sears repair, IBM on-site support, or FedEx package shipping). In the United States, chances are good that your mobile workers will connect over CDPD or(to a lesser extent because it is newer) over GPRS. Both are packet networks that offer good nationwide connectivity; however, operators of both technologies typically charge based on the amount of data being transferred. For these reasons, the amount of data being sent over the network has to be minimized. This means that additional logic needs to be coded into the synchronization process so that only records changed since the user last sync'd get sent over the air. In most applications, a significant amount of lookup data rarely if ever changes. Your design process should identify these elements and develop a plan to install this lookup data over a wired (or WiFi) LAN to prevent lengthy downloads and hefty access charges.
Once data has been sync'd out to the client, it is often a requirement to develop some strategy for "cleaning up" stale data off these mobile clients. A typical Pocket PC device, for instance, may have only 32MB total memory. No need to hang onto delivery addresses and repair information from assignments completed months ago! There's also the issue of application-level security. If your application is syncing with another enterprise application, if a user gets locked out of the enterprise app (password expires, user leaves the company, and so on), these changes need to be also sync'd to the mobile app. Because most database applications rely heavily on the concept of primary keys to generate unique IDs for data, a strategy needs to be in place so that if User A on Device A creates a new record (with primary key 123456), User B on Device B can't create a new record with that same primary key. If this happens, when the second one through syncs up, he will receive a primary key violation when attempting to insert back into the enterprise database.
In addition to all those issues (getting nervous yet?), there is the issue of data conflicts. Imagine that Mobile User A updates a customer's home address based on information he gained during a delivery. Before he syncs up, someone back at the home office also modifies that customer's address. When User A syncs, whose update "wins?" Does User A simply overwrite the home office's updates? Hopefully not. What is needed is some sort of mechanism to identify and properly handle these conflicts—usually by updating one or more intermediary tables. A LAN user would then typically manually look at the collision and determine which updates were valid (often both because the two users actually updated separate fields on the same record).