We are currently migrating from the older ReportViewer to the newer HTML5 ReportViewer.  We use a ReportBook to display all our reports, regardless if it is one or multiple reports.  Inside the ReportBook’s constructor, a method is called that determines which reports are to be displayed and puts them in a loop that does the following:
1. Uses LINQ to SQL to generate the data to be displayed,
2. Instantiates the report,
3. Assigns the generated data to the report’s DataSource property, and
4. Adds the report to a ReportBook.

All of this is done in code, in the ReportBook’s constructor.  Yes, I realize Telerik probably wouldn’t recommend doing it this way.  The individual reports do not use the designer to create a SqlDataSource, ObjectDataSource, etc…

This design worked with the old ReportViewer because it simply instantiated the ReportBook once on the server and returned markup back to the client.

The HTML5 ReportViewer seems to expect that the report use data sources which are generated as a result of the report being created instead of having the data generated before the report is created.  Our problem is that the HTML5 ReportViewer calls the ReportBook’s constructor 3 times, which results in the data for each report to be generated 3 times.

I have tried using counters to generate the data only 1 of the 3 times the ReportBook’s constructor is called, but the data does not display.  I’ve tried on the first call, the second call, and the third call, but the report does not display the data. 

Therefore, I can’t think of a way to upgrade to the HTML5 ReportViewer without making drastic changes to our reports.

Given our current design, can anyone from Telerik suggest a way to upgrade with minimal changes?

When I say we use a ReportBook to display our reports, I mean we have created an object which inherits from ReportBook.  This is how we have access to the constructor.

Hello Keith,

Indeed, HTML5 report viewer uses Reporting REST service in order to display reports. Therefore, run-time changes to report needs to be inside the custom report resolver that is used by the service. Resolver's Resolve() method will be called several times, it will happen each time when the Reporting engine needs the report source.

To avoid retrieving of the data each time the Resolve() method is called, my recommendation is to consider using a custom cache where the already created data object can be saved and retrieved from. Report can connect to the data object using ObjectDataSource which DataMember property is set to the method that retrieves the data object from the cache or instantiates it if the cache is empty.

In case there are still issues with migration process you can share the code that creates the ReportBook so we can test it on our side.


Regards,
Katia
Progress Telerik