Bryan's Blog : Reporting Services

Using an External DataSet with Reporting Services Reports

bryanke — Tue, 14 Sep 2004 00:54:00 GMT

A colleague of mine working at the SQL Server Developer Center has written a short article on Reporting Services and DataSet data processing. You can view it here:

http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-us/dnsql2k/html/rsdsetex3.asp

Writing Custom Code for Reporting Services Reports

bryanke — Tue, 14 Sep 2004 00:45:00 GMT

Teo Lachev has published a partial chapter of his new book "Microsoft Reporting Services in Action" to the Microsoft Developer Network (MSDN) online. The excerpt comes complete with sample code available as a download. Special thanks to Teo and to Manning Publication for allowing this content to be made available to Reporting Services customers.

Read the article here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/ERSCstCode.asp?frame=true

GetReportParameters method

bryanke — Thu, 29 Jul 2004 18:05:00 GMT

I stumbled across this short article on using the Reporting Services SOAP API to retrieve parameter information for a report by K. Scott Allen. Visit http://odetocode.com/Articles/123.aspx

Welcome Tudor to Reporting Services Blogging

bryanke — Thu, 15 Jul 2004 02:26:00 GMT

Just wanted to let you know that Tudor has started a Reporting Services blog. As some of you may know, Tudor is the lead developer for the Reporting Services product and thereby an instrumental part of its design and development. His first post on Measuring and Improving Performance is worth a read.

Reporting Services Service Pack 1 Now Available!

bryanke — Wed, 23 Jun 2004 17:05:00 GMT

SP1 of Reporting Services can be downloaded from the following site:

http://www.microsoft.com/downloads/details.aspx?FamilyId=580FEBF7-2972-40E7-BCCF-6CD90AC2F464&displaylang=en

It contains the following new enhancements and fixes:

Excel rendering extension has been improved and now supports viewing in Excel 97 and 2000.
PDF rendering extension is more robust and has better performance.
Chart control provides more control over display styles.
References to external URLs (images and resources) from within a report are now supported.
Data caching behavior for report preview is now supported.
Newline in expressions is now supported.
The style of the HTML Viewer toolbar can now be modified through a style sheet.
New URL parameters offer more options for customizing report presentation at run time
Report Manager proxy persists authentication cookies so that they can be used by custom security extensions.
Hidden parameters are now supported.
Temporary snapshots can be compressed as well as stored on the file system.
Integrated security support for accessing report data sources can be disabled.

