Knowledgebase | My Retail Pro

Retail Pro Prism Replication Troubleshooting - What Not To Do

This is a table of replication troubleshooting provided from the 2022 Retail Pro Prism 2 Workshop.

WHAT NOT TO DO	DESCRIPTION	IMPACT	PREFERRED
Kill the Process (PMQ, RMQ/erl.exe, etc.)	Killing the task from Task Manager	Killing RabbitMQ can cause data corruption in RabbitMQ queues Orphaned initialization Data/message loss	Identify root cause or isolate issue first. Restart services using service manager As a last resort, kill the task/process but ensure that it isn't in the middle of some process to avoid/mitigate the issues associated with this.
Restart PrismMQ as defacto solution/resolution	Restarting PrismMQ without a clear understanding of the issue or state of the system	Lost messages Stuck/orphaned initialization	Identify the root cause or isolate the issue first. Many times, the solution is not related to the application and the restart can be avoided.
Leave closed/inactive stores active in Retail Pro Prism	Leaving stores in Retail Pro Prism that are closed or offline for extended periods of time	Excessively large locked queues can create strain on the system and prevent online system from getting D2D data. Producer cache tables can grow very quickly get extraordinarily large. Performance can degrade as the table grows.	Make sure to remove profiles for stores which are offline for extended periods to avoid accumulating large sets of messages on the producer cache tables. Remove closed stores from the enterprise.
Initialize data just because one item is incorrect or missing	Initializing inventory when a small or single set of data is out of sync	Adds unnecessary load on system.	Verify data isn't in the queue already. Use alternatives such as the compare tool, manually edit the item/customer. Track if the item/items are sent and then determine if there is an issue with replication or the data.
Send data that is not required	Sending data unfiltered to the store that they don't use or need Examples: Sales receipts/vouchers/etc. for all stores Customers (potentially) Outslips PO & TO UDFs	Adds overhead to the system for no reason	Filter where possible by store Avoid sending documents or customers, etc., if not need.
Send D2D messages too frequently	Setting the D2D interval in the PMQ config file too low	Sending data such as inventory/customers to frequently with high data volume can overwhelm the system with duplicate messages	Generally speaking, set this between 300 and 900 seconds, and in some cases more if bulk loads/updates are an issue.
Replicate messages from POA to RIL	Unless data is being created in the POA, you should not be replicating messages from the POA to RIL	Increased overhead due to the cost of consuming and then producing the same message you just received	Send the message from the store to both RIL and POA. One message is created and sent to both queues and you only have to create the message once.

Published on Jul 19, 2022 in Data Replication, Errors