The Reporting Services add-in adds specific configuration and administrative settings for each of the Reporting Services content types—the Report file (.RDL), the Report Model file (.SMDL), and the Report Data Source (.RSDS)—which are accessible from a contextual drop-down menu against each respective Reporting Services content type stored within SharePoint document libraries.
Note
Reporting Services content type contextual menus are security trimmed, and only end-users with the member/contributor role and higher will see some or all configuration options relating to the administration of each content type. The exception is the Report Viewer Web part toolbar, explained earlier. For general information on securing Reporting Services reports, see the end of this section.
Next, we will list the configuration and administrative settings for each content type, along with considerations for security configuration of each type.
The Reporting Services data source file is the source from which the report model and actual report will be based. The data source identifies the data source type, such as SQL Server, and comprises a data source connection string and the credentials that will be used by the Report Server to access the data source when generating reports based on that data source. The configuration options available for a Reporting Services data source are shown in Figure 19-11.
The View Dependent Items option will display both the site and document library location of any reports or report models related to the data source, while the Edit Data Source Definition option allows modifications to the data source type and data source credentials.
The most important consideration in configuring a data source is the credentials, which will be used by Reporting Services to access the data source when running reports and report models, as shown in Figure 19-12.
The credential settings applied to a data source will depend on how you’ve configured Reporting Services, specifically, the authentication mode you’ve chosen within the Manage Integration Settings section of the Reporting Services settings contained within SharePoint Central Administration, Application Management, either Trusted Account or Windows Authentication. In our environment, we configured the authentication mode as Windows Authentication and then found we needed to use stored credentials for our data source connections throughout SharePoint document libraries. If we had configured the authentication mode as Trusted Account, where Kerberos was fully enabled throughout the server environment, then the two options—Windows Authentication (Integrated) and Unattended Report Process Account—would be an alternative.
Report Model Configuration
The report model is based on a data source. A data source can have many models, but each model can have only one data source. Reports are created from the report model. At least one report model must exist within a SharePoint site before reports can be created with the SQL Server 2005 Reporting Services Report Builder. A report model can have many reports. A report model can determine exactly the items made available for creating a report, such as particular tables and fields within a database, and can be secured using the Manage Model Item Security option in the Report Model configuration options shown in Figure 19-13.
Note
For further information on creating report models, see "Developing a Report Model and Designing a Report Builder Report" at http://channel9.msdn.com/ShowPost.aspx?PostID=365619.
The Manage Model Item Security option enables an administrator to lock down individual model items to specific users and/or groups of users. In other words, the data source defines a database, whereas the model tailors items within the database. This option limits the type of reports end-users can create based on their permission to each of the secured model items. For example, you may choose to allow only users within the Sales Group access to create reports against the Customer table. Figure 19-14 shows the Model Item Security page for the Adventure Works DW data source connection where access to the Dim Customer has been locked down. Other users accessing the Adventure Works DW model will not see the Dim Customer item and will not be able to create reports against that item.
Permissions on the report model in entirety can be managed by selecting Manage Permissions. For instance, you may want to limit who can create reports based on the overall model. End-users who do not have access to a report model will not be able to view that report model when creating new reports.
The Load In Report Builder option will launch the SQL Server 2005 Reporting Services Report Builder to create a new report based on the current report model. Clickthrough reports relate to Reporting Services drillthrough reports. For details on how to create a drillthrough report, see http://msdn2.microsoft.com/en-us/library/aa337439.aspx. The Regenerate Model option is used where the source database schema has been modified. If this is the case, the model will need to be regenerated to view and access changes.
Reports are created from a report model. In SharePoint Integrated mode in combination with the Reporting Services add-in, reports can be created and deployed to SharePoint sites using either Visual Studio 2005 or the SQL Server 2005 Reporting Services Report Builder, which is directly launched from SharePoint document libraries. Figure 19-15 shows the configuration options available for reports stored in SharePoint document libraries.
Figure 19-15. Configuration options for a Reporting Services report stored in a SharePoint document library
The Edit option in Report Builder will launch the report in SQL Server 2005 Reporting Services Report Builder. However, if the report has been created in Visual Studio 2005 and deployed to a SharePoint document library, then you cannot edit that report in Report Builder, even though Report Builder will attempt to open it.
The View Report History option is invaluable. It allows you to view a copy of a report at a given point in time. Snapshots can be taken of reports either manually or automatically based on a schedule, which can be configured under Manage Processing Options.
Note
We recommend you set up scheduling for report history, especially where multiple users are editing reports and making changes. The history will provide you with a way to roll back and/or check cumulative changes in the case of errors or issues with existing reports.
The Manage Processing Options page, shown in Figure 19-16, also allow you to configure the data refresh options, such as Use Live Data, Cached Data, or Snapshot Data. Consider the size of reports throughout your SharePoint deployment and bandwidth limitations. For instance, if you are running a global deployment where end-users are browsing reports from remote parts of the world and have multiple page reports, you may want to consider leveraging the Cached Data or Snapshot Data refresh options. You could configure a schedule for report snapshots each day, or twice per day, depending on the update frequency of the report data (data source).
Note
When moving Reporting Services reports between SharePoint document libraries, remember that you will need to resurrect the report’s data source link, ensuring that the report can find its associated data source at the original location. Another consideration when moving reports is the associated report history (snapshot) files. You will need to determine whether to leave snapshots in the original location or move them, but you will also need to check that any snapshots can locate their original data sources.