Report Definition - Custom HTML fragment called twice when clicked on page 2
We have report definitions that can return data for multiple pages of page size of 25 or more based on each report definition. For logging a NPI data, we developed a custom HTML fragment that would call an activity which will in turn insert records into a custom proprietary table. This works fine for page 1 of the report definition. When we click either next or '2' link, it calls the custom HTML fragment twice against only once. This custom HTML fragment is defined in report definition under Design tab (Format values area). See attached for details. We have tested with multiple report definitions in various applications and result is same.
Steps to Reproduce
Create a report definition , have data for multipage, configure a custom HTML fragment that could call an activity. See what happens when you click next or page 2 or 3 and so on.
No error message but inconsistent system behavior between first page invocation display vs multi-page display.
Suppose if there are 93 records and 50 records page size, here is the outcome.
• Page 1 invocation – For each row of the output resultset, this activity was called through custom HTML fragments (50 times in page 1 but we have a criteria to exit if index is > 1 for row numbers greater than 1).
o Custom fragment called 50 times but only executed once due to exit condition on index parameter of the pagelist.
• Page 2 invocation – For each row of the output resultset, this activity was called through custom HTML fragments (43 * 2 times in page 2 but we have a criteria to exit if index is > 1 for row numbers greater than 1).
o So for some reason, index = 1 comes twice, thereby resulting in executing this activity 2 times (out of 43 *2) instead of 1 times (out of 43 * 1)
Can someone explain this behavior and help us identify a solution where it doesn't call activity twice in page 2 vs page 1?
As it is a custom HTML section, my first thought is to wonder if it is not actually doing what it appears to be doing behind the scenes. Have you confirmed that it is definitely picking up the index = 1 twice? I wonder if it's more something like the paging causes the fragment to load differently than on initial display, causing it to run the same logic (correctly) twice.
Does the same double execution happen if you page back to the first page? If so that would indicate any troubleshooting should focus on what happens during the paging itself, not page 1 vs. page 2.
Brendan, It is picking up twice on page 2, page 3 consistently across different report definitions. On Page 1, it picks up only once. I do think its a product defect unless Pega can effectively clear the air for me.
We can’t really call this a defect because of a custom piece of code executing something the system wasn’t necessarily designed to do. But you can certainly use this community to see if other participants are interested in engaging in this discussion to work out the custom behavior and figure out how to get it to execute appropriately for your scenario.
While I may not be the best participant to troubleshoot code with you, I will offer the advice that you might want to take a step back and reconsider if there is a better way to implement what you are trying to do.
How is the table implemented? Is all the data already retrieved and on the clipboard or loaded dynamically on the paging? If the former, why not insert all the data on initial load of the report instead of having custom code associated with every row?
Report Definition allows Custom HTML fragment to be added. Custom HTML is not complicated. It simply passes some parameters to an activity which does the work in the background. Since it is an optional featured provided by Pega, Pega OOTB code like ApplyColumnConfig executes in the background. Hence, reached out to community if someone experienced similar behavior and any solutions etc.
Fair enough. Still, while the system may allow you to define the custom HTML fragment, I don't think the primary purpose is for scenarios like this. Per the description in your original post, the custom HTML is being defined in a design area for formatting values. The primary use case for using custom HTML is to define the visual formatting of the data being displayed in a particular cell, not to insert code that runs against the data set being displayed in its entirety.
I'd still look into different design options than the one you're attempting. But I leave it to the community to see if anyone has ideas or recommendations that can help you out.