Issue with HTML 5 Report Viewer after switching to version 9 / Q1 2015 (at least with expand / collapse images)

[Fridli Jacober]

Hello together

As we're setting up a new dev server atm, one of the first thing was trying to get the html 5 report viewer to work.

We started with newest softwares and libraries and therefore it wasn't much of a problem setting up a blank, new web site and adding the necessary stuff for the html 5 viewer and it seem to almost work perfect.

Almost, because where in the test project on my local pc where expand/collapse (+/-) images (SampleReport) is now some kind of arrow up in chrome and nothing in IE (see image attached).
Too, in Chrome I get 404 - not found errors for the images:
GET http://...../api/reports/clients/163505-14ea/instances/155744-0f00/documents/163505-973f163505-89ba/resources/Resources.Expand.png 404 (Not Found)
GET http://...../api/reports/clients/163505-14ea/instances/155744-0f00/documents/163505-973f163511-b5a0/resources/Resources.Collapse.png 404 (Not Found)
GET http://...../api/reports/clients/163505-14ea/instances/155744-0f00/documents/163505-973f163511-b5a0/resources/Resources.Expand.png 404 (Not Found)

 

I tought it might be the problem that I copied the viewer from version 8 (Q3 I guess) but am using reporting 9 Q1 on the dev server. So I did the upgrade wizard but it didn't help (it did upgrade the viewer's files but it didn't solve the issue). I then did the upgrade wizard on my local machine too to update from v8, probably q3 (where everything worked fine before, especially the expand/collapes images) to q1 15 and what happens? On my local machine now I have the same strange behaviour. It seems that with v9 "some output" has changed...?!?

On Dev server I have WebApi 5.2.3 and tried Newtonsoft.Json 6.0.4 and 6.0.8. On my local machine I have WebApi 5.2.2 and Newtonsoft.Json 6.0.6. So there shouldn't be the problem as everything worked fine there before updating to reporting v9.
I too tried another report (Dashboard) with diagram images in it on the dev server which works fine too.

 

