1. DataPage at Node level which has around 5000 results.
2. Pagelist B which has around 600 results.
I am iterating over Data Page and using a pre-condition @IsInPageList() to check against pagelist B, if true doing a Page-Copy. Likewise i have few pre-conditions along with @IsInPageList().
I have benchmarked the time and it is taking around 4 secs with or without using @IsInPageList(). I am assuming this impact is due to the number of results. Is there any efficient way to do this Page-Copy which can improve the performance? (to < 3 secs?)
Did you try building a reusable function rule for this purpose. Have 3 parameters to the function;
1. PageList A (DataPage / 5000 results) / 2. PageList B (600 results) / 3. PageList C (populated by Page-Copy)
If the you get any issues with referring the data page directly from a function, you can setup a pagelist property with reference set on data page.
Try this with your earlier benchmark? you might get a improvement.
1.The IsInPageList and the other when conditions will go inside the function. But you can improve reusability by creating seperate WHEN rules instead of hard coded expressions. So that if the conditions change, you can change the WHEN rules without touching the Function rule.
2. If the other pre-conditions contain references inside the two page lists you won't be able to use WHEN rules separately. (because they are parameterized to the function)
3. The code will look a bit messy
Posted: 5 years ago
Posted: 16 Sep 2016 17:19 EDT
Matthew Osborn (mjosborn85)
Finance BPM Mgr
We just dealt with this same issue. Page-Copy is a very expensive operation -- no getting around it. It's tempting to think that the data retrieval is the expensive bit, but if you're retrieving from a tuned database then No! Ironically the in-memory iterate and page-copy is orders of magnitude slower than the database call-and-populate.
With 5000 items there is little you can do to speed that up with these methods. However, if you're willing to stretch the Guardrails, you can fix this...
If possible, use Obj-Browse or report definition to retrieve the exact values you want into an editable (throwaway) Data Page. Then use a Java step or a function to call the Public API Clipboard.move() function to steal the pxResults property from the Data Page to wherever you need it. This operation is nearly instant. For us, this turned a 40 second process into a 4 millisecond process.
Caveats: All filtering dependencies must be exposed in the database. The source data should be trusted. I suspect that Page-Copy might be slow because it triggers validation? Don't really know. But this technique will skip it.
If you cannot reload the source data every time, I did find that performing a data transform pxResults <- pxResults took have the time compared to individual Page-Copy of each pxResults item in an Activity.