Rank 2
Iron
Iron
Veteran
We use Web service data source in a report which has long OData query.
After adding filters, the OData query becomes too long. That's why it causes 404.15 error.
This is probably due to the limitation of maximum Url length in browsers. It is about 2048 characters (for IE). So there different limits for different browsers and web servers. https://www.geeksforgeeks.org/maximum-length-of-a-url-in-different-browsers/
To solve the issue probably we can use POST method in the web service data source instead of GET method.
I have "@url", "$select", "$expand" and "$filter" parameters set in the data source. How to use those parameters in body of the post request? And is it good solution?
As a sample report you can use attached report (TestProductReport.zip). The sample report has web service data source. The query in Service URL is short in this case, but we have long query in other report.
Getting error 400 when previewing the sample report. Any idea to fix this issue?
Thank you for the attached report!
I reproduce the problem with it but I must say that you have set up the WebServiceDataSource correctly, this is how you can use the post method and how you can set the req body dynamically.
I tried to make this request the same post request in a tool for testing APIs and I got the same error which leads me to believe that the problem has to do with the service and not the report, please see the attached image.
I advise checking whether you are making the request correctly, with all required parameters.
Note that you may be able to work around the browser URL limitation issue if you use the ObjectDataSource to get the data through C#/VB code.
Thanks Dimitar!
From your answer and the attached picture I understand that we are not able to do POST request to our service. But, the Telerik report is being able to make POST method request. Using the ObjectDataSource data source is not suitable for our case.
I am not sure that I understand what is meant by " the Telerik report is being able to make POST method request".
To me, the behavior seems to be the case when testing with the tool and with making the same request through a WebServiceDataSource in the report, both return status code 400 which to me indicates that the problem is either in the request structure or in the web API itself.
My recommendation is to use a tool like Insomnia to see what should be the correct URL and request body for the request to return 200 and then replicate that in the report's WebServiceDataSource.