Table with large data support (about 600,000 rows in DB and pagination with 1,000 rows per page)
Currently, we have requirements about table displaying for huge amounts of data with features as follows:
- support about 600,000 rows fetched from external database
- display pagination with 1000 rows per page with acceptable UI responsiveness
- support filtering/sorting/inline editing
We tried to POC those requirements, but the result is unacceptable by users due to slow UI responsiveness.
Anybody, please suggest me for the best approach for this.
Thank you in advance,
Pegasystems Inc.
US
Reporting facilities in Pega are designed to support interactive reporting, and 600 pages with 1,000 rows per page exceeds that definition. Scrolling through 1,000 rows is not user friendly nor is paging through 600 pages. You need to think a bit more about how your users will be using this report.
If it truly needs to be used interactively inside the application, then you need to provide some reasonable initial filtering to substantially reduce the volume of data being presented. Your end users can then alter the filtering to suit their specific needs.
Make sure you are not trying to present a "one size fits all" report. If writing multiple reports against this external DB cuts down on the data for any given report and serves specific users better, then that is something that should be done.
Finally, if this report is being run specifically to export it (e.g., to Excel) then you should probably use BIX.
KBTG
TH
Thanks for reply,
P.S. Our situation is my users will use new web application (PEGA platform) instead of their old web application (.NET web application)
Reporting facilities in Pega are designed to support interactive reporting, and 600 pages with 1,000 rows per page exceeds that definition. Scrolling through 1,000 rows is not user friendly nor is paging through 600 pages. You need to think a bit more about how your users will be using this report.
-> We didn't use table to show for reporting purpose, we show table in section for review and editing purpose
-> Yes, we think much about this and fought with these not-user-friendly requirements but our users told us that their old system (web application) can do this and they expect PEGA to do the same or better
-> And our users want to do inline editing also
If it truly needs to be used interactively inside the application, then you need to provide some reasonable initial filtering to substantially reduce the volume of data being presented. Your end users can then alter the filtering to suit their specific needs.
-> We will try to adjust the requirement to do so
Thanks for reply,
P.S. Our situation is my users will use new web application (PEGA platform) instead of their old web application (.NET web application)
Reporting facilities in Pega are designed to support interactive reporting, and 600 pages with 1,000 rows per page exceeds that definition. Scrolling through 1,000 rows is not user friendly nor is paging through 600 pages. You need to think a bit more about how your users will be using this report.
-> We didn't use table to show for reporting purpose, we show table in section for review and editing purpose
-> Yes, we think much about this and fought with these not-user-friendly requirements but our users told us that their old system (web application) can do this and they expect PEGA to do the same or better
-> And our users want to do inline editing also
If it truly needs to be used interactively inside the application, then you need to provide some reasonable initial filtering to substantially reduce the volume of data being presented. Your end users can then alter the filtering to suit their specific needs.
-> We will try to adjust the requirement to do so
However, we wants to know/learn the best development approach or technic to fulfill these requirements and if PEGA can't do that with acceptable UI responsiveness, I'll tell them. But if this is the case, I want something like confirmation email or evidence from PEGA that PEGA doesn't support these requirements for now.
Many thanks in advance,
Updated: 1 Dec 2020 3:51 EST
IT
US
We had the similar requirements for one of our client, we achieved it as follows.
Results Export:
1. Once user initiates the search for required results, we invoked an activity to run the BIX extract.
2. Create an activity that runs the BIX extract and exports the results into an EXCEL to a network drive and then email the generated excel attachment to the user.
Row Editing:
Allowing users to edit 1k rows on the page is going to cause the concurrency issues and will throw errors. If the values being populated are common for all records, we could probably think about Bulk Edits feature. Bulk edits for updating common values can be done through a modal window and by calling RDB methods to post the changes.
You will need to group the editing features into multiple bulk edits and then achieve them through RDB methods.