Migrating from Oracle Reports, have a few questions

[M]

Hello, we're in the process of migrating from Oracle Reports (since it's no longer supported) and are evaluating Telerik Reporting as a solution. After looking up the the Standalone editor and make a few POC reports, we have a few questions.

For reference :

• we have ~700 reports that we will migrate over time. They all are "static" reports, meaning that we only want to produce a PDF that will be downloaded by the user at the click of a button.
• we don't intend to use the Telerik Report Server solution.
• we want our reports to consume a REST url to get the needed data (which will return a JSON). Which means we probably will have a REST url for each report.

Here are our questions :

1. What's the difference between the .NET Framework and .NET 6 standalone executables ? Why use one or the other ? Are the report files (.TRDP/.TRDX) produced identical between the two ?
2. When upgrading Telerik Reporting, we understand that we have to be careful about the version and it's changes. What about the report files ? Do we have to "upgrade" each and every one of them manually each time we upgrade Telerik Reporting ? With ~700 reports, it would be way too much time consuming.
3. Our development workflow would be the following. Are there any catch we should be aware ? Is it feasible ? 
   1. Create a REST url for the new report
   2. Create the new report with the standalone editor and set it's datasource with the newly created REST url
   3. Push the report on a custom report server
   4. Implement the call to the report in our application

4. Lastly, what's the best practice for the report versioning ? We'd like to use a GIT to store our report files and show diffs between each revision. I understand I would not be possible with a .TRDP since it's an archive, so should we save and store our report file as .TRDX to achieve this ?

Thanks a lot for your help !

[Todor]

Hi,

Thank you for considering our product.

Let me start by suggesting the WebServiceDataSource component that can fetch the data from your web service and feed the data items with it.

Regarding your particular questions:

1. The TRDX and TRDP reports are identical between the two Standalone Report Designers. The main difference is in the custom assemblies you may reference in the designers. In the designer for .NET Framework, you may reference only assemblies for the .NET Framework and .NET Standard 2.0

With the .NET designer, you may reference custom code targeting .NET 6+ and .NET Standard 2.0+.

The designer for the .NET Framework can also connect to the Telerik Report Server. This functionality is not yet available in the .NET version of the designer.

2. You need to upgrade only your viewers and services to the newer Reporting version. The TRDP/TRDX reports from an older version may be used seamlessly with a newer Reporting version. If you edit such a report in the Standalone Designer with a newer version, its schema will be updated to the new one - see XML Schema.

3. The first two steps seem fine. I don't see potential failures in the workflow.

When it comes to pushing reports to the custom report server, you need to keep in mind that the built-in UriReportSource that may be used to pass to the Reporting engine TRDP/TRDX reports is designed to work with physical paths. For example, it cannot resolve a report from a database, or a remote URL through a web request. You need to have the report on the machine where you run the Reporting engine or Reporting REST Service.

For the scenarios when the report file is not directly accessible from the service machine, you need to get the report definition and return it to the Reporting engine in a server-side ReportSource. If you use Reporting REST Service, you need to create a Custom ReportSource Resolver that does this in its Resolve method.

For the final step, you may render the report with code, for example, as explained in the article Generating Reports Locally with Code, or if you use a Reporting REST Service, you may download it with the Reporting REST Service API.

4. Indeed, you need to use the TRDX format in version control environments when you want to be able to compare content visually. We store reports in our repos in Github in both formats, TRDX and TRDP. We prefer TRDX for the same reason. The TRDP files get deleted and uploaded rather than updated, so you cannot directly compare the two versions.

Regards,
Todor
Progress Telerik