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.
Optimized usage of the bandwidth is a most important aspect for the data
synchronization. If LOB (Documents, Images, Base Profiles) and Normal Data
(created from the transactions like creating a Purchase order, releasing a Customer
order) are
received from the same port, then normal data may have to wait until large sized LOBs
are sent entirely. There for it is important to be able to configure two
separate ports for normal data and LOB data to avoid unnecessary traffic in the
network. If required it should be possible to configure any number of ports as
needed.
Configuring additional listen ports is possible using a Reverse
Proxy Server. Here we will discuss how Apache HTTP server can be configured as a
Reverse Proxy Server to enable additional communication ports.
Download and install Apche HTTPD server.
Go to <Apache_Install_Dir>\conf and open httpd.conf for editing.
Load the mod_proxy moudles. Uncomment the following LoadModule
directives:
IFSSYNC is a system
User
which is created for internal
operations in Data Synchronizations. This user should not be
mapped to an actual end user but should be used only for technical purposes. IFSSYNC is granted
new permission set called '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 Solution Manager\Security\Users\Create User
FND_SYNC is a predefined permission set which is created upon
installation of IFS Applications 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 Applications 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.
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.
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'
There is another database task called 'Restart Data
Synchronization Lob Messages' to restart a failed lob 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 for lob messages.
Create a Even action for Event 'SEND_LOB_DATA_SYNC_NOTIFICATION'
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 Foundation1 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. This functionality
is available for both Data and LOB messages. The allowed values
are ON and OFF.
EXCLUDEDCUSTOMLUS - Data belongs to the defined Custom LUs in this
parameter are excluded from synchronizing. Use '^' character to seperate
list of LUs in this parameter. By using * as the value for this parameter,
you can exclude all the Custom LUs from synchronizing,
CUSTOM_FIELD_LUS_FOR_BROADCASTING - If the relavent LU is consist with
custom fields and the broadcasting is enabled, the LU name need to be added
to this parameter. Otherwise only the Standard fields will be broadcasted. Use '^' character to seperate list of LUs in this
parameter. By using * as the value for this parameter, you can include all
the LUs for broadcasting with their custom fileds.
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 live 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.
