Synchronization consists of all communication between a device and a server.

Axional Mobile must be able to work offline. For this reason, all critical data is kept on the local device (SQLite Database).

All data stored locally on the device is controlled by a general synchronization rule, which lists and orders the tables to be synchronized.

1 Data

                                
					Loading...
				
                                

digraph {
            graph [fontsize=10, fontname="Verdana", shape="tab"];
            node  [shape=record fontsize=10 fontname="Verdana" style=filled fillcolor="#99ccff"];
            edge  [color=dashed];
            overlap=scale; # (try to) stretch everything if edges overlap
            splines=ortho;
            graph [ordering="out"]
            compound=true
            rankdir=LR 
            ranksep=1.0


    
            subgraph cluster_mobile_properies {
                label=""
                fillcolor="#0277BD"
                wic_user          [label="Users 
(wic_user)" shape=boxs style=filled fillcolor="#1a237e" fontcolor="#FFFFFF"]
                wic_user_mobile_properies       [style=filled fillcolor="#651fff" fontcolor="#FFFFFF"]
                
            }

            subgraph cluster_wic_sync_rules {
                label=""
                fillcolor=""

	            subgraph cluster_assign3 {
	                label=""
	                fillcolor=""
	                wic_sync_tables   [label="Tables
(wic_sync_tables)"  shape=boxs tyle=filled fillcolor="#81c784" fontcolor="#FFFFFF"]
                 
                 }
            
	            subgraph cluster_assign { 
	                label=""
	                node [style=filled]                
	                wic_sync_rules 
	                color="invis"
	
	                    
	
	            }
            }

			
			wic_user_sync_client_status [label="Client status
(wic_user_sync_client_status)" shape=boxs style=filled fillcolor="#ef6c00" fontcolor="#FFFFFF"]
            wic_user_sync_client_iologs [label="Client logs 
(wic_user_sync_client_iologs)" shape=boxs style=filled fillcolor="#e65100" fontcolor="#FFFFFF"]
			
            wic_user    -> wic_user_mobile_properies       [lhead=cluster_mobile_properies]
            wic_user_mobile_properies  -> wic_sync_rules    [lhead=cluster_wic_sync_rules ltail=cluster_tasks]
            wic_sync_rules    [label="Syncro rules 
(wic_sync_rules)" shape=boxs style=filled fillcolor="#1b5e20" fontcolor="#FFFFFF"]
            wic_user_mobile_properies   [label="User mobile properies 
(wic_user_mobile_properies)" shape=boxs]
            
            
            }

2 Synchronization Rules

Menu path:

Devices / Mobile devices / Synchronization / Rules

Definition of synchronization rules used by wic_user_mobile_properties to set a specific user's sync rule.

Contains all the synchronization tables between the server and the device, as well as the settings and parameters of each table.

wic_sync_rules
Label	Description
Rule	Rule
Name	Name

Actions
Button	Title	Notes
BUT_COPIAR	Copy	Copy the current Rule to new one

Menu path:

Devices / Mobile devices / Synchronization / Tables

Ordered list of tables, with device parameters used to synchronize data between the server and the device.

wic_sync_tables
Label	Description
Synchronization rule code	Synchronization rule code
Order	Order in which different tables are synchronized. When loading tables, users must keep in mind the integrity of the relationships between them. Let's take the apps_pos_ticketh, apps_pos_ticketl, and apps_pos_ticketc tables as an example. We must first synchronize the ticketh data, then the lines (ticketl) and, finally, the possible receipts (ticketc).
Table	Name of the table in the database where the query will be made.
Group	Informative column used to group and classify certain tables.
Mode	Mode: [D]ownload, [U]pload, [N]eutral Default: D Values: D: Download. U: Upload. N: Neutral. M: Up & Down.
Primary key	Required in Download, Neutral and Merge Mode tables. The primary key determines the unique index of the table. It is also essential for managing registrations, modifications and downloads in Download Mode.
Query limit	If this value is reported, the device will limit list views to show only the number of records indicated. Example: the device synchronizes all customers' data, but only 10 rows are displayed in order to protect customer data.
Date of modification	Used in Download and Merge Mode tables. Determines if the server-side record has been modified. Using the date of the latest synchronization of the table, device records are updated. The CURRENT value will force the download of all data for each synchronization. If this column is not reported, it means that data will only be downloaded when there are no existing records in the terminal database. Required for tables like apps_series where the number of documents must be restarted, in case of terminal crash and restart.
Date of synchronization	Used in Download and Merge Mode tables. Updates the field indicated in the table. This field must be in datetime format. It is used to register, on the server side, records which have been synchronized to the device. A check is performed to verify that these records are now on the device.
Date of deletion	Used in Merge Mode tables. Updates the field indicated in the table. This field must be in datetime format. It is used to register, on the server side, records which have been synchronized from the device to the server and subsequently deleted from the device.
Sort	Column or columns to sort upon synchronization.
Crontab code	With this column, we can set an automatic synchronization time. The program will recursively check tables which contain a foreign key to this table, forming a synchronization group. Example: If we add a synchronization cron to the table apps_sfa_task_assign, the program will also synchronize tasks, responses, etc.
Download condition	The 'where' clause of the SQL statement. Used in Download and Merge Mode to determine which records to synchronize to the device.
Upload condition	The 'where' clause of the SQL statement. In Upload Mode, it determines which records in the table must be uploaded to the server side.
Delete condition	The 'where' clause of the delete SQL statement. In Download and Merge Mode, it determines which server-side records meet the delete condition, and using the primary key, device records are removed. In Upload mode, device database records which meet the condition are deleted.
Full resync date	Datetime field where the total resynchronization of a table can be scheduled. If the last synchronization date for a table is before the date entered in this field, the device will delete the table and re-synchronize the information.

Actions
Button	Title	Notes
BUT_RENUMERAR	Renumber	Renum the order, used to add new rows between tables...

2.1 Modes

This section describes actions and events in the synchronization processes of various modes.

Some universal aspects are shared between all modes:

- If the table does not exist on the device, the schema of the central system database must be used to create the table in the device.

- If the table exists on the device and the schema of the central system table has changed, a copy of the device's data is made. A new table following the new schema is created on the device. Previously-saved data is transferred to the new table, so no information is lost.

2.1.1 Download

Synchronization Process in Download Mode:

(1) Structure verification between the central system and the device.

(2) If a delete condition exists, device records are deleted.

(3) Device data updated or added.

If the delete condition is reported, an SQL statement is made, asking the central system database to obtain primary keys using the delete condition. If the primary key is in the device's database, the record is deleted.

The system will synchronize data if there are no existing records in the device database, and if the following conditions are met: the table exists in the device, the table schema in the central system database has not changed, and the Date Column is not reported.

If the table exists in the device, the table schema in the central system database has not changed, and the Date Column is reported, then the table's primary key records will be obtained. An SQL statement will be used to obtain primary keys from after the last date of table synchronization, using the download condition.

Using primary keys, the device's database will be added or updated.

2.1.2 Upload

Synchronization Process in Upload Mode:

(1) Structure verification between the central system and the device.

(2) Device records updated and added to the central system.

(3) Removal of device records which have been uploaded to the central server.

If the table exists in the device and the table schema in the central system database has not changed, then the upload condition is used. Device records which meet the condition are specified, and those records are updated or added to the central system, using primary keys.

2.1.3 Merge

Synchronization Process in Merge Mode:

(1) Device records updated and added to the central system.

(2) If a delete condition exists, then device records are deleted.

(3) Device data updated or inserted.

If the table exists in the device and the table schema in the central system database has not changed, then the upload condition is used. The device records which meet the condition are established, and these records are updated or added to the central system using primary keys. If a delete condition exists, an SQL statement is made, asking the central system database to obtain primary keys using the delete condition. If the primary key is found in the device's database, then the record is deleted and data is updated/inserted.

2.1.4 Neutral

Synchronization Process in Neutral Mode:

For internal tables within the device. Data is not synchronized, but structure is verified.

3 Client Status (Sync)

Menu path:

Devices / Mobile devices / Synchronization / Client status

Each time the device performs synchronizations with the server, synchronization records are kept for each table.

In this way, we can get additional information about a device and the synchronizations performed.