System Settings → Report Templates → Custom Reports → Reporting Services Architecture
Reporting Services Architecture
In order to understand the reporting environment, it is important to understand the interaction between the Report Viewer (users of reports), the application and the Report Server. The visual below shows how reporting works. For the remainder of this document, we will refer to the server that has Reporting Services and reports data as the Report Server.
- The application communicates with Report Server to retrieve reports catalog (what reports are available) and report templates (what the report is designed to do). This communication takes place over a Web service. This interaction takes place every time a user is creating new report instances.
- Report Viewer interacts with report Server to view report instances. This is done over HTTP/HTTPS.
- The Report Writer interacts with the Report Server to deploy reports.
- An administrator interacts with the Report Server to manage content and access.
- Report Server communicates with data via a custom OLE DB to get the data for the reports.
Usually, the flow of events for reporting is as follows:
- The user logs on and navigates to the Reports view.
- The user clicks to create a report. The Web server queries the Reports server for available report templates.
- The user clicks to view a report instance. If applicable, a request is made for report parameters.
- SQL Reporting Services passes parameters, and then collects the data.
- SQL Reporting Services renders the report instance.
- The user can re-configure parameters and view report again. If a user schedules reports, the parameters are stored. The Scheduler service initiates rendering of the report and then stores the scheduled report instance in the Documents Manager.
- Report Writer posts additional reports. The Administrator manages content or access.
Copyright © 2003–2010 Serena Software, Inc. All rights reserved.