The Synchronization Rules define how the data is synchronized between IFS Cloud and the Aurena Native application.
The entities are categorized into two types:
Synchronization Rules with the Rule Type of "System" are mandatory entities for the Aurena Native application.
Synchronization Rules with the Rule Type of "Application" are optional depending on the Aurena Native applications functionality.
See the Aurena Native Framework Synchronization Guide and/or the Troubleshooting Aurena Native 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.
Security Group and Entity Filters¶
The Security Group set against the Entity in Synchronization Rules must be granted to the Aurena Native 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 an Aurena Native application 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 Method - 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 Schedulewhich 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 NativeBatch Scheduleinterval.
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.
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 an Aurena Native 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.
Delivery Method - 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 Aurena Native 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 Aurena Native 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 Aurena Native 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 Aurena Native 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 Aurena Native users. These business roles could be access to all Companies and/or Sites that will be used by the Aurena Native users running the Aurena Native application.
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 Aurena Native 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 Aurena Native users.
Note 2: There is a possibility to switch from Grouped Push to Batch Delivery Method, see Switch Delivery Method.
Delivery Method - Client Cache¶
Client Cached entities are only accessible in the first instance in the Aurena Native application when the device has connectivity to IFS Cloud. The data will be saved for offline usage in the Aurena Native application.
Delivery Method - Online¶
Online entities are only accessible in the Aurena Native application 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 Aurena Native application.
Delivery Method - Incoming¶
Incoming entities do not synchronize data to the Aurena Native application, instead they are used to send data from the Aurena Native application to IFS Cloud only.
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.
Switch 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.
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 Aurena NativeFramework Synchronization Guide for more details on the Refresh process.