Initialization

About Initialization
Initialization loads a new Prism server with data. Initializing Prism 2.0 (or later) must use a "Prism-to-Prism" profile and a connection to another Prism 2.0 (or later) system. Initialization using a "V9-to-Prism" or "RIL-to-Prism" profile from a Retail Pro 9 or RIL system is not possible. (Note: To load a new Prism server with data from an external non-Retail Pro system, contact your Retail Pro Business Partner.)
The amount of time required to initialize Prism will depend on the size of the database, especially the size of inventory and customers. The larger the data set, the more time is required. Please set aside enough time for initialization to complete. For larger retailers, the ExportImportResources.exe tool can be used to separately initialize documents, customers, and inventory (the resources most likely to cause bottlenecks and slowdowns during initialization and replication).
Be sure to initialize servers in the proper order, from the top to the bottom of the enterprise hierarchy.
Options for Migrating Data from Legacy Versions of Retail Pro
To migrate data from an existing RP9 or RIL system to a Prism 2.0 (or later) system, one of the following processes is required:

• (Preferred method) First, cross-grade an existing RP9 install to Prism 1.14.7/RP9 and initialize the Prism 1.14.7 database with the existing data. Next, upgrade the 1.14.7 system to Prism 2.0 (or later). Prism can then be used to initialize the other Prism 2.0 systems.
• Use the "Prism Export/Import Tool" to export data directly from RP9/RIL and import (initialize) the data into a clean Prism 2.0 installation. The server can then be used to initialize their other Prism 2.0 systems. This does not export all data, but rather Inventory, Customers and Documents.
• (RP8 users) Either upgrade RP8 to an RP9 installation and then use one of the processes noted above or use the "RP8 to Prism Import Utility" to move data directly from RP8 to a Prism 2.0 (or later) install, bypassing the need for a Retail Pro 9/RIL system. (Note: In either case, the RP8 data must be cleaned, just as is required for a typical RP8 to RP9 upgrade. Prism 2.0 cannot handle uncleaned data from RP8.

Initialize Prism server
At the root authority machine, launch the Prism Proxy using the desktop shortcut and log in.
Navigate to Admin Console > Connection Manager > Prism Dashboard > Profiles.
Create a profile that will be used to initialize the POA server with data from the root authority (HQ) server. The only Type available in Prism 2.0 and above is Prism-to-Prism.
Enter a Name for the profile.
For initialization, typically all resources are sent. Click the "All" link to select all resources. Uncheck any resources that should not be sent.
Select the individual subsidiaries whose data will be sent. For example, if the new server only needs data for a single subsidiary, select that subsidiary and uncheck the other subsidiaries. This will help reduce the time required for initialization.
After adding the Profile, click the Initializations tab.
In the From Server field, click the text box and select the server that will be the data source for the initialization. In this example, the HQ server is the data source.
Click Start Initialization.
Select the Profile that will be used to initialize the new server.
Select the check box for the server to be initialized.
Click Start.

Pause/Resume Initialization
You can pause/resume the initialization process. You cannot pause the Sender, but each downstream Consumer system can be paused and/or resumed. There are three key properties in the PrismMQService.ini file that are related to this feature. These properties are set to True by default, so no configuration is necessary.

VERY IMPORTANT: In tandem with this property the user must also set the INIGUARANTEEDMESSAGEDELIVERY to true on the sending server for the appropriate initialization type to guarantee that if RabbitMQ goes down that no messages are lost.

Example Scenario for Guaranteed Message Delivery (GMD)
Here's a typical situation when this setting can be used: Lets say you start an initialization and realize the consumer's 20 thread default is too low for the power of the machine. Now, you can pause that consumer, change the thread count and then resume the consumer. Initialization will pick up where it left off with the new thread count. If a consumer stops responding for some reason, when PrismMQ restarts, the initialization can resume either automatically or manually by the user. In contrast, if GMD is set to False, then some messages may be lost if there is a RabbitMQ Failure (not just a PMQ failure). In such a case, even a restart of initialization will likely get stuck and not finish, and the initialization will have to be cancelled and restarted from the last completed resource.

Slower Initialization when using INIGUARANTEEDMESSAGEDELIVERY
When turning on GMD for a system that has both sender and consumer on same system (ie, RIL and Prism installed together on same system) will slow down initialization somewhat for this system and any others that might be included in an initialization batch with this system. If these properties are set to false then Pausing and resuming will still work as long as RMQ on a given consumer does not go down.

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.

Delete Initialization
If you need to delete an initialization, make sure that the initialization message queue has finished processing. If you delete an initialization while it is still processing, some messages will be stuck in the queue.
Click the Delete button.  A confirmation is displayed. Click Yes.
Use the Server List button and other buttons to navigate the batch hierarchy as needed.
Restart PrismMQ after Deleting Replication Records
The key service involved with replication, PrismMQ, caches records aggressively to improve performance. If the record is in the cache, it is assumed that the record exists and PrismMQ doesn't need to confirm its existence in the database. This is usually not a problem; however, it can become a problem if you have deleted replication-related records (e.g. replication status) from tables while troubleshooting. The record you removed as part of your troubleshooting efforts may still be in the cache. Therefore, you should restart PrismMQ as soon as possible after deleting replication-related records. Restarting PrismMQ will clear the cache.
Factors that Affect Initialization Times
CPU Cores and Memory: Initialization can take a long depending on the size of the database and the machine's resources. A system with 2 CPU cores and 4GB of RAM system can install and run Prism; however, initialization goes faster when using a machine with at least 4 CPU cores and 8GB of RAM. The more CPU cores and RAM, the better, the more improvement you will see when using advanced features to improve initialization performance (e.g. Server Mode).
Server Mode: Server mode enables the initialization process to take full advantage of the CPU cores and memory. By default, only half of the CPU cores are used. When using Server Mode, you can use up to N-1 CPU cores, that is, all cores except one. Set the Prism Initialization Receive thread count to four or the number of cores you have allocated if you allocate more than four.
Type of Record: Resources such as "company" are simple and can be communicated quickly, even in large numbers. Other resources, such as "customer," are more complex and take longer.
Number of Stores: The number of stores is one of the primary factors influencing the time required for initialization. During initialization, each item's quantity and other information must be sent to every store.  As the number of stores increases, the time required for initialization also increases.
Number of Defined Preference Settings: The more preference settings in Retail Pro 9 that are used will also increase initialization times.
Using Promotions: If the Promotions Plugin is used, this will lengthen initialization times.
First Initialization or Subsequent: The first time you initialize, multiple records are added to the RP Prism tables using a single INSERT statement. The second time you initialize, RP Prism has a record of the first initialization and therefore each record is added using a separate UPDATE statement, increasing initialization times (the UPDATE statement takes longer because it has to compare the new data to the existing data).
Log Levels: If log levels are set to 3 (verbose), initialization times will increase.
Failed/Stopped Initializations
Initialization can take a long time for larger databases and can sometimes fail to complete successfully. If an initialization fails or is stopped for whatever reason:
Create a new Sender profile that starts from the resource after the last COMPLETED resource. For example, if the initialization was in the middle of the Inventory resource when the failure occurred, the new Sender profile should include Inventory and the rest of the resources to the bottom of the list. Run initialization again using the new Sender profile.
When you create a new Sender profile and restart, it may take a while to process the first resource (the resource that was being initialized when the failure occurred). This is because the program must do a slower UPDATE operation on each of the resource's records that are already in the tables. Once the program finishes the updates and reaches the unprocessed records for the resource, it switches to the much faster INSERT operation. There currently is no way to restart a failed/stopped initialization from the specific point of failure. The entire resource in which the failure occurred must be sent again.

"Existing Data Found" Message
When trying to join the enterprise, you may see a message like the one below informing you that existing data was found.
 
The join-the-enterprise script expects that the server joining the enterprise is a freshly installed database. If you operate the Prism server as a standalone installation before joining the enterprise, then you will see this message when joining the enterprise. If you see the information message, go back into Connection Manager at the server that will join the enterprise. Do a Prism-to-Prism initialization using the predefined Core Resources profile. Navigate to the Prism Dashboard > Initializations tab. In the From Server area, select the current server in the dropdown. Click Start Initialization.
 
In the Profile area, select the Core Resources Profile. In the Initialize To area, click the checkbox for the server's POA. Click Start. When the process is complete, try again to join the enterprise.