Two message classes with the actions:
Replication_Util_API.Receive_Configuration__ and
Replication_Util_API.Receive_Message__ are registered on installation of
connectivity. By default these background jobs will be running in the Default
Queue.
The background job Replication_Util_API.Replicate__ is
registered in the default queue the first time it is executed by background
process Replication_SYS.Process_Replicate__.
It is of outmost importance to set up a queue dedicated for the background
job Replication_Util_API.Receive_Message__. This queue must be
restricted to having one process only to ensure the correct sequence of
processing of replication messages. Failure to do so may result in failure when
the background process is updating an LU, because referenced data also
replicated has not yet updated the database (see explanation below).
It is equally important to ensure that the user running the background process have been given the proper authorization to update the replicated objects. When an LU has specific authorization for Companies or Sites the user running the background process must be given authorization to update all Companies or Sites that may be updated with replicated data. In the master configuration you can see which Companies and Sites that are replicated.
If the background job Replication_Util_API.Receive_Message__ is
running in a batch queue that allows two or more processes there is a risk of
failure when replicated data is received. If two objects are created in a master
database where the second object is depending on the first one, they may be
transferred to the slave in one transaction (because of the wake-up intervals).
If the slave site allows two or more processes the received data will be
processed in correct order but in two processes and there is a possibility that
the first process has not ended its transaction when the second process start.
The second process will then fail because it references data not yet present in
the database.