Troubleshooting
Problem
Attempts to run SSI_MASS_SYNC agent for elastic server indexing affects order or shipment purge in IBM Sterling Order Management.
Symptom
- Order or Shipment purge does not happen.
- Order and SHIPMENT are not fitting into purge criteria after running the SSI_MASS_SYNC agent
Cause
SSI_MASS_SYNC agents updates the modifyts value in ORDER and SHIPMENT tables
Diagnosing The Problem
The SSI_MASS_SYNC agent is used to sync the orders and shipments in the database to the Elastic search index.
Basically this is used when :-
- You upgrade from the Sterling order management version where ES(Elastic search) index was not present to a version where ES index is available in the product and needed according to your database structure (like sharded or nor).
- You have database sharded but so far not used Elastic search but wanted to use that to optimize your search.
- When existing index have been corrupted for some reason and you need to built it from scratch.
- You changed index configuration (for eg: added more fields to index) and you need to re-index so that all the existing documents in the index get those new fields also)
Scenario 1 and 3 corresponds to FULL mode.
Scenario 2 is UNINDEXED mode
Scenario 4 is VERSIONSYNC mode
All the indexable entities will have an INDEX_VERSION column and this will be updated with the current version of the index configuration when that entity is propagated to index. This is on the basis of Sterling Search Index and cannot be modified. Whenever any attributes of an entity is modified modifyts also changes. This is the basis of Sterling OM Platform.
Resolving The Problem
SSI_MASS_SYNC should not be run as a routine process and purge agents should be run before SSI_MASS_SYNC agent to avoid the data discrepancy for purge criteria
SSI_MASS_SYNC agent meant to be run only once (when any one of the above mentioned scenario arise). This should never be part any cron job or any periodic runs. It updates the order and hence modifyts changes. You don't need to run it again after all the existing orders in the database are indexed. There is already a mechanism to purge the orders from index when it is purged from database also. Since purge is a periodic process and as and when purge runs it removes the corresponding document from index also.
NOTE: The Orders in the history table are not present in the index.
So when you are running SSI_MASS_SYNC for the first time (when any one of the above mentioned scenario arise) you need to decide whether to run purge before that. This is based on whether you have a long retention days before purge and have enough purgable orders. Running SSI_MASS_SYNC will update the orders with the current date and orders will be picked up only in the next purge cycle.
And note that the search index is added to get a faster retrieval of orders. An order which is closed (basically confirmed or shipped or invoiced) continue to eligible for search. Users come for returns and at times search for their older orders and hence these orders have to be present in the index for faster retrieval. So the expectation SSI Mass Sync agent should not update closed status orders is incorrect.
Here since the SSI_MASS_SYNC has run before purge, it got updated and will not picked up for purge now. It will get purged in the next cycle.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21977400