Progress® Telerik® Reporting R3 2020

Telerik Reporting REST Services

The Telerik Reporting REST service provides an Application Programming Interface (API) over HTTP to the reports generation engine. This engine allows exporting report documents in all supported rendering formats. The server - client communication relies on simple Data Transfer Objects (DTOs). All DTOs are JSON encoded.

The service primary usage is in the HTML5 Report Viewer ecosystem. It leverages the pure client side implementation of the viewer. You may also use this service in JavaScript application without the viewer. Then please check out the telerikReportViewer.ServiceClient class in the JavaScript API.

The service has several implementations targeting different web service frameworks which are described in this chapter.

How it works

The service exposes all report generation assets, including report instances, report documents, images or other rendered report meta-data as web resources accessed from specific web endpoints. A set of requests issued from a particular client host is wrapped in a client session identified by a clientId. The client session expires in particular time span which can be configured. That said, in the boundaries of a client session the same requests result in returning the same cached resource. An exception is the Register Client endpoint which can enforce regeneration to support the Refresh Report functionality. To achieve that, a useCache = false setting should be added to the request body.

The Reports service can be configured in the application configuration file, either .config or .json for different service implementation: restReportService Element

The client of the service requests a report by a JSON object called client report source. The service then resolves this to a .NET report source. To do that it uses a REST Service Report Source Resolver. The Telerik Reporting REST service serves the rendered reports as web accessible resources. The service caches all generated resources in a REST Service Storage of choice.

In some scenarios you need to share the service for more than one app. For these you may need to turn on Cross-Origin Resource Sharing.

If all new report requests get executed simultaneously the host will get overloaded. To avoid this the service executes the report generation requests in a task queue. The count of the simultaneously rendered reports is configurable. In some scenarios you need to host two or more reports services into a single application. For that do assign a unique HostAppId property on each implementing controller. This will produce dedicated task queue for each service instance. Please do set appropriate worker count for each queue so that the system does not get overloaded.

In this article
Not finding the help you need?