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 a source RIL Oracle database. In the case of a POA or Store server, the data 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 HQ with Data from RIL
After installing the Prism components on the HQ server machine, launch the Prism Proxy and navigate to Admin Console > Installation Defaults. Change the RIL Address to the hostname or IP address of the source RIL Oracle. The Controller Name and RIL Address should not be the same computer name.
Next, navigate to Admin Console > Connection Manager. If you added the RIL Address in Installation Defaults, then you can select the server from the Server Address dropdown. If you didn't, you will have to add the RIL Address. Click the Add \ Edit Local RIL Server Button.
Under "Server Address" enter the computer name of the HQ installation (it should match the RIL Address that you entered under Installation Defaults). Click Save.
Click the Connect button. The connection between the two servers is established. Additional tabs become available on the RIL Dashboard.
Click the Profiles tab. Click the Add button. The Add Profile screen is displayed. Select the specific resources that should be sent from the HQ to the POA during initialization. Save the profile.
Click the Initializations tab on the RIL Dashboard. Select the RIL 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.
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.
|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.
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.
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.