Report created multiple times

[Lauren]

I'm programmatically laying out a report design, and it contains some expensive (slow) operations.  I noticed that the resolver's Resolve method is called twice each time I want to view the report (image of call stack attached).  I found another post here http://www.telerik.com/forums/how-do-i-get-a-ireportdocument-from-a-trdx-file#L8MMUbxn_UKgCTtHVjcNjA that mentions that Resolve will be called every time the report service requires a new report definition instance.  I'm trying to improve the performance of my report generation, and not having to generate my entire layout twice would help.  Is this working as designed?  Or do you have any suggestions to prevent generating the layout twice?

Thanks!

[Nasko]

Hello Lauren,

The Resolve method will be called multiple times, as explained by my colleague and this is working as designed.
In order to improve the performance of the report generation, you can use a design patterns, such as Singleton, or another approach to execute the expensive operations only once and then return the already generated report instance on subsequent calls.

Regards,
Nasko
Telerik

[Lauren]

Ok, thank you for the tips!

[Chris]

HI

 

I have no use "Solve" and just add new item - Telerik MVC Report Viewer R3 2016.

and report constructor run 3 times too.

 

    .ReportSource(NewTypeReportSource)

I don't know why and is there have any official document explain about this situation.

 

Best Regards

 

Chris

 

 

[Stef]

Hello Chris,

the Reporting REST Service's resolver is called multiple times on requests for:

1. Getting the report's ReportParameters collection, required for generating the viewer's parameters area at the client;
2. Creating an instance of the report;
3. Applying new parameters values submitted by the client;
4. Export and print operations;
5. Navigation to another report;
6. Refresh of the viewer;

In general:

1. The viewer has a client-side ReportSource, from which we extract the string description of the report (relative path to a TRDP|TRDX file), the assembly qualified name of a report class (<namespace>.<report_class>, <assembly_name>) or custom string (almost anything can be included with respect to REST limitations for used characters and size of the message).
2. The reports string description is submitted to the server and it is handled by the Reporting REST service's Resolver. The service's default resolvers can handle a relative path to a TRDP|TRDX files or an assembly qualified name of a report class. Anything else requires you to create a custom resolver that returns a server-side ReportSource object on its own.
3. Once the Report resolver returns the server-side ReportSource object, the viewer submits the Parameters collection of its client-side ReportSource. This Parameters collection is applied as the server-side's ReportSource.Parameters collection.
4. Next, the reporting engine starts processing the report, means the report events fire, expressions are evaluated. At that moment the server-side ReportSource.Parameters collection is mapped to the report's ReportParameters collection - where Name properties (case sensitive) are the same, values are set for the report parameters.
5. Finally, the report is rendered and paged in the requested format (HTML for web preview, PDF for export and etc.), and the content id returned to the client(viewer).

We will consider adding more details about the usage of the Reporting REST service's resolver.

Regards,
Stef
Telerik by Progress