Updated: May 7, 2021 8:49am

Initializing Servers

(Note: This topic is being revised for Prism 2.0; check back later for an update.)

About Initialization
Initialization is the process of loading a new Prism server with data. In the case of the Prism HQ server, the data that is loaded comes from an existing Prism server. Typically initialization is a one-time process, done at the time of install.
The amount of time required to initialize Prism will depend on the size of your 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.
Initialize servers in the proper order, starting with the PrismHQ server at the top of the hierarchy and then POAs, and then store servers.
Initialize Prism server
Navigate to Admin Console > Connection Manager > Prism Dashboard.
Click the Initializations tab.  Select the desired server in the dropdown and click Start Initialization.
You will see a screen that enables you to select the servers to initialize and the profile to use for the initialization. Select the checkbox for the server and select the Profile you created in the dropdown. Click the Start button.
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.

Setting Notes
INIGUARANTEEDMESSAGEDELIVERY (RIL to Prism intialization) By default, set to True.
RESUMEINITONSTARTUP (Applies to Prism Initialization consumer for both Initialization types). Set to True by default. By setting ResumeInitOnStartup to true, if a consumer goes down during an initialization, when the consumer is restarted it will resume initialization automatically.
INIGUARANTEEDMESSAGEDELIVERY (Prism to Prism initialization) By default, set to True.


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.

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.
 existing data 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.
 from server
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.
initialize from