Reports: separating the Source from the Display
Business need: What's the best & most efficient way for users to specialize reports?
From: https://pdn.pega.com/forums/prpc/reporting/reports-separating-the-source-from-the-display
There's been several iterations of reporting in Pega.
Early on, the thinking was to separate the list of columns (Rule-Obj-List) from the criteria definitions (Rule-Query-List/Summary)
I think some variation of this idea might still have merit.
My experience tells me that there's two main pieces of a report: the Source, and the Display.
The Source includes the class/joins, columns, & calculations, and the max rows (e.g., the SQL call, minus the paging)
The Display includes, the criteria values, paging size, output type (e.g., chart), column order/visibility.
Some advantages:
Business need: What's the best & most efficient way for users to specialize reports?
From: https://pdn.pega.com/forums/prpc/reporting/reports-separating-the-source-from-the-display
There's been several iterations of reporting in Pega.
Early on, the thinking was to separate the list of columns (Rule-Obj-List) from the criteria definitions (Rule-Query-List/Summary)
I think some variation of this idea might still have merit.
My experience tells me that there's two main pieces of a report: the Source, and the Display.
The Source includes the class/joins, columns, & calculations, and the max rows (e.g., the SQL call, minus the paging)
The Display includes, the criteria values, paging size, output type (e.g., chart), column order/visibility.
Some advantages:
- When calling the report programmatically, only the source would be needed (with parameters passed in).
- Many different Displays could re-use the same Source.
- Typically a user will customize the Display for their own queries.
- The user's customization cannot make a runaway query (assuming that the max rows are setup in the Source definition)
Without this customization, user need to SaveAs the whole report, and as such the Source part of the report would be duplicated. Any changes any of the Source fields (e.g., adding properties to the request)
One possible way to achieve this is to create a subclass of Report-Definition which allows certain aspects of the report to be inherited from a specified Report
Related to this -- what's the best way to count the records returned by an existing report?
Given a report (Source + Criteria), is there a function / control that exists that can run a variant of the SQL which just returns the select count(*)?
Never seen this, so have always ended up building this custom.
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems
IN
The direction is to use grids to display the data and control the paging, sorting and other things. Report definitions can be used just to fetch the data. The separation may not be exactly as you provided but that is the idea. Report definitions have these features as well because we use report definitions for adhoc reporting where reports are created on the fly from the report browser and is designed.
On the count of records, the result page should have the total count. Refer pxResultCount property on Code-Pega-List page.
BNY Mellon
US
So what's the best way for a user to create a customization of a report?
Think of doing this in Jira -- you take an existing report, change your criteria, and save.
My concern was that the report definition (source, columns, etc) should be fixed (and separate).
Also, on the count of records -- what I'm looking for is a reusable Function / Control.
And my point was that it may be more efficient to skip the column mapping, just due a select count(*)
Pegasystems
IN
Maybe I am not following correctly, but wouldn't report editor just give you this feature where you open an existing report, change the columns and do save-as. This also include the sorting as well. You can also change the display style also.
Regarding changing the source, does it mean to change the applies to class (pyClassName) of the report or the underlying database or schema (reports DB functionality in Data-Admin-DB-Table)?
For the count part, this could be an enhancement to the existing functionality. I will pass it on to product management.
BNY Mellon
US
Yes, correct, in Report Editor, the end-user can be guided to use an existing class to base the report on, so that they wouldn't wander and create their wn one.
Though I don't have Save As; I only have the button Apply Changes & Exit.
Pegasystems
US
Hi Jon,
These are great questions. Since more recent Pega versions have replaced the old “form builder” with actual harness rules for rendering the rules, would you be able to create your own subclass of “Rule-“ and prototype a demo of the split report definitions ?
Similar for the count(*) idea, would you be able to over-ride the report-rule harness and in your over-ride add a button to the rule form called “preview count of items” ? I would envision that the way that would work under the hood is that it would generate the same sql as actually running the report, except it would replace the “select * where . . . ” with “select count(*) where ” . The actual popup and display of results would be similar to the way “test connection” works for class rules, so you could use that logic as a jumping off point. Actually, you might only need to over-ride one section of the harness, whichever section you’re going to add the new button on.
/Eric