Question
375008155608
US
Last activity: 19 Jul 2021 0:08 EDT
Populating DeclareIndex Properties On Implementation Classes
When doing an import of a product rule that includes new declare index based properties, there is an option to populate the index values. This seems to work fine when the index is defined in the exact class of the work object that has the properties to be indexed (ex: my index is in myco-fw-work and the actual work class is myco-fw-work). If however, your declare index is defined in myco-fw-work, and the implementation class is myImpl-work (direct inherits to the myco-fw-work class), then the importer does not create indexes for those classes...it tries to add them for the fw class, which because it isn't the real runtime class, it will never actually add the indexes.
Does anyone know if there is a simple out of box work around for this? We've built a custom queue processor that runs the RecreateIndexesForInstance activity but this does not seem nearly as performant as the ootb indexer that runs on the fw class during import.
@pega, it would be slick if the product rule import wizard evaluated the indexes and gave you a checkbox option list of classes for which to run the job against.
375008155608
US
I did find that there are rest api available that allow you to trigger jobs that will populate the indexes. At this point, I've manually called the underlying activities that the api calls, and while it worked, it also exhibited some behavior that worries me a little, and I need to do some troubleshooting. The problem that I encountered was that due to security issues, every optimization encountered a failure, and the error message was persisted to the work object, causing all work objects to be unworkable (I wrote a job to page-clear-message on all cases and resave/commit). At this point, I'm not sure if this behavior was due to me running the activity directly, and want to test to see if I see the same behavior when calling via the api. If I trigger the optimization from the rule import, the errors still occur, and the status ends up being "completed with errors" however the errors are not persisted (this would be the preferred behavior of the api as well). I will reply back once I've done some more troubleshooting.