How can we cancel the report?

[Tursunkhuja]

Scenario: We are printing a financial transaction report from an odata service.  The query is very large because the user entered a query that requests too many records.  Now I want to cancel the report because it is taking too long to generate.  How can we cancel the report? (Canceling the report should cancel odata request as well).
Odata uses cancellation tokens to cancel.  See: https://docs.microsoft.com/en-us/dotnet/api/system.threading.cancellationtoken?view=netframework-4.8

Here is one post to cancel report, but it's solved: See: https://www.telerik.com/forums/cancel-report-generation

 

[Tursunkhuja]

Here is one post to cancel report, but it's not solved yet: See: https://www.telerik.com/forums/cancel-report-generation

[Todor]

Hello Tursunhuja,

Report generation cannot be cancelled.
The workaround we recommend is described in the referred Cancel Report Generation forum thread.
You may try also to use an ObjectDataSource component where to fetch the data from OData service and use custom logic to control data retrieval. For example you may cancel data fetching upon some condition and return no data, and use the No Data Message feature to inform the user that the report processing has been cancelled.

Regards,
Todor
Progress Telerik

[Tursunkhuja]

Hello Todos,

I have server app and I am using WebServiceDataSource with OData connection to load entities. I am designing it with Telerik Report Designer version: 13.0.19.222.Is it possible to cancel odata request somehow in business login side?

[Todor]

Hello Tursunhuja,

The WebServiceDataSource will wait for a response after making the data request. It is not possible to cancel this request. It will be necessary to use an ObjectDataSource with custom code to achieve the requirement.

Regards,
Todor
Progress Telerik

[Tursunkhuja]

The suggestion in https://www.telerik.com/forums/cancel-report-generation is to kill the thread.  There are two problems with this: 1) Killing a thread seems like a bad work around. 2) Killing the thread won’t cancel the Odata request.

1. Is the WebServiceDataSource open source so that we can modify it without needing to reinvent the wheel? Even if we create the ObjectDataSource, is there a way to cancel the report gracefully rather than killing the process?

2. Canceling report generation seems like a basic requirement for a report writer. When we were evaluating Telerik reporting, we just assumed this would be there. Is there any plans to add this functionality?

[Todor]

Hi Tursunhuja,

Let me suggest a possible workaround with an ObjectDataSource.
You can make two Odata requests in the data providing method. The first one should be a fast one, requesting just the amount of data that would be returned with the real query. Based on this amount you should decide whether to make the real request, or return for example an empty collection or throw an error. This error may be handled in the viewer (e.g. error event) or the logic that uses RenderingResult.

Our code is not an open source and should not be modified.
Currently the report cannot be cancelled smoothly and we will consider adding an option for report cancellation. However, we plan our new features ahead and this feature is not in our road map yet.

Regards,
Todor
Progress Telerik

[Tursunkhuja]

I'm using ObjectDataSource with ExpandoObject. I downloaded that sample project from this link: https://www.telerik.com/support/kb/reporting/details/how-to-use-objectdatasource-with-expandoobject

But, the only issue I'm having is the dynamic properties of the expando object is not showing on the data explorer.

I am getting json data from an odata source. I noticed that your web service data source shows properties in the data explorer.  Obviously these are created dynamically because json isn't statically typed.  Could you send me a snippet of code on how you show properties in the data explorer with the web data source.  This is a requirement for the objectdatasource that I am creating.

 

[Todor]

Hello Tursunhuja,

If I understood correctly, you would like to see the Names (i.e. the value of the Key property) of the dynamically created ExpandoObject properties in design time.

Note that we use System.Reflection to drill through types' properties. In design time the custom properties of the ExpandoObjects are not available yet, hence cannot be found. In fact ExpandoObject is a collection of KeyValuePair, hence its properties are Key and Value as can be seen when the ObjectDataSource is fed with data by a method that returns an ExpandoObject. Therefore, the requirement cannot be currently achieved directly.

You may check the Dynamically create property name forum post for a workaround.
The workaround should allow to create dynamically a type with properties, which names correspond to the Key of the ExpandoObject. If this type is assigned to the ObjectDataSource (i.e. replacing ExpandoObject), the Report designer should be able to display the real property Names instead of Fields.Key.

Feel free to log this requirement in our feedback portal, so that other users can vote for it - the prioritization of our new features implementation depends on the votes received from our users.

Regards,
Todor
Progress Telerik

[Tursunkhuja]

The problem here is that there is a limitation with your web service data source.  We were told to create an object data source.  See the current post above. How do you show properties in the data explorer with your web service data source?
We must be able to show properties in the data explorer.   

[Glenn]

@Todor,

I talked with Tursunhuja.  Let me make the requirements clear here:

== Requirements ==

- We need to be able to read odata (Json web service)

- We must be able to cancel that web call.  You recommended implementing our own web service data source with ObjectDataSource so that we can implement the cancel token ourselves.  A sample was given which implemented the expando object. I like the idea of using an ObjectDataSource because there are a few other things we could do to make things nicer for the user that is creating the report.

- We must be able to see properties in the data explorer of the standalone report writer because users are not techy enough to find the property names and we want them to be able to modify reports.

== Non-requirements ==

- We do not need to use expando objects.  We have json. Json is, of course, dynamic. I don't have static types on the client.

== The real question for you to answer ==

We need to be able to do the same thing as your web data source where you read json and somehow get the properties of those json objects to show in the data explorer. Obviously this is possible because you are doing this in the web service data source. Is there any example code?  Can you send us what object types you use in your web data source.  Better yet -- just send us a snippet of your code from the web data source.

We tried the ICustomTypeDescriptor. That solves the problem of getting errors when printing, but it does not solve the data explorer problem.

 

[Todor]

Hi Glenn,

Thank you for the clarifications and for summarizing the requirements in a single post.

The code for our WebServiceDataSource is coupled with the base logic for the data sources. Therefore, I am not sure if it will help.

I will suggest a workaround that may work for your scenario.
The ObjectDataSource can take a DataTable as input - check Supported Object Types. It should be possible to fill the data from the incoming JSON, or from the ExpandoObject in a DataTable and pass it to the data source. Our engine has dedicated logic that would recognize the table columns and display them as data fields in the Report designer.

Regards,
Todor
Progress Telerik

[Glenn]

Todor,

Ok, that makes sense.  There is one concern with the DataTable: I am guessing that is a flat file.  For example, it would not support customer.Address.State as the web service data source does today.  Am I correct?  If it does support nested objects, then I think that is the answer we need. 

[Todor]

Hello Glenn,

For the DataTable approach it will indeed be necessary to flatten the data, e.g. use columns like Address_State and flatten the data among all Addresses and States.

Our developers came up with another approach that seems more simple and easier to implement and maintain. Next I will explain it:
You should use the ItemDataBinding event of the data item (e.g. Table, Report, etc). At this point you have the values of the Report Parameters - in their Processing instances (namespace Telerik.Reporting.Processing). So, it is possible to construct the query that will be used to fetch the data. Thus, you may request from the service the count of the data records that will be requested by the original data source (WebServiceDataSource). If you decide that this count is too big, you may set the DataSource of the data item (its Processing instance) to Null, and the original data request will be skipped. Note that as you modify the Processing instance of the data item, the definition instance (namespace Telerik.Reporting) will not be changed, and on the next processing the data source from the definition will be preserved. If the decision is that the data should be fetched from the original source, it won't be necessary to make any changes.

Regards,
Todor
Progress Telerik