172
Views
5
Comments
Solved
[Ultimate PDF] Timeout when trying to PDF print of filtered table
ultimate-pdf
Reactive icon
Forge asset by Leonardo Fernandes
Application Type
Reactive

Hi all,

I am playing around with reporting in OutSystems and created a simple demo.

However, I am having problems with timeout when navigating to the PrintLayout screen. 

For filtering I kept it simple for now, basically, you can specify the number of records you wish to display as well as a checkbox to get a specific record.

The OnRender client action calls the PrintToPDF server action but it does not seem to work.

How can one fix this or would be the correct approach to tackle this problem?

I have attached the OAP for reference.

Thank you for looking.

Demo_Reporting.oap
2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

Hi André.

Make sure you understand the screen lifecycle events. The OnRender event will be invoked whenever the screen changes, due to a filter being changed or an aggregate being fetched for example. I am sure you don't want to use that event to generate PDFs. That is probably generating dozens of PDFs every time you load the screen, which is probably what's causing performance issues on your application and causing timeouts.

If you're still having issues with timeouts, you can change the Server Request Timeout in your call to PrintToPDF_Advanced to suit your needs.

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

I have also noticed that you placed the PrintToPDF call in the PDF screen itself.

That means, when the system attempts to generate the first PDF, the PrintToPDF call will start generating another PDF. This second PDF will then make another call to PrintToPDF again, launching a third PDF... and recurse ad infinitum until the server runs out of memory, reboots, or explodes, whichever happens first.


The call to PrintToPDF should probably be in the GenerateQuotesReportOnClick, just make sure to use the URL of the PDF screen like so: "/Demo_Reporting/Projects?NumRecordsProjects=5&FilterByKeyword=true"

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

I have also noticed that you placed the PrintToPDF call in the PDF screen itself.

That means, when the system attempts to generate the first PDF, the PrintToPDF call will start generating another PDF. This second PDF will then make another call to PrintToPDF again, launching a third PDF... and recurse ad infinitum until the server runs out of memory, reboots, or explodes, whichever happens first.


The call to PrintToPDF should probably be in the GenerateQuotesReportOnClick, just make sure to use the URL of the PDF screen like so: "/Demo_Reporting/Projects?NumRecordsProjects=5&FilterByKeyword=true"

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

Hi André.

Make sure you understand the screen lifecycle events. The OnRender event will be invoked whenever the screen changes, due to a filter being changed or an aggregate being fetched for example. I am sure you don't want to use that event to generate PDFs. That is probably generating dozens of PDFs every time you load the screen, which is probably what's causing performance issues on your application and causing timeouts.

If you're still having issues with timeouts, you can change the Server Request Timeout in your call to PrintToPDF_Advanced to suit your needs.

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP
Solution

I have also noticed that you placed the PrintToPDF call in the PDF screen itself.

That means, when the system attempts to generate the first PDF, the PrintToPDF call will start generating another PDF. This second PDF will then make another call to PrintToPDF again, launching a third PDF... and recurse ad infinitum until the server runs out of memory, reboots, or explodes, whichever happens first.


The call to PrintToPDF should probably be in the GenerateQuotesReportOnClick, just make sure to use the URL of the PDF screen like so: "/Demo_Reporting/Projects?NumRecordsProjects=5&FilterByKeyword=true"

2023-02-06 14-27-11
André Smit

Hi @Leonardo Fernandes 

Thank you for taking the time to have a look, appreciate your input.

All seems to be working, now I can start to build a bit more complex filtering into the tables.

Although this question may be better suited for a separate discussion, I'm curious about the best approach regarding Application Objects. Would it be advisable to create individual 'PrintLayout' screens for each data source?

To clarify further, let's consider three sources: Projects, Quotes, and Invoices. Each of them requires distinct filtering capabilities, meaning that it may not be feasible to utilize a single screen for all PDF printing tasks. I assume that incorporating filtering into the URL might lead to excessive length and complexity. As a result, the potential savings of a couple of Application Objects may not outweigh the drawbacks.

What are your thoughts/suggestions?

Thank you once again for your assistance.

2019-07-08 11-04-35
Leonardo Fernandes
 
MVP

Indeed each PDF report usually uses 1 AO.

If that becomes an issue, you might combine multiple reports into a single screen, for example you could create a concept of "ReportType" and receive the report filters via a JSON object. In the screen, you would need to have logic for all reports.

This strategy saves AOs but hurts the maintenance of the application, since changes in one report might unexpectedly affect other reports.

2023-02-06 14-27-11
André Smit
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.