Synchronization from the mobile device to the source database

±ΧΈ² 5 shows how changes that a user submits are applied to the source database during synchronization. The numbers in the figure correspond to the explanation following it:

±ΧΈ² 5. How changes that a user submits for synchronization are applied to the source database

Begin Figure 1. Four boxes, the first box representing a mobile device, the second box representing a synchronization request, the third box representing a mid-tier system, and the fourth box representing a source system. The box representing a Mobile device contains a VNMEDICALRECORD (DB2 Everyplace table). The Mobile device box has an arrow pointing to the synchronization request box. The synchronization request box has an arrow pointing to the input queue in the mid-tier system box. The input queue has an arrow pointing to the administration control database. Above the arrow, it reads "authentication". Below the arrow, it reads "query for subscription information. An arrow then points from the input queue to the VNMEDICALRECORD staging table. An arrow points from the VNMEDICALRECORD staging table to the VNMEDICALRECORD mirror table. An arrow from the VNMEDICALRECORD mirror table points to the DB2 log. An arrow from the DB2 log points to the capture program. An arrow from the capture program points to change data table. An arrow from change data table points to Apply in the source system box. An arrow from apply points to the VNMEDICALRECORD source table. End Figure 1.

  1. A home health care specialist or visiting nurse updates the blood pressure of a patient in a local copy of the VNMEDICALRECORD table on a Palm OS device. The nurse exits the application used to edit the table, then taps the IBM Sync icon to start the synchronization client software on the device. A mobile application can also be written to include the ability to start the synchronization, utilizing the Sync Client API. When the synchronization client application starts, the nurse chooses the name of the application to synchronize, then taps Synchronize to request synchronization.
  2. The request is authenticated and then placed on an input queue on the mid-tier system. The synchronization client software on the device waits for a synchronization reply from the source server (see Synchronization from the source database to the mobile device).
  3. Users can synchronize only the subset of data and files to which they have been subscribed.
  4. The data is placed into a staging table. Staging tables help improve throughput capacity of synchronization requests because changes can be staged while other updates are taking place.
  5. The data is copied from the staging table to the mirror table (VNMEDICALRECORD in this example) and potential update conflicts are resolved. Changes to the mirror table are recorded in the DB2 log.
  6. The DB2 DataPropagator Capture program starts. This program captures changes to the mirror table from the DB2 log and writes them to a change data (CD) table.
  7. The DB2 DataPropagator Apply program starts and applies changes from the CD table to the source table, VNMEDICALRECORD, in the VNURSE database on the source system.

Related concepts

Related tasks