The Readme file is a good place to start to get the latest, in-depth info on the above improvements (okay, I know nobody reads the readme, but I'm a doc guy and I have to plug it, and it will seriously be worth your time if you are interested in any of the SP1 enhancements).

Reporting Services WebParts - Walkthrough

bryanke — Fri, 28 May 2004 01:25:00 GMT

Check out Bryant Likes' blog for a nice walkthrough on setting up Reporting Services WebParts for SharePoint.

Clarification on the Placement of CodeGroup Elements for Extensions

bryanke — Fri, 14 May 2004 18:15:00 GMT

Well, I've been away for a while, lots of stuff going on at work and home. The next series of posts are going to be related to corrections and/or updates to Reporting Services Programming documentation. The first subject I would like to cover is the placement of CodeGroup elements when granting permissions to external components (extensions and custom assemblies) in Reporting Services. Books Online is not specific about the placement of code group entries for extensions or custom assemblies. The placement of CodeGroup elements in a security policy file is important. For extensions and custom assemblies that you develop, it is recommended that you place your custom code groups directly below the existing entry for the URL membership "$CodeGen$/*", as indicated by the following:

Additional code groups can be added one after another.

You've just installed Reporting Services, now back up that encryption key!

bryanke — Thu, 18 Mar 2004 17:58:00 GMT

I presented some demos at this year's PASS (Professional Association of SQL Server) Community Summit on how to use the rskeymgmt utility in Reporting Services. This is a crucial tool and should be used after every Reporting Services installation. What is it good for? Well, it can do several things, least of which is to extract and store the symmetric keys used to encrypt data in the report server database or catalog. This tool captures the complete key set that is defined during setup, and stores it as a file that you can save to disk or to removable storage media. You will absolutely need this key at some point if the account that is used for the ReportServer Windows service changes in some way (if a password is changed for instance) or if you want to connect a new report server to an existing report server database instance. Without the ability to apply this key at a later date to a report server instance, you may be forced to delete all encrypted data in your catalog including data source and user information. The rskeymgmt utility can help with that as well, but this shouldn't be necessary as long as you back up the key. The key is an integral part of storing encrypted data. If, at some point, the encryption key for the report server instance is different from the key used to store encrypted content in the database (i.e. a new report server installation, but an existing catalog), you report server will not function properly. So, bottom line, store your encryption key on a floppy disk for safe keeping using rskeymgmt. You can read the specifics about the tool on MSDN here.

Sample Script for Setting Item-level Security in Reporting Services

bryanke — Thu, 18 Mar 2004 06:26:00 GMT

Report Manager is a solid, Web-based administrative tool for Reporting Services, but it is not the end-all-be-all of administrative functionality for a report server. There are many capabilities available through the Web service that Report Manager does not take advantage of. Case in point: Setting a security policy (otherwise known as a role assignment) for an item using Report Manager is a bit cumbersome, especially if the item for which you want to add a policy is nested several folders deep in your report server namespace. Let's take an example. Let's say you have a folder at “/Budgets/Finance” and you would like to give Bob permission to view reports in the Finance folder. You add a new role assignment for Bob and make him a Browser user of the Finance folder. Bob logs into Report Manager hoping to navigate to the Finance folder, but...Bob is not able to see any folders when he logs in. What gives? Well, unfortunately the path to Bob's Finance folder actually contains three items: The Home or root folder (”/”), the Budgets folder and the Finance folder. Because Bob is not allowed to view the root folder or the Budgets folder, he will never see the Finance folder for which he has permissions. Sorry Bob. In order to give Bob Browser permissions on the Finance folder, you must add Bob as a Browser of both the Home and Budgets folders. If you need to add more groups or users to the Finance folder, it can get downright tiresome. Oh, did I mention that every time you add a policy for Bob to one of the folders, the inherited policy is broken. Yes, that means that any users that enjoyed inherited permissions to those items (for example BUILTIN\Administrators or some other administrator group) no longer have any access rights. You will have to re-add inherited permissions as local policies on each of the three folders in our example. Yikes. Fortunately for Bob, Reporting Services offers rs.exe, a scripting utility with complete access to the Reporting Services Web service. You can use this scripting tool to automate certain tasks and to perform administrative functions that may not be easily automated through Report Manager.

The following sample script can be used to add a security policy for a nested folder or report which automatically gives the user permissions up the namespace tree. After using this script, the item is immediately accessible to the user. In addition, you can use this script to keep or delete the current set of policies for the item, including inherited ones. I haven't given the script the whole battery of tests yet, so if you play around with the code, try it on your test server only. If you find any problems or issues, let me know.

'=====================================================================

' File: AddItemSecurity.rss

' Summary: Demonstrates a script that can be used with RS.exe to

' set security on an item in Reporting Services.

'---------------------------------------------------------------------

' THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY

' KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE

' IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A

' PARTICULAR PURPOSE.

'=====================================================================*/

' Variables that are passed on the command line with the -v switch:

' userName - the name of the user for which to add a policy

' roleName - the name of the role to apply for the user (i.e. Browser, Content Manager)

' itemPath - the path of the item for which you want to add the policy (i.e. /SampleReports)

' keepCurrentPolicy - whether to keep the current policy and add the new one

' Sample command line:

' rs -i AddItemSecurity.rss -s http://localhost/reportserver -v userName="MyTestUser"

' -v roleName="Browser" -v itemPath="/SampleReports" -v keepCurrentPolicy="True"

Public Sub Main()

Dim isRoot As Boolean = False

Dim inheritParent As Boolean

Dim policies() As Policy

Dim newPolicies() As Policy

Dim policy As New Policy()

Dim roles(0) As Role

roles(0) = New Role()

roles(0).Name = roleName

policy.Roles = roles

policy.GroupUserName = userName

While Not isRoot

' Once the root of the catalog is reached,

' stop applying policies

If itemPath = "/" Then

isRoot = True

End If

policies = rs.GetPolicies(itemPath, inheritParent)

' If the user selects not to keep inherited or current policy,

' empty the policy

If Not keepCurrentPolicy = "True" Then

policies = Nothing

End If

newPolicies = AddNewPolicy(policy, policies)

rs.SetPolicies(itemPath, newPolicies)

itemPath = GetParentPath(itemPath)

End While

Console.WriteLine("Policy successfully set.")

End Sub 'Main

' Method to parse the path of an item and retrieve

' the parent path of an item

Private Function GetParentPath(currentPath As String) As String

Dim delimiter As String = "/"

Dim rx As New System.Text.RegularExpressions.Regex(delimiter)

Dim childPath As String() = rx.Split(currentPath)

Dim parentLength As Integer = childPath.Length - 1

Dim parentPath(parentLength) As String

Dim i As Integer

For i = 0 To parentLength - 1

parentPath(i) = childPath(i)

Next i

If parentPath.Length = 1 Then

Return "/"

Else

Return String.Join("/", parentPath)

End If

End Function 'GetParentPath

' Takes the policy to add and applies it to the current set

' of policies if applicable

Private Function AddNewPolicy(policyToAdd As Policy, policies() As Policy) As Policy()

If Not (policies Is Nothing) Then

Dim policy As Policy

For Each policy In policies

If policy.GroupUserName = policyToAdd.GroupUserName Then

Throw New Exception("The supplied User policy already exists for the item.")

End If

Next policy

Dim list As New System.Collections.ArrayList(policies)

list.Add(policyToAdd)

Return CType(list.ToArray(GetType(Policy)), Policy())

Else

policies = New Policy(0) {}

policies(0) = policyToAdd

Return policies

End If

End Function 'AddNewPolicy

How hard is it to write Reporting Services extensions?

bryanke — Tue, 16 Mar 2004 23:38:00 GMT

Obviously the answer to this question is fraught with conditions and dependencies. In general terms, this would be my answer (from easiest to most difficult):

Data Processing Extensions: Built on the same framework as ADO.NET, a Reporting Services data processing extension models .NET data providers in many ways. They are fairly straight forward to build and because they are based on .NET data providers, there is ample documentation and resources to support them. Obviously, you can make it as complex and powerful as you want, but as a rule, they are not hard to build. The documentation for Reporting Services includes a sample, however, that sample does not cover the use of data extensions that handle parameters. This is the only area where it gets confusing. Hopefully we will include a more comprehensive sample in the future. Developers with some experience with ADO.NET and .NET data providers should be well on their way to implementing a data processing extension.

Delivery Extensions: Unique to Reporting Services, delivery extensions can appear a bit overwhelming at first, but they really are simple once you get down to it. A delivery extension supports extension settings, which are used to drive subscriptions to reports. In addition, developers must implement the Deliver method which actually handles delivering the notification. Once again, there is a sample available with the Reporting Services documentation which should give you an idea of what they are all about. If you follow the sample and its logic, you should be able to write a delivery extension of your choosing with little or no problem. Once again, it can be as complex and feature-rich as you need it to be.

Security Extensions: Unique to Reporting Services, but based on technologies that ASP.NET developers should be familiar with, security extensions present a unique challenge. The difficulty does not lie in developing or understanding them, but in deciding when and how to use them. In addition, they are hard to deploy. Deploying a security extension touches just about every configuration file imaginable. The Reporting Services team is close to releasing a technical article and comprehensive sample that should shed some light on these types of extensions. Currently, the only type of security extension that has been written or conceived of is a Forms Authentication extension, which provides Forms-based ASP.NET authentication and then models Windows authorization. Security extensions are for intermediate to advanced developers with knowledge in ASP.NET Security, Forms Authentication and role-based security concepts.

Rendering Extensions: Also unique to Reporting Services, rendering extensions are the most difficult of the extensions to develop. Even the most talented developer will find rendering extensions a bit overwhelming. The difficulty lies in the understanding of the report object model and the sheer number of APIs. If you want to develop one, it might help to travel to Microsoft's main campus and stay for a month or two while you work alongside Reporting Services developers. There is no documentation and there are no samples available yet. An alternative to writing a rendering extension might be to first render to XML and then apply an XSLT or simply live with the rendering extensions that Microsoft provides (new ones are in the works). These aren't impossible to write by any stretch of the imagination and many third party developers are getting up to speed. It will definitely help when we release an official version of the rendering extension documentation. Just be prepared for a tough road ahead when developing these suckers.

Impersonate in Reporting Services ASP.NET Web Clients

bryanke — Wed, 03 Mar 2004 18:06:00 GMT

This issue comes up quite often with users who are building client Web applications that use the Reporting Services Web service. When you develop ASP.NET client applications that generate a Web service proxy, you can authenticate the current user to the Web service in your code. However, in ASP.NET, impersonation is turned off by default. This means that when you run your client application using integrated security, regardless of the current user, your client accesses the report server using the ASPNET account (for example NT AUTHORITY\NETWORK SERVICE under Windows 2003). This is not a very privileged user in Reporting Services (for good reason). You will need to enable impersonation in your Web application. The easiest way to do this is to modify the Web.config file for your client app. Simply add the following line within the <system.web> configuration element:

Accessing a Report Server Using a URL POST Request

bryanke — Sun, 15 Feb 2004 01:56:00 GMT

If anyone is interested in a simple example of how to access a report server using a form post action, you can check out a short article here.

Documenting a SOAP API: The Reporting Services Web service

bryanke — Thu, 12 Feb 2004 23:34:00 GMT

I'm often asked, especially by those developing Reporting Services' Web service clients using straight SOAP messages, why the decision was made to document the Reporting Services Web service methods from the syntactical perspective of the .NET languages VB and C#. There are several reasons for this. Early on, we had planned to include XML representations of each Web service operation as it would appear in a SOAP message, but the cost of maintaining such documentation was high, especially as the product was in the early stages of development. We found that most of our customers, integrating reports into applications using the Web service, were .NET shops using primarily Microsoft development technology. It made sense to offer documentation and samples that supported their development efforts. Another reason was precedence. At the time, Reporting Services was just one of two Microsoft products with a complete, published Web service interface; the other being Mappoint .NET. We studied the Mappoint method of Web service documentation and wanted to be consistent, while at the same time, making sure that our customers would have the information they needed to be successful. Mappoint laid a strong foundation for Web service documentation and we wanted to follow suit. As stated previously, we expect that the majority of developers of Web service clients in Reporting Services will be working with Visual Studio and the .NET Framework. That is our primary development scenario for this release even though that Reporting Services WSDL is W3C compliant and adheres to the standards of that organization. In the future, we may look to include a "SOAP syntax" section along with each method topic, but that is not high on the documentation priority list. We do have some customers using non-.NET languages such as Delphi and Cold Fusion who at times struggle to get the right SOAP syntax. For those who need some help, here are a few tips:

1. If an argument to a Web service method is optional, leave the element out of the message entirely. Many of the samples that ship with the product pass null values for optional input parameters. This is required when you use a .NET proxy. This has the same affect as leaving the element out of the SOAP message completely.

2. If your development kit comes with a SOAP trace provider, use it. You can write .NET samples such as the ones found in Books Online and then run a trace on your report server to view the SOAP representation of calling certain methods. This is acceptable only in a development environment of course.

3. In languages, such as Delphi, that do not support passing null values for string parameters, you may be required to work with SOAP messages directly. You may not be able to access some Web service operations with a proxy object.

Okay, as usual, if you have comments on Web service documentation, what you like and don't like, feel free to let me know.

Printing Reports in Reporting Services

bryanke — Wed, 11 Feb 2004 22:13:00 GMT

Reporting Services brings a lot of new and exciting features to the BI marketplace as a version one reporting tool. The programmatic interfaces as well as the extensibility architecture allow for a lot of features to be added by third-party developers. One question that I get from customers is if Reporting Services supports some kind of client- or server-side printing control that enables users to print reports with a single button click directly from the HTML viewer. This feature was not automatically built into the product in favor of focusing more on nailing down some of the other core features. Never fear, Reporting Services supports automatic exporting of reports to two, pixel perfect formats: PDF and Image. Reporting Services also has plans to support both server and client direct printing in future versions. Still, there may be an instance when you might want to build programmatic printing of reports into your business application. For one possible solution, please visit my articles area and check out Printing Reports Programmatically Using C# and SQL Server 2000 Reporting Services.

Code Access Security and Custom Assemblies

bryanke — Tue, 10 Feb 2004 22:57:00 GMT

I've recently published a technical article that addresses the topic of code access security in Reporting Services. It also has some helpful tips and tricks regarding using custom assemblies in your report projects. You can find the article on MSDN at:

http://msdn.microsoft.com/library/?url=/library/en-us/dnsql2k/html/dngrfCodeAccessSecurityInSQLServer2000ReportingServices.asp?frame=true

This is a hot topic in Reporting Services, because the implementation of code access security and custom assemblies is dramatically different in the released version of Reporting Services from the Beta 2 version. This whitepaper should help give you the information you need in order to ramp up on the latest regarding these topics.