Synchronization Rules

The Synchronization Rules define how the data is synchronized between IFS Applications and the mobile application. 

The entities are categorized into two types:

Synchronization Rules with the Rule Type of "System" are mandatory entities for the mobile application.

Synchronization Rules with the Rule Type of "Application" are optional depending on the mobile applications functionality.

See the Mobile Framework Synchronization Guide and/or the Troubleshooting Touch Apps for more information.

Contents

Transaction Grouping

Applications that are defined with Server error handling with have the Transaction Grouping set on all editable entities.  Transaction Grouping is used in Failed Transaction handling to only block transactions from a single business object when a failure occurs rather than blocking all transactions from the User/Device/Application.

Activity - Permission Sets And Filtering

The Activity set against the Entity in Synchronization Rules must be granted to the mobile user via a Permission Set for the Entity to be synchronized.  Additional row level filtering can be added to any Entity that is synchronized with a mobile application by adding a Permission Set Filters to the Activity via the Create Permission Set Filter context menu option.  If the Permission Set Filters is created from the Permission Set Activity screen then the list of possible Entities the Permission Set Filters can be created against is automatically provided. Once the Permission Set Filter is created it must be added to a Permission Set Activity which is granted to the end user for the Permission Set Filter to take affect on the next Sync whether that is Push, Batch or manually triggered via Sync Now.

Note 1: It is important to remember that large data sets should be filtered to ensure the synchronization processes (Push, Batch on the server & Initialize on the client)

Note 2: It is important to ensure that any permission set filter that is added to an entity is efficient and does not impact the synchronization process.

Delivery Method - Batch

Batch entities are synchronized on a schedule. The schedule is controlled by the configuration of the corresponding Synchronization Rule. Synchronization Rules are created with a default schedule, but this can be overridden by using the context menu Edit Schedule.

Batch synchronization is processed by a Database Task. When this process runs it will compare the current system date/time with the last synchronized date/time for the User/Device/Application for all Entities.  If this time interval is greater than the frequency defined for the Application/Entities then a Synchronization Task will be created for the User/Device/Application/Entities to update the identified entities data. By comparing all Entities in the Batch synchronization process the number of Synchronization Tasks created is reduced.

Some important points to note about the Batch synchronization process are:

  1. The process is optimized to only synchronize new, changed and removed records based on the data that has previously been synchronized with the User/Device/Application.
  2. The Last Synchronized Date and predicted Next Synchronized Date can be seen in Synchronized Entities.
  3. The Touch App Batch Schedule which processes the Batch synchronization will be scheduled with an interval.  By default this is 15 minutes.  This means that it is not possible to refresh the entity data of a Synchronization Rule with a frequency less than the Touch App Batch Schedule interval.

Delivery Method - Push And Batch

Push and Batch entities are synchronized in a similar way to Batch entities with an addition of pushing data changes to the users. 

Each Entity will have an Event associated with its Logical Unit that will trigger on New, Update and Delete.  These changes are processed via Push synchronization which uses Events to generate a Push Queue record for the User/Device/Application/Entity to synchronize the data.

Each Event will have an Event Action associated with it that will execute a SQL statement that will create the Push Queue record.

It is important that these Events and Event Actions are not altered in anyway otherwise the Push synchronization process will not work as expected.

Each Event Action consists of a guard condition that will prevent the unnecessary creation of Push Queue records when no data should be pushed to a mobile application. The Push Queue records are then processed via a Database Process which will check the Ownership Query defined in Entity Details to determine which User to send the data to and will create a Synchronization Task to process the Push Queue records. If for some reason the Ownership Query returns no data then the Entity will be processed later via the Batch synchronization process as defined above.

Sync Now

To be able to advance the batch synchronization process for a specific Entity it is possible to select the record and use the context menu Sync Now. This will not alter the schedule configuration but will sync the selected Synchronization Rule for all users with permission set access to the Activity.

Edit Schedule

Each Entity is defined with a Default Schedule.  This can be overwritten by using the context menu Edit Schedule.  This opens a dialog box that will allow the Entity to be synchronized:

Note 1: It is important to ensure that entities consisting of large data are synchronized on a long schedule otherwise they will impact the system performance and batch synchronization.

Note 2: For entities with the same Synchronization Group changing the interval on one of the entities will change all the interval for all entities in the group.

Note 3: On Change should only be used for slow moving tables otherwise they will impact the system performance and batch synchronization.

Note 4: On Change can only be used on entities that have been designed to support the On Change synchronization process. If it is not possible to set On Change against an entity a reason will be displayed in the Edit Schedule dialog.

Activities in Synchronization Rules