Reporting Service Internals
Was this helpful?
Was this helpful?
Report rendering is performed using . To maintain compatibility with .NET Core the Report Viewer control is executed in a external service that must be hosted in a computer running the full .NET Framework.
When the application requires rendering a report, it contacts the report rendering services. This service receives the definition of the report (Using RDL format) and the data of the report returning a PDF file (in an array of bytes) with the result of rendering the report.
The following diagram shows the main flow of the Report service execution:
In the ReportWatcher project exists the WFC service where every report's information should be processed to generate the report output file. The main execution of a processing report starts in the method named as ProcessReport, this method requires the following parameters:
Report: this parameter represents the RDL xml file serialized to bytes, then this array must be compatible to be converted to a MemoryStream.
Subreports: each key item from this dictionary should represents the name of the subreport and the value should be the serialized RDL file to bytes.
ReportInfo: represents a serialized xml file. Where all information related to metadata in the report is stored. The following information should be stored: the report name, the name of the datafile, the subreports name and corresponding names of tables associated to a subreport.
DataSet: a serialized xml file that contains the definition of the data belonging to the report and subreports.
This class contains in memory, all needed information to process a report from the RDL xml file to the expected PDF file. Various data structures such as Streams, Dictionaries and DataSet are used as storages while a report is being processed, so the size of those structures could be considerable.
In this method, the main goal is orchestrate all necessary components to generate a PDF file from the Report Builder dependency. Currently, this method is invoked from the class ReportService.svc, then every needed field is transformed in this previous execution.
This method is in charge of defining the event Rep_SubreportProcessing in the Report Builder, this event is triggered when this dependency needs data related to a corresponding subreport. Here, all data from the main data set is filtered to show only the subreport's information according the parameters. As an important mention, a DataSet is compound by different tables, and if the table contains a column named as "subReportKey", it means that this table belongs to a subreport.
This static class wraps all interaction with the external dependency of Report Builder. Mainly, here you can find common code to generated a report from this dependency.
AddData: resolves the table in the dataset belonging to the main report. Also tables related to DropDowns are resolved here.
RenderReport: call to the external reference of ReportBuilder to create a PDF file.
GetSubReports: this method resolves the following information related to subreports, the name of the RDL xml file, the name of the subreport and the name of the tables in the dataset referenced.
The Following steps shows how to install a report rendering service with your migrated application:
Start your Report Rendering Service and ensure that it can be reached through the following URL form: http://<[ip or hostName]:[port]>/ ReportService.svc, for example http://localhost:5011/ReportService.svc
Inject a singleton instance of ReportServiceConnection to your migrated application services at StartUp.cs. Please, ensure pass by constructor parameter the previous tested URL. See the following example related to this step:
You can start your migrated application from console and indicate the report rendering’s URL, just by executing the following command: dotnet run –reportService=URL, where your migrated solution site is located. All binaries for Report Rendering can be found on Mobilize repositories.