Security
The reporting platform you choose must meet your organization's security requirements, and you must be able to implement and maintain the security solution with a reasonable amount of effort. Every organization has its own specific report-security requirements, but most security needs fall into two categories: report security and data security. Report security defines which users or user groups can access which reports. Data security protects the data that populates those reports. Of the two security types, data security is often more complex and more difficult to administer.
For report security, Crystal Enterprise supports multiple security models, including table-based Lightweight Directory Access Protocol (LDAP) and Windows NT. Reporting Services uses a role-based model in which user roles control access to reports and data. User roles are associated with one or more Windows users or groups. All other security models in Reporting Services require the development of custom security extensions. Security extensions are essentially custom modules that integrate with file- or session-based authentication schemas that provide a UID to the Report Server. This UID interacts with the defined roles in the same way as it interacts with Windows users.
In both platforms, data security is part of report design rather than report administration. By using either the Windows UID or the UID passed in from an alternative security system, you can include in the data-source query a filter based on the data set available to the current user. This feature raises a couple of interesting points. First, for organizations generating reports for large numbers of non-Windows users (e.g., clients or vendors), an anonymous or group user authentication might seem a good strategy for report security but might become a data-security problem. The reporting platform can't effectively filter data unless all members of the shared UID have access to identical data sets. Second, each reporting platform offers data filtering at two levels: data source and data set. Data-source filtering defines the population of the report query (e.g., the data that makes up the query result set). Data-set filtering occurs after the query executes and returns a subset of the query data. Thus, you can generate multiple UID-specific reports from one common query, resulting in less query traffic to the database and potentially significant performance gains. Regardless of which platform you use, the ability to manage access to data is essential to security as well as performance. Although the specific security implementations are different in Crystal Enterprise and Reporting Services, both platforms support these security functions.
Administration
In Reporting Services, Microsoft includes the Report Manager interface for access to administrative tasks such as data-source management, report security, subscription management, and scheduling. Data-source management includes the ability to edit data-source connection definitions for all reports that you deploy to the server. Maintaining the data-source connection definition in the administrative environment rather than the development environment creates a level of abstraction between the report-designer and report-administrator roles. This abstraction lets the report developer work independently of the production environment, relieving potential security and deployment management concerns. Data-source management also includes the ability to define shared data sources that allow for single-point management of data connections across several reports. Figure 1 shows Reporting Services' report-administration interface.
By using native Windows security integration or a custom security extension, Reporting Services' report security lets the report administrator grant or deny users or user groups access to individual reports or report groups. Subscriptions in Reporting Services let you schedule report delivery to email recipients or as files delivered to file shares. And the subscription functionality supports the use of parameters to target the report data to specific users' needs. When you deliver reports by email, you can send them as hyperlinks or as fully generated reports. In addition, Report Manager functionality is exposed in the Web service API, which means you can develop a fully customized management interface.
Administration of Crystal Enterprise reports reflects the product's more complex architecture. The primary interface to report administration is the Management Console, which Figure 2 shows. However, access to some of the platform's important functionality is available only through the module utility interfaces for specific capabilities. For example, a scheduling utility supports report scheduling, and a configuration utility provides access to Crystal Enterprise servers and server components. Like Reporting Services, Crystal Enterprise can deliver reports based on events or a calendar schedule. Also like Reporting Services, Crystal Enterprise lets users who have appropriate permissions schedule their own reports.
Monitoring Performance and Usage
Small organizations, particularly those that need reports primarily for internal use, can dedicate relatively less energy to tracking and tuning reporting performance than larger organizations that might need to generate reports for people outside the organization. Although smaller organizations can monitor performance by communicating directly with the handful of users who receive reports, larger organizations might have hundreds or thousands of reporting users. To monitor and optimize performance across a community of this size, you need an effective system for monitoring report performance with good tools for administering the reporting platform.
The Crystal Enterprise Management Console is a Web-based tool that gives report administrators access to most server objects (e.g., users, groups, reports) as well as some monitoring of report-usage metrics such as query frequency, duration, and execution time and date. The level of detail available in the Management Console isn't as granular as some administrators might like, but you can add detail by using the administration API to customize the report. For most organizations, Crystal Enterprise's out-of-the-box monitoring capabilities are adequate, and for those who need extended capabilities, the supplied capabilities are a good place to start.
Reporting Services doesn't currently ship with a monitoring capability that's sufficient to satisfy many organizations' needs. As with other Reporting Services functionality, you can develop a custom application for performance monitoring. To understand how to create a historical monitor of report-execution activity, you can start with the collection of SQL scripts and the Data Transformation Services (DTS) package that Microsoft supplies on the SQL Server CD-ROM in the \Microsoft SQL Server\80\Tools\Reporting Services\ExecutionLog folder.
Choosing Wisely
So which of these reporting platforms is better? The answer is a resounding, "It depends." Both platforms are viable solutions to most organizations' reporting needs. The only "show-stopping" difference is that organizations that require the report server to run on a non-Windows server can't use Reporting Services.
Aside from the OS requirement, choosing the right platform comes down to evaluating your organization's reporting needs and strategies against the relative strengths and weaknesses of each platform. Crystal Enterprise is a more mature product and provides more business-userfriendly features. But the trade-off for this user-friendliness comes at the cost of customization and control capabilities that hard-core report designers strongly desire. Reporting Services provides excellent customization and extensibility but at less than a year old, it's the less mature product and is a "build-it-yourself" environment that requires more initial investment in the redeployment effort as designers learn the technology and build replacement reports that users will accept.
The initial cost of licensing Crystal Enterprise is significantly higher than that of Reporting Services. However, depending on how you count it, the Crystal installation base is huge—typically somewhere near 20 percent of all reporting and analysis applications—so it's likely that a Business Objects license of some kind is already in place in most midsize to large organizations. Although this fact doesn't necessarily translate into reduced licensing costs, significant savings are available to organizations that are simply upgrading from earlier releases. An equally important consideration is the cost of retraining and retooling. Changing platforms can be quite expensive, so you need to figure out the time required to recover your investment. Even given its large lead, however, Business Objects has to be concerned about the continued market share growth of Microsoft's SQL Server suite. Microsoft's product positioning—bundling Reporting Services, DTS, and Analysis Services as part of the SQL Server license—makes every company using SQL Server a potential Reporting Services client. Meeting reporting needs without purchasing any additional licensing is a compelling option that will be more compelling as Reporting Services' capabilities mature.
Neither Microsoft nor Business Objects is likely to sit on its platform laurels, and although both companies continually restate their commitment to cooperation, it's clear that competition for the reporting-platform space will drive future releases of these products toward better feature sets. Business Objects owns the reporting-solutions space today, but Microsoft's use of common components in Reporting Services should let the company quickly build functionality or integrate third-party capabilities that will make higher-cost solutions hard to justify.
End of Article
Prev. page
1
[2]
next page -->
