To enable partial sync:

1. Set the Store class deleteAllRecordsOnSync property to false.
2. Set the uniqueIdentifier in the Model class to the field or fields that uniquely identify the record in the database.

Implementing Individual Record Sync

The mobile framework supports syncing limited record sets by configuring the properties of the Common.store.sync.SyncStore class. The deleteAllRecordsOnSync property determines if the sync process deletes all of the records in the client table. Use this property to implement individual record sync:

/** * @cfg {Boolean} deleteAllRecordsOnSync When true all records for the table are deleted * in the client database during the sync. Set to false to enable the Partial Sync mode. */ deleteAllRecordsOnSync: true,

When you set deleteAllRecordsOnSync to false, the client database deletes old records that corresponde to those downloaded from Web Central, then inserts the modified records. Existing, unchanged records in the client database are not affected.

The following steps are required to configure individual sync:

1. Set the Common.store.sync.SyncStore#deleteAllRecordsOnSync property to false.
2. Set the store sync restriction to the record or records that you wish to sync.
3. Execute the Common.store.sync.SyncStore#syncStore method.

The following example illustrates how to sync a single record for the WorkRequest table:

var workRequestStore = Ext.create('Maintenance.store.WorkRequests'); workRequestStore.setDeleteAllRecordsOnSync(false); workRequestStore.setRestriction({ tableName: 'wr_sync', fieldName: 'wr_id', operation: 'EQUALS', value: '1150000338' }); workRequestStore.syncStore();

Other Considerations

The example above syncs records between the mobile client database and the sync table. In most cases, the mobile app executes a workflow rule that applies the records to the Web Central table. You may need to modify the workflow rule to apply only to the synced record. Application of this logic depends on the mobile app's requirements.

Tracking record changes

Records that are inserted, updated, and deleted in the Web Central application are recorded using a Data Change Event. The database tables that have the transactions recorded are configured in the AbCommonResources-MobileSyncDataChangesOnlyTables application parameter. The Mobile framework uses the recorded transactions to determine which records are updated and deleted from the client during a sync.

To create a custom store that syncs only modified records

1. Create a Store class that extends the Common.store.sync.ValidatingTableStore class
2. Create a Model class that extends the Common.data.Model class. Set the Model class uniqueIdentifier property.
3. Add the server side table name to the AbCommonResources-MobileSyncDataChangesOnlyTables application parameter.

To implement a custom timestamp sync store

1. Create a Store class that extends Common.store.sync.SyncStore
2. Set the Store class timestampDownload property to true
3. Implement an application workflow rule that applies the required logic to manage the last_modified field values.

Document Sync Performance

Improving performance for the document transfer process during a mobile sync can have a large impact on overall sync performance. This feature implements the following features to improve sync performance:

• Download only documents that have been modified on the Web Central server.
• Transfer files in binary mode instead of converting to character data in base64 format.
• Document references need not be copied from the transaction table to the sync table.

The first point specifies that each sync downloads only modified documents to the client. To determine whether a document is modified, the transfer routine checks the document's version field in the table afm_docvers . If the version value in afm_docvers is greater than the document version stored on the client, the document downloads to the client. If the version value in afm_docvers equals the document's version value on the client, the document does not download.

Document Sync Configuration

Syncing document data requires the following:

• Define the document field in the Common.data.Model class.
• Set the documentConfig property in the sync Store class.

Defining the doc1 field in a Model:

{ name: 'doc1', type: 'string', isDocumentField: true, isSyncField: true },

In the Model field definition above, the isDocumentField property indicates to the mobile framework that this field will reference a Document.

Configuring a Store for Document Sync:

documentConfig: { documentTable: 'wr', documentTableKeys: ['wr_id'] }

Specifications in the code above:

• documentConfig configuration is taken from the Maintenance.store.WorkRequests store.
• documentTable property indicates the table documents are referenced to.
• documentTableKeys property contains primary key field or fields of the referenced document table.

Mobile framework uses documentTable and documentTableKeys properties to retrieve document data from Archibus Document Management tables.

Note: In the example above, the Maintenance.store.WorkRequests store syncs to the wr_sync table, but the documents are retrieved using a reference to the wr table. This implementation eliminates the need to copy the document data from the wr table to the wr_sync table before downloading the document data.

Sync Process for the Maintenance App

These steps summarize the Maintenance app's sync process:

1. User creates a new work request record in the mobile app:
   • Record is new.
   • A wr_id value has not been assigned to the record.
2. User syncs the Maintenance app:
   • New record is synced to wr_sync table.
   • Record saved in wr_sync table does not have a wr_id. Primary key for wr_sync record is wr_sync.auto_number value.
3. App executes the Maintenance app WFR:
   • WFR logic copies the record from wr_sync table to wr table.
   • Sync process creates record's wr_id value when it inserts record in wr table.
   • WFR logic writes record's new wr_id value to wr_sync table.
4. Sync process downloads contents of wr_sync table to the device.

Iif the sync process completes without errors, no duplicate records are created. If an error occurs, such as a network interruption during step 2, the sync process does not complete. When sync process resumes at the point of interruption, it may upload a duplicate record to wr_sync table, a duplicate that remains in the table when wr_sync records are processed.

Using GUID Fields

Adding a Globally Unique Identifier (GUID) field to the sync table can eliminate duplicate records. The GUID field provides a means for the mobile framework to determine if the record exists in the server database.

The following configurations are required to use a GUID field in the sync:

• Add the GUID field to the Common.data.Model class.
• Set the Store class guid property to true.
• Add the guid field to the Store inventoryKeyFields property.

Use the field type of guid in the Model configuration:

{ name : 'guid' , type : 'guid' }

The model field type property automatically populates the guid field with a GUID value when the record is created.

The model field type property will cause the guid field to be automatically populated with a GUID value when the record is created.

Sync process with a GUID field:

The following steps are performed when a table containing a GUID field is synced:

1. If the sync Store guid property is true, the primary key values and GUID values of the existing sync records are downloaded to the client.
2. The client updates the GUID values of the existing records.
3. New or updated client records are uploaded to the server.
4. The server side sync code performs an insert or update of the records using the GUID value to check if the record already exists on the server.
5. The client executes the application workflow rule. The application WFR logic inserts or upates the records in the Web Central transaction table.
6. The application WFR deletes all of the records in the sync table for the current user.
7. The application WFR inserts the records to be downloaded to the client into the sync table. New GUID values are written to the sync table records in this step.
8. The new records are downloaded to the client.

See also

Apps and Their Sync Tables