This chapter is from the book
This chapter is from the book
This chapter is from the book
The Report Manager
So far we've given an overview of designing reports and deployment to a Report Server. We've said little about how these deployed reports can be managed while in the Report Server, nor how a user might choose a report to run. Well, to do this Microsoft provides a Report Manager ASP.NET web application. The Report Manager provides an attractive interface that acts as a wrapper to the URL calls and SOAP methods of the Report Server.
The Report Manager can be accessed on its default URL of http/https://<server>/Reports. What users see rendered in their web browsers depends on the security permissions they have been assigned; reassuringly, users can perform administrative functions only if they have Administrative privileges. In Chapter 4 we'll discuss Report Manager security and explain how to setup Administrative and User account roles. The Report Manager really comes into its own as a user application that enables users to choose from and execute the managed reports that they have permissions to access.
Managing Security Permissions
The Reporting Services security permissions system is extensive and is based on assigning roles to Windows domain, local machine user, or group accounts. Here's how it works. At the lowest level of granularity, the various tasks that can be performed are identified, and these tasks can be aggregated into various defined roles by an Administrator or someone with appropriate privileges.
Out of the box there are four defined roles—Browser, Content Manager, My Reports, and Publisher—providing permissions very much along the lines of what their names imply. Because these roles are constructed from a selectable list of task operations that can be performed, it is possible to define new roles consisting of different subsets of tasks. Keep in mind that by default ordinary users have no rights; only those who have Administrator rights can access these roles unless you modify the permissions for your selected accounts.
Managing Folders
As mentioned earlier, the Report Server maintains managed reports and shared Data Sources in notional folders, and the Report Manager lets users navigate these folders. Depending on security permissions, the person browsing can create new folders and can delete, move, hide, rename, and edit the descriptions of folders or reports. Of course, if the person browsing doesn't have permission to see a report or folder, then it isn't visible when the user views the Report Manager. In addition, it is possible to set permissions for users and configure the Report Server to maintain folders on a per-user basis on a model similar to the My Documents folder on the Windows file system. This model enables users to have their own My Reports folders for their own reports (independent of other users) that they alone can see.
Managing Shared Data Sources
Subject to permissions, any shared Data Sources can be managed by a user through the Report Manager. Users can change credentials and Connection strings in the Data Sources on a live Report Server without invoking a development tool.
Managing Linked Reports
One of the cool Report Server features that the Report Manager exposes is the ability to create, name, delete, and manage linked reports. This is a report description that doesn't have any RDL of its own. The concept here is very similar to the way a shortcut operates in the Windows file system. The Report Manager enables linked reports to have different default values, different visibility for parameters, and different security than those of the underlying report to which they are linked, and it provides a placeholder for a user to execute. Alas, for a linked report, it is not possible to establish Data Sources or credentials that differ from the ones used by the real underlying report. Now that would be interesting.
Managing Shared Schedules
We have referred to schedules several times in different contexts. The Report Manager provides a mechanism for creating system-wide schedules that can be shared wherever a schedule can be used and can be managed from a central point.
Managing the Cache, Snapshots, History, and Report Execution Timeout
When we discussed the Report Server, we mentioned caching Snapshots and creating historic Snapshots. Yes, you can use the Report Server SOAP interface to configure these, but you'll probably be relieved to know that the Report Manager provides a UI wrapper around the SOAP interface to let you easily configure these and many other features without needing to resort to programming.
At the site level, someone with Administrator privileges can create defaults using the Report Manager to set the maximum execution time in seconds that a server should spend rendering each report before it decides to abandon it and return a message to the user. This site default can also be overridden on each report.
Subscriptions
Users with the requisite permissions can subscribe to managed reports using the Report Manager. This means that selected users can configure a managed report to be delivered to them via one of the installed Delivery extensions (such as Report Server File Share) or by e-mail on a personal or a shared schedule. With additional permissions a user can configure a data-driven subscription, where configuration information and distribution lists can be derived from a query on a table.
Help
All the pages that constitute the Report Manager have context URL links to HTML help pages. If the Report Manager is going to be deployed in the default location where users select and execute reports, it is reassuring to know that an out-of-the-box help system is provided. If you are going to build your own report management system, you'll need to budget time to explain how it works and possibly provide your own online help system.
Extending the Report Manager
The Report Manager is intended to be a closed, black-box solution. Because of this Microsoft has not released the source code. In our opinion, the Report Manager is a delightful application, but there are some rough edges that you may find that you want to smooth out. In this respect, not all the settings that one might like to adjust from the Report Manager are provided. Although some of these may be added at a later stage, at the moment a System Administrator may have to delicately futz around with the XML-like configuration files or find a custom application that does it. Another irritation that comes to mind is that there is very little control over the layout of the ASP.NET controls that are used to collect the parameters in a report.
Microsoft's official position is that you should make your own Report Manager if you don't like the way the Report Manager works. To some extent, Microsoft helps by providing some sample starter applications. The problem is that it's a heck of a lot of work to build all the functionality that the Report Manager application provides when you want to add only a few bells and whistles.
Well, because we are not on the red pill we spoke of earlier, we can be mischievous and tell you how to pry open the Report Manager black box and provide the degree of customization you might want. This certainly takes much less effort than creating a whole Report Manager application. Of course this approach is hostage to Microsoft changing things, as it is at liberty to do in the future. However, the approach we'll show you in Chapter 11 enables you to make easy modifications now, and if Microsoft comes back and breaks your toys later (as we told you it might), at least you'll be able to incorporate them into your own Report Manager should you be forced to build one.