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.
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.
- Excluded User - 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.
- 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.
- 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.
Read about how to