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 replica in one transaction (because of the wake-up intervals). If the replica
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.