Rank 2
We're building an Azure Web App using an Azure SQL Server database. It will incorporate Telerik Reporting. We have no plans to use Report Server at this time. The target framework is .NET Core 3.1.
Currently, we're building reports using the standalone desktop report designer, with SQL data source connections. The intention is to integrate these as another project in the solution at a later date.
Is this the best way to proceed? Are we better off using the EntityDataSource component?
More to the point, what are the architectural decision criteria and best practice patters for this kind of development? Where might I find them documented?
For example, we could set up a data access layer as a separate project in the solution, and then it could be built as an external assembly to make it available for designing reports. This would have the great benefit of decoupling the database from the solution and providing a single common interface to the data for all projects (and indeed, any future other solutions).
But it is clearly more work. What are the criteria to choose the approach to use?
Should we even be using the standalone report designer? Should we be using the Visual Studio Report Designer instead? I do understand that we currently can't use this, but I also understand that .NET Core 3.1 support is coming real soon now. (Roughly when, please?)
When should we use the HTML5 Report Viewer and when should we use the HTML5 ASP.NET MVC Report Viewer? What are the advantages and disadvantages of both?
Again, what is the best pattern, the recommended approach? And using what criteria?
I realise I'm asking a set of very open-ended architectural questions; I'm hoping that you might provide some general guidance here as it would certainly be extremely useful for us right now, and quite likely for a lot of other folk in the future.
Best wishes, Donna Kelly
1 Answer, 1 is accepted
Hi Donna,
Generally, we support the Azure environment as well as any other environment that complies with our Requirements:
- System Requirements
- Reporting Web API REST Service Requirements
- Html5 Report Viewer Requirements and Browser Support
Regarding the Azure platforms, please, have in mind that they recently stopped supporting metafiles. This requires images to be incorporated in some Report documents as bitmap files, which makes them non-scalable. We are still investigating the problem and looking for a better solution.
Regarding the data layer, I confirm that you may use it in the reports through our ObjectDataSource component. The EntityDataSource component is dedicated to the EntityFramework for .NET Framework. It cannot be used with EntityFramework Core or in reports that would be rendered with the Reporting engine running in .NET Core/5/6 projects.
Note that when you use the SqlDataSource component, you provide only meta-information on how the Reporting engine should connect to the database. Our engine utilizes the specified ADO.NET data provider for this purpose. It passes the connection string and the query to the data provider and waits for the returned data. That said, our code is coupled only to the ADO.NET, which is part of the .NET environment.
Generally, we cannot recommend which data source to use as this strongly depends on the particular requirements, environment, etc. Indeed, implementing a dedicated data layer may be an extra effort that requires also additional maintenance. You may avoid this if the SqlDataSource works for you. On the other hand, if you anyway need to have this data layer for other projects, you may use it also for your Reporting implementation through the ObjectDataSource. This would give you more control over the database connection, fetched data, etc.
When it comes to the Report Designer, I strongly recommend utilizing TRDP or TRDX report definitions in your projects. Note that you may stick to the Standalone Report Designer, or use the Web Report Designer to edit these reports. If you integrate the latter in your application, your users would also be able to edit their reports directly from your application. For dynamic modifications of the report layout, you may use the Bindings, Conditional Formattings, User Functions, and other Expressions and Global Objects directly in the report definitions. The benefit of this would be the much easier maintenance of your reports. You won't need to maintain additional classes.
I confirm that the Visual Studio Report Designer for .NET Core is in active development. It is being developed under .NET 5. Currently, it can be built also with .NET Core 3.1 and we don't see any reasons for it not to work in .NET Core 3.1. Generally, we are targeting the widest set of environments for it, from .NET Core 3.1 to .NET 6. Unfortunately, this information is not final as there is a lot of work still to be done. For the same reason, we cannot state an exact release date for the first version of the designer. We hope to release it in the first half of 2022.
Regarding the viewers. All our web viewers (I exclude the legacy WebForms Viewer that is no longer developed) are based on the Html5 Report Viewer. The MVC Viewer is a wrapper of the pure Html5 Viewer and has exactly the same functionality and outlook as the pure Html5 Viewer. Importantly, it is an ASP.NET MVC viewer that is not compatible with the .NET Core Framework. Hence, you need to use the pure Html5 Report Viewer in .NET Core 3.1.
Regards,
Todor
Progress Telerik
Rank 2
This is extraordinarily helpful! My sincerest thanks!
Just one thought on Azure and bitmaps. We are doing much graphical stuff in the Web App itself, with the Kendo UI for JQuery framework, and thus avoiding quite a bit of this issue. The other way we are working around it is by specifying a HD 1920*1080 screen as a reporting requirement, and thus avoiding the scaling issue. Not the greatest, but it seems to work.
We will stick with the standalone report designer. We would not give our users the ability to edit anything! :-)
For the future, I note that "Should you need to import your existing reports created with the Standalone Report Designer our recommendation is to use the TRDX|TRDP converter available in the Import Report Wizard. The result will be a class inheriting Telerik.Reporting.Report, that can be loaded in Visual Studio Report Designer.". That looks just fine to me.
Donna Kelly
Hello Donna,
Thank you for the update. I am so glad I managed to help.
Thank you also for sharing your workarounds related to Azure limitations with our community. Hopefully, other users will benefit from this information.