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.
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.
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.
Batch entities are synchronized on a schedule. The 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:
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.
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.
Note 1: It is important that these Events and Event Actions are not altered in anyway otherwise the Push synchronization process will not work as expected.
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 application. 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 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 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 application 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 users. These business roles could be access to all Companies and/or Sites that will be used by the mobile users running the mobile application.
In addition to any defined Grouped Push User Filter it is possible to create a Permission Set Filter that will filter the data to a group of users. However, any Permission Set Filter that is created must not be personally specific for the mobile users as the process that collects the data is executed by the Grouped Push User. The Permission Set 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 Permission Set 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 Permission Set 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 users.
Note 2: The Delivery Method - Grouped Push is only available for IFS Aurena Native Apps.
Note 3: There is a possibility to switch from Grouped Push to Batch Delivery Method, see Switch Delivery Method.
Cached entities are only accessible in the first instance in the mobile application when the device has connectivity to IFS Applications. The data will be saved for offline usage in the mobile application.
Note 1: The Delivery Method - Client Cache is only available for IFS Aurena Native Apps.
Online entities are only accessible in the mobile application when the device has connectivity to IFS Applications. The data will be accessed directly online and will not be saved for offline usage in the mobile application.
Note 1: The Delivery Method - Online is only available for IFS Aurena Native Apps.
Incoming entities do not synchronize data to the mobile application, instead they are used to send data from the mobile application to IFS Applications only.
Note 1: The Delivery Method - Incoming is only available for IFS Aurena Native Apps.
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.
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 RMB Use Batch Delivery to change from Grouped Push to Batch Delivery. Use RMB Use Grouped Push Delivery to change from Batch to Grouped Push Delivery.
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:
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 Framework Synchronization Guide for more details on the Refresh process.
It is possible to create a Permission Set Filter for the Entity against the Activity to restrict the records that are synchronized to the mobile users. Once the Permission Set Filter has been created it must be added to a Permission Set that is granted to the Mobile Users for the filter to be used during the synchronization process.