Posted: 29 Aug 2019 3:45 EDT Last activity: 30 Aug 2019 10:02 EDT
How to reindex Declare Index table
Scenario: After Go-Live, customer has optimized a page list property (ID, Name, and Price) that references to MyCo-MyApp-Data-Item class in Dev. Now we have a Declare Index (Index-MyCo-MyApp-Data-Item). If we import R-A-P into production environment, new work object will create a record in index table with exposed column (ID, Name, and Price) populated, but for existing work object, system won't do anything.
Question: How can we populate exposed column with value that only exists in Work table's blob field.
Approach: There is an out-of-the-box activity Code-.ReCreateIndexesForClass. This activity takes a class as a parameter and I tried "Index-MyCo-MyApp-Data-Item". It ended successfully but the exposed columns are still null in index table. Am I missing anything, or how am I supposed to run this activity.
You can create an activity which opens the case (work object) on a temp page and then call OOTB activity @baseclass.RecreateIndexesForInstance on the same temp page. The key is to set pzReindex property to true and save the work object. The OOTB activity does this for you.
Thanks for your response. I was able to achieve this by your method but why would you suggest to use @baseclass.RecreateIndexesForInstance activity instead of my original post (Code-.ReCreateIndexesForClass)?
Code-.ReCreateIndexesForClass is designed to take a class name as a parameter and it handles all instances in the work class while @baseclass.RecreateIndexesForInstance is designed to handle a single instance. Code-.ReCreateIndexesForClass actually has a step to do Property-Set pzReindex to true, and this is more convenient to use. However, unfortunately Code-.ReCreateIndexesForClass throws an error when I pass a class name ("MyCo-MyApp-Work-PurchaseRequest") as follows:
I have found out that this is because Code-.ReCreateIndexesForClass activity is not setting "Lock" in the Obj-Open-By-Handle step. I am not sure why engineering team did not do this but anyways, this is the reason that I was failing. So I have tested private checkout on this rule and check "Lock" (and also "ReleaseOnCommit"). Now activity runs without any error and the records were populated into Index table successfully.
Is my approach above okay? Or, is your suggestion, creating your own custom activity using @baseclass.RecreateIndexesForInstance is a better solution? Please let me know.
Your approach is OK. In the past I used RecreateIndexesForInstance because I only had to update indexes for one case at a time. I never paid attention to what RecreateIndexesForClass was doing. I now looked at the activity. It seems to be calling RecreateIndexesForInstance on each instance of the class you pass as the parameter. Since you need to update indexes for all instances of your work class, you are doing the right thing, i.e., using RecreateIndexesForClass. And the thing with the "lock" parameter you found may not be a defect. Since the activity accepts any class as a parameter, we cannot always assume that every class has locking enabled. For example, you may want to update indexes for a data class that doesn't require locking. Since the activity is "available", you can customize it as per your needs.
Thanks for your insight. If your analysis is right about "Lock" setting, then I would have appreciated if they parameterized this so everyone could use it as out-of-the-box. There are not much things to override other than this "Lock".
Anyways, thanks and I was able to achieve what I wanted.