Day-to-Day (D2D) Replication refers to the sending of data on a regular basis between two Prism servers (or between the Prism HQ server and its RIL Oracle database). Whereas initialization is typically a one-time operation that replicates all available data, Day-to-Day replication is typically more focused, sending only a subset of data types, i.e. data types that are likely to have new or updated records.
D2D replication is carried out by creating a profile that includes the desired resources and then linking that profile to the appropriate connection. When creating profiles for D2D, you can select only those specific resources needed by the receiving location. This reduces the time and computing resources required. Resources that are unlikely to change, like Departments or Vendors, can be excluded from D2D. You can use the Advanced Filters feature to apply fine-grained control over the specific records that are replicated. You can create as many profiles as you need and assign the profiles to connections on an as-needed basis. Remember, the profiles you create must be assigned to an active connection before any data included in the profile will be replicated. In addition, a profile must be linked for each direction in which data will be replicated.
Note: In certain situations (e.g. a small data set), the same profile that is used for initialization can also be used for D2D replication.
Day-to-Day Replication Guidelines
D2D between PrismHQ and non-root POA or Store Server
The PrismHQ will need a Prism-to-Prism profile for D2D replication with subordinate systems (child POAs or store servers). Depending on the retailer's needs, the same D2D profile could be linked to multiple connections, or a custom profile could be created for each connection. The D2D profile for sending data from PrismHQ to subordinate systems may include resources like inventory, adjustments, purchase orders, and any other resources needed by the subordinate systems. The subordinate systems will need to create a Prism-to-Prism profile to send data back to the PrismHQ. This will typically include Documents (transactions), Customers and any other records needed by the PrismHQ server.
At the non-root POA or store server, create a Prism-to-Prism profile for sending data from this server to the POA server (named something like "POA1-to-PrismHQ D2D").
D2D between non-root POA and Store Server
A non-root POA will need a Prism-to-Prism profile to send any new or updated records down to the store servers. A store server will need a Prism-to-Prism profile to send documents, new customers and other info generated at the store server up to the POA.
Modified Date during Day-to-Day Replication and Initialization
This section has information about how the Modified Date (MODIFIED_DATETIME in the RPS database) is considered differently during Day-to-Day replication compared to initialization. The Modified Date stores the date/time of the most recent change to the record.
- During Day-to-Day replication, Prism compares the Modified Date of the record being sent with the Modified Date of the existing record at the target location. If the Modified Date of the record being sent is more recent than the Modified Date of the existing record at the target location, the record at the target location is overwritten. If the Modified Date of the record being sent is older than the Modified Date of the existing record at the target location, the record is discarded.
- Initialization does not consider the Modified Date of records. Initialization is for loading an empty Prism database with data from its Point of Authority (POA). This becomes an important factor if users make changes to an offline server that is subsequently made the target of an initialization. The initialization will overwrite any overlapping records at the target database, regardless of the Modified Date.