P.S. I noticed a change in the expand/collapse image path between reporting v8 and v9. Just to mention it.
Therefore I tried the failing image path in the browser and figured out what appears and "how far" I can go... I can until (and with) the id after .../documents where I see an exception trace (http://wm4.webmembers.ch/api/reports/clients/163505-14ea/instances/155744-0f00/documents/163505-973f163505-89ba/).
Everything further give me a 404 error and anything less far gives me:
<Error><Message>The requested resource does not support http method 'GET'.</Message></Error>

I don't know what of all is working exactly and what's not but up to now it seems that this is the only thing which doesn't work right.

 

Thanks for any tipps and infos!

[Stef]

Hi Fridli,

This is a known issue with MVC projects. It is related to how the URL for the collapse/expand image is built with dots.

Please test applying the following settings based on the Don't use runAllManagedModulesForAllRequests="true" when getting your MVC routing to work blog post.

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  <!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>

The issue will be addressed by our developers in a consecutive release.

Regards,
Stef
Telerik

 

 

[Fridli Jacober]

Hi Stef

Unfortunately, I don't know what this is and I don't understand what I'm doing with this.
But I understand that I configure this module to run at every request this way...?!?

P.S. We're not using MVC. We're using "normal" 4.5 and the problem only occured after switching from v8 to v9.

But so you say, the problem isn't our environment but it's a bug instead and the report viewer basically seem to be working fine?

 Regards

[Fridli Jacober]

p.p.s. under the link you provided somebody posted this article as solution to the problem but I still don't understand it:

https://support.microsoft.com/de-ch/kb/980368/en-us

[Stef]

Hello Fridli,

The suggested settings are a temporary solution to the problem caused by the URL used for getting the collapse/expand image from the server.

The GET request currently looks as follows:

/api/reports/clients/{clientID}/instances/{instanceID}/documents/{documentID}/resources/Resources.Expand.png

The standard processing of the URL will lead to a 404 error as it will not be resolved (mapped) correctly. This request is sent to the Reporting REST WebAPI controller. The following setting replaces the default module handling the URL with one that will not cause problems with the dots in it:

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>

The issue will be addressed in a consecutive internal build, and the above configuration will not be required in future.

Regards,
Stef
Telerik

 

 

[Fridli Jacober]

Thanks for the answer!

It works but i occasionally noticed "strange random zooming behaviour" when expanding/collapsing (actually after the content is re-loaded). By playing around with the web.config a little bit and "Ctrl+F5"-ing the page several times it seems to be gone again.

As we aren't needing the expand/collapse feature atm and aren't live yet with the html 5 viewer I removed the temp fix again for the moment. Mainly wanted to know if it's a problem with our setup which seems not to be the case.

 

P.S. Are this lines good for anything or should I remove them (as the viewer works without them. They were added after installing the necessary NuGet packages.

 

Thanks and regards

[Fridli Jacober]

Oops, forgot the code lines:

    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
.....      

[Stef]

Hello Fridli,

The issue is fixed in the latest available internal build of Telerik Reporting - Q1 2015 SP1 build 9.0.15.422 (download link from your Telerik account - Latest internal builds - Reporting) . after installing it, run the Upgrade Wizard in projects having references to Telerik Reporting.
Also you can remove the temporary handler's settings.

About the zoom issue, please check if you are double-clicking in the viewer, which will trigger the viewer's  doubletap event that toggles the viewer's scale(zoom) options. To change this behavior you can edit the viewer's JS file (telerikReportViewer-9.0.15.422.js line 1274).


Regards,
Stef
Telerik

 

 

[Fridli Jacober]

Hello

Seems to fix the issue.
But I've got another question: How is it intended to pass data to the report viewer and then to the report itself (which report to show, report parameters)?
I don't think it would be a cool idea to have another report viewer html file for every report with it's report parameter... What is "best practice"?

About the zoom issue you may be right that I expanded/collapsed too fast after each other.

Thanks and regards

[Stef]

Hi Fridli,

To change the report in the current viewer you just need to update its reportSource from the client. Please check reportSource(rs) method and How To: Pass Values to Report Parameters (via custom UI).

Regards,
Stef
Telerik

 

 

[Fridli Jacober]

Hmm I think you didn't quite get me right. But I think I blocked my thoughts too with the "server side non executable html 5 viewer".

Atm (and also desired in future) we have one single reports aspx file for all report definitions. This aspx file is passed an ID (get parameter) which defines the desired report and possibly further parameters. Inside, there's a huge select/case which (possibly) executes some server side code needed for the current report and then calls the (maybe customized) constructor of the apropriate report definition where it possibly passes again some newly generated parameters or parameters previously passed to the report viewer aspx through get parameters.

So for the HTML 5 report viewer I guess I can create an aspx page too which writes out the apropriate reportSource object with its parameters (passed through get parameters to the aspx or created by server side code from get parameters) corresponding to the current report.
And for simplication of the reports resolution I guess I should abandon the custom report constructors (which is a bad approach from earlier in my opinion) and in the then having default constructors access the anyway passed report parameters (formerly passed as constructor parameters) and do my stuff if necessary.

But as some constructor custom stuff isn't posible like that with trdx reports, how would you for example do something like "SELECT ... FROM ... WHERE MyId IN ('MyId1', 'MyId2', ...)" with "... IN (MyReportParameter_IdList)"?
We never managed this by using a report parameter without manually building the select command as the report parameter then is treatened as one string instead as a list of strings like in the first example.

regards

[Stef]

Hi Fridli,

Reports with custom constructors are OK with the HTML5 Report Viewer. having a default constructor was a requirement forced by the way the ASP.NET Session works, because the ASP.NET WebForms ReportViewer relies on the ASP.NET Session, whereas the HTML5 Viewer has its own cache storage configured through the Reporting REST service's methods.
Still if you can avoid customizing reports, and use the expression engine as bindings, it is recommended to do so.

The HTML5 Report Viewer allows you to work with reports in XML format (XML stored as string or TRDX files), reports created with VS Report Designer and report created at run-time. For the standard reports (without customizations) you can use the default implementation of the ReportsControllerBase. For customized reports or reports stored in custom locations e.g., XML in a database, you will just need to plug your own custom report resolver.


About using multivalue report parameters, their running values are evaluated as arrays of objects. Regardless the underlying data retrieval method, the report parameters values must be handled with consideration for their type. Thus you can use a SQL query like:

SELECT * FROM COUNTRIES
WHERE (CountryID in (@CountryID))

where the SQL parameter is mapped to a multivalue report parameter on configuring the SqlDataSource component (step 4).

Regards,
Stef
Telerik

 

 

[Stef]

Hello,

In addition, check my post in How pass multivalues param values to report MVC or HTML5?

Regards,
Stef
Telerik

 

 

[Fridli Jacober]

Hello

Thank you for clearing up the thing with multi column parameters!
I don't know if this was not available at that time but this was one of the main reasons why we customized the constructors to pass a comma delimited string list which was inserted in the sql command in the constructor.
I'll have to try it myself to get it completely but I'll guess this won't be much of a problem.

"having a default constructor was a requirement forced by the way the ASP.NET Session works..."
I don't really agree to this. We often didn't have a default constructor and it worked properly anyway. When we switched to state server session storage, we had to add a default constructor because otherwise the session could not be serialized. Alltough there was no code inside of the default constructor. It just had to be there for serialization.

About the parameter passing: I think you still don't get me completely.
I'm not curious about how to pass parameters to the reports or how to tell the viewer which report to show. But in every example there is fixed code. You have ONE html file which shows ONE report whit its FIXED parameters.
In our case, you have the report viewer which shall show dozens of different reports (query string parameter), each with its unique parameter collection. And part of the parameters is known in the client (query string or filters) and part is gathered and passed on the server (formerly through custom constructors)

 Regards

[Stef]

Hi Fridli,

If I understand correctly the scenario, you have a single page with the HTML5 Report VIewer on it, where this page is reloaded when you need to display a new report. Thus the new report information is transferred to the page through the QueryString.

If this is the case, on reloading the page the viewer will be recreated.
Thus on creating the viewer object you need to set the reportSource attributes (report and parameters) based on the current QueryString values. To get the values from the QueryString you can use Javascript e.g., Get URL parameters & values with jQuery.
The rest parameters can be set on the server on resolving the report via custom report resolver plugged in the Reporting REST service's CreateResolver method.


If you need further help on this, please open a support ticket and send us a demo project illustrating your settings and issues on changing the report.

Regards,
Stef
Telerik

 

 

[Fridli Jacober]

Hello and thanks for your post!

 You got it right! I now decided to make it an aspx page and evaluate the query string server side. This way I don't have to expose  the whole information for every report in client-side JavaScript but only the information needed for the current report.

ASPX:
 ...
reportSource: { report: reportDef, parameters: reportParams }
...

Code behind:
Select Case Request.QueryString(0)
            Case "d7dba7d1eaee422b9c4211d5d6f152d9" ' Journal
            Case "bd52ee7f8cbf4b4abbea064577651eef" ' Rapporte
                ReportDef = "Rapporte/Rapporte.trdx"
                ReportParameters = "PersonalObjectID: '" & Request.QueryString("o") & "', ReportNr: " & Request.QueryString("f")
End Select

        ClientScript.RegisterClientScriptBlock(Me.GetType, "ReportViewerInit", "var reportDef = """ & ReportDef & """; var reportParams = { " & ReportParameters & "}", True)

This way I have full control on the server and access to all the data I need

Regards