This page defines the additional configurations required for Data Synchronizations in both Hub and Satellites. However necessity of these configurations can be changed according to the customer requirements.
User and Permission Sets¶
IFSSYNC is a system FND_SYNC. User account for IFSSYNC is created during the deployment of FNDRPL to database.
Note: IFSSYNC is created with a randomly generated password and it has some sort of elevated privileges. Hence, it is important to change the password of this user, before starting Data Synchronization between IFS installations. After changing the password, It is important to use that changed password in the routing addresses which used for data synchronization.
Grant Access to Companies and Sites for IFSSYNC User¶
- Navigate to Page Solution Manager\Security\Users\User
- Fetch 'IFSSYNC'
- Expand Companies & Sites
- Expand Companies and check relevant companies
- Expand Sites and check relevant sites
- Save and Refresh the Security Cache
FND_SYNC is a predefined permission set which is created upon installation of IFS Cloud with a build home that has the component FNDRPL. This role is granted to IFSSYNC user. Since this is used for internal operations in Data Synchronization, it is recommended that this role is left as it is.
FND_SYNCADMIN is also a predefined permission set which can be used for administration related works in Data Synchronizations. This is also created upon installation of IFS Cloud with a build home that has the component FNDRPL. This role has every grants necessary for a user to be an administrator in Data Synchronizations. FND_RUNTIME is granted to this role.
Read about how to How to manage permission set hierarchies
Parameter Setting for HTTP_SENDER1¶
Bundled data synchronization messages are sent via http sender. If the connection between Hub and Satellites goes down, message is not delivered and the application message moves to 'Waiting' state. After the number of retries if there is still a connection problem, that particular message is failed and queue is stopped. Hence, we need to make sure that http sender is configured with a reasonable number of retires until the connection problems between Hub and Satellite is resolved. Refer to Tuning and Trouble Shooting for more information.
Note: These values can be changed according to the customer requirements.
Notification for failed Synchronization messages¶
When a data synchronization message is failed, there should be a mechanism to convey it to an authorized person. There is a database task called 'Restart Data Synchronization Messages' to restart a failed synchronization message and when it is reached to maximum attempt of restarts, it sends a notification. This notification can be an E-mail, Application Message, Online SQL, etc. Event for sending this notification is generated when FNDRPL is deployed to the database. Hence, it is required to configure an event action for that Event.
Following example shows the way of configuring an E-mail for sending notifications.
- Create a Even action for Event 'SEND_DATA_SYNC_NOTIFICATION'
- Enable Event.
- AUTO IMPORT MODE - This is used for synchronization of configurations. Values of this parameter can be 'ON' or 'OFF' and 'OFF' is the default value.
- EXCLUDE CUSTOM LUS – Exclude any Custom LU from synchronizing among sites you can set those LU names as a value for this parameter. Multiple LUs can be entered here with ‘^’ separator.
EXCLUDED USERS - Users defined in this parameter are excluded from Password Synchronization. Predefined value of this parameter is a combination of system users such as IFSAPP, IFSADMIN, IFSSYNC, etc. Addition to system users, if particular IFS Cloud platform user does not need to send his password to other sites, his user id can be added to this excluded user combination.
IGNORE DUPLICATES - Sometimes when the network conditions are poor between the HUB and Satellites messages send from HUB to Satellite and vice versa can fail because of the timeout of the HTTP sender. Then such failed messages will be resent by the "Restart Failed Messages" database task. This duplicate message will be successfully processed at the receiving site. However when the network conditions improve the original message will also reach the receiving side eventually. Now since the duplicate of this message has already been processed this message can fail at the receiving end (If this is a record insert). This will result in a message failure and the corresponding queue will stop. There is logic in place to stop this from happening. When this functional parameter is ON the messages with same sender message id will be ignored and will not be processed. A given number of previously successfully finished messages are analyzed at the receiving side to determine if the same sender message id occurs in the data received. If found the message will be ignored and will not be processed. If this functional parameter is OFF this behaviour is not there. The allowed values are ON and OFF.
TRANSACTIONAL SYNC – This is a setting that used to decide whether the Data Synchronization is done with a transactional based bundling of data or not. Data Sync functionality is initially developed to synchronize data ensure transactional consistency between sites.
But with the different usages of this functionality such as synchronize (migrate) data among sites specially when offshore sites are going alive this transactional based bundling may not important. To provide that capability, this new functional setting can be used. The default value of this setting is ‘TRUE’ which is the default behavior of Data Synchronization which consider the bundling of data in to the same bundle which belongs to same transaction.
But if there is a need to synchronize data which the transactional bundling is not required you can set this parameter value to ‘FALSE’. From this you can get a better performance. But use this parameter carefully since if you set it to ‘FALSE’ to get better performance then the Data Synchronization functionality will no longer take care of the transactional bundling.