Synchronization Rules¶
The Synchronization Rules define how the data is synchronized between IFS Cloud and the mobile app.
The entities are categorized into two types:
- System
- Application
Synchronization Rules with the Rule Type of "System" are mandatory entities for the mobile app.
Synchronization Rules with the Rule Type of "Application" are optional depending on the mobile app functionality.
See the Mobile App Framework Synchronization Guide and/or the Troubleshooting Mobile Apps for more information.
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.
Security Group and Entity Filters¶
The Security Group set against the Entity in Synchronization Rules must be granted to the mobile app 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 app by adding Entity Filters to the Security Group Grants. See Security and Entity Filters for more information how to set up the permissions against Security Groups and how to add Entity Filters to Security Group Grants.
When this is done and is granted to the end user it will take effect 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 entity filter that is added to an entity is efficient and does not impact the synchronization process.
Delivery Methods¶
Batch¶
Batch entities are synchronized on a schedule. The Synchronization Rules are created with a default schedule, but this can be overridden by using the command 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:
- 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.
- The Last Synchronized Date and predicted Next Synchronized Date can be seen in Synchronized Entities.
- The Aurena Native 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 Aurena Native Batch Schedule interval.
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 a Synchronization Trigger associated with its Logical Unit that will execute on New, Update and Delete. These changes are processed via Push synchronization which uses Synchronization Trigger to generate a Push Queue record for the User/Device/Application/Entity to synchronize the data.
Grouped Push¶
Grouped Push entities are used to synchronize the same set of data to a group of users. The data is collected the first time a user within a group connects with the mobile app. When another user within the same group connects the collected data is synchronized to the user (plus any subsequent changes to the collected data). To maintain the collected data, database triggers are used based on the Grouped Push Change Detection Tables defined in Entity Details. When the database trigger is executed a Grouped Push Transaction Queue record is created which is processed via a Database Process that pushes the New, Update and/or Deleted data to the mobile app users within the group.
How the entity data is collected for the user groups can be defined in a Grouped Push User Filter which is associated with the entity as shown in Entity Details. If no Grouped Push User Filter is defined for the entity then all records the entity selects based on the Default Where in Entity Details will be pushed to all mobile app users.
The Database Process that collects the data to be pushed to a user group group is executed by a special Grouped Push User. A Grouped Push User is created for each mobile app that is deployed into the environment that has at least one entity defined with Grouped Push as the Delivery Method. For these entities the Grouped Push User must have access to all business roles that are used to filter the data to the mobile app users. These business roles could be access to all Companies and/or Sites that will be used by the mobile app users running the mobile app.
In addition to any defined Grouped Push User Filter it is possible to create an Entity Filter that will filter the data to a group of users. However, any Entity Filter that is created must not be personally specific for the mobile app users as the process that collects the data is executed by the Grouped Push User. The Entity Filter also cannot be dynamic across groups of users. If the requirement is to select different data from an entity for different groups of users then multiple Entity Filters must be created to select the data required per group of users. The group of users is then defined by granting the Permission Set that the Entity Filter is associated with to the required group of users.
Note 1: It is possible for the entity to be defined with a Guard Condition as shown in Entity Details. If a Guard Condition is present then this will be used within the database trigger to ensure only relevant data is pushed to the mobile app users.
Note 2: There is a possibility to switch from Grouped Push to Batch Delivery Method, see Switch Delivery Method.
Client Cache¶
Client Cached entities are only accessible in the first instance in the mobile app when the device has connectivity to IFS Cloud. The data will be saved for offline usage in the mobile app.
Online¶
Online entities are only accessible in the mobile app when the device has connectivity to IFS Cloud. The data will be accessed directly online and will not be saved for offline usage in the mobile app.
Incoming¶
Incoming entities do not synchronize data to the mobile app, instead they are used to send data from the mobile app to IFS Cloud only.
Action Commands¶
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 command 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 Security Group.
Delivery Method¶
There is a possibility to switch delivery method between Grouped Push and Batch in this screen and also to switch back later from Batch to Grouped Push. The reason for this is that it gives the customers a possibility to flex the synchronization rules to their specific data requirements.
Use the command Delivery Method to change delivery method.
Edit Schedule¶
Each Entity is defined with a Default Schedule. This can be overwritten by using the command Edit Schedule. This opens a dialog box that will allow the Entity to be synchronized:
- Daily at HH:MM - Execute Daily at given time (Example: Daily at 13:30 - executes daily at 13:30)
- Weekly on [Days] at HH:MM - Executes weekly on given days and time. (Example: Weekly on Mon;Tue at 15:45 - executes on Monday and Tuesday at 15:45)
- Monthly on Day N at HH:MM - Execute each month on given day. (Example: Monthly on Day 1 at 15:45 - Execute monthly on 1st day of the month)
- Interval Every HH:MM - Execute in a frequency (Example: Every 00:30 - executes in every 30 min)
- On Changes - Synchronize only when data has changed
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.
Note 5: Editing the schedule for a Grouped Push entity will change the frequency the Refresh process is executed for the Entity. By default the Refresh process runs with the Initialization process defined by the Application Parameters INIT_SCHEDULE. See Mobile App Framework Synchronization Guide for more details on the Refresh process.