Friday, April 21, 2006
Reading and modifying the configuration of web parts from an external tool
The Web Part Infrastructure in ASP.NET 2 offers a very neat system that allows users to configure and personalize parts of a web page, dragging the web parts to their preferred position, etc... When you are administering a web site that works with web parts, you'll soon want to know how many of your users actually personalized their page. And what settings did they use? Surely, you can find this out by inspecting the personalization database? Wrong.
The personalization of all web parts in a web part page is stored in a binary field in the database. This field holds the position and configuration of all web parts on the page and also which extra parts a user may have added to her page. All this information is not readily available.
Last year, I wrote a post detailing how the WebPartManager stores its information in the personalization system and I created a small library that could be used to read and change the configuration of a page from code and without the ASP.NET context available. This was working with beta 2 of ASP.NET and sadly, the format of the storage later changed in anumber of very subtle ways, leaving the library broken.
I have now updated the library to work with the final release (it turned out to be difficult to have it work with both versions). It comes with a little sample program that shows how to read the binary info from the database, make a few changes and save it back to the database. This is the code of the sample program:
As you can see, I use a typed dataset and the automatically generated TableAdapter to load the byte array of configuration from the SQL Express database, then I create a PageState object with this data. In the PageState, I make two changes: I delete all dynamically added web parts from the page and I set the web part with ID Weather to the RightZone. Lastly, the updates are stored in the dataset and persisted to the database.
The library and sample program can be downloaded here. No warranties.
The personalization of all web parts in a web part page is stored in a binary field in the database. This field holds the position and configuration of all web parts on the page and also which extra parts a user may have added to her page. All this information is not readily available.
Last year, I wrote a post detailing how the WebPartManager stores its information in the personalization system and I created a small library that could be used to read and change the configuration of a page from code and without the ASP.NET context available. This was working with beta 2 of ASP.NET and sadly, the format of the storage later changed in anumber of very subtle ways, leaving the library broken.
I have now updated the library to work with the final release (it turned out to be difficult to have it work with both versions). It comes with a little sample program that shows how to read the binary info from the database, make a few changes and save it back to the database. This is the code of the sample program:
As you can see, I use a typed dataset and the automatically generated TableAdapter to load the byte array of configuration from the SQL Express database, then I create a PageState object with this data. In the PageState, I make two changes: I delete all dynamically added web parts from the page and I set the web part with ID Weather to the RightZone. Lastly, the updates are stored in the dataset and persisted to the database.
The library and sample program can be downloaded here. No warranties.
Labels: aspnet_webparts
Wednesday, April 19, 2006
Allowing blanks in the parameters of a report
In the new version of the SharePoint extension for Reporting Services, I added a feature that may need some explanation. All reports that use the extension will automatically have a parameter called SiteUrl. This parameter can be used to override the site URL that is configured in the connection string. If you leave the parameter blank, the value from the connection string will still be used. One problem: by default, reports will not allow blanks in their parameters.
In our organization, we create a standard teamsite to track information about the progress of projects. This teamsite includes numerous web parts that display a SSRS report using data from the current site. This means that these web parts will have to pass the URL of their source team site to the report server on the URL of the report. The most obvious way to do this is by having the extension automatically insert a parameter into the report to override the default site URL.
How to allow blanks for a parameter
To allow blanks for a parameter, open the report in Visual Studio and go to Report|Report Parameters dialog. This is the place where you can select the option "Allow blank value". You might also choose to hide the parameter if you don't want to bother the report users with this feature.
Why adding this parameter anyway?
Sometimes you want to report over data in one and only one team site. Think of a central site that is used to track current job applications. There, it is fine to have the URL of the site as part of the connection string. But in some cases, you want to have one report, but you want to use it on data from several sites. These will typically be sites that are created from a common Site Template.In our organization, we create a standard teamsite to track information about the progress of projects. This teamsite includes numerous web parts that display a SSRS report using data from the current site. This means that these web parts will have to pass the URL of their source team site to the report server on the URL of the report. The most obvious way to do this is by having the extension automatically insert a parameter into the report to override the default site URL.
Labels: reporting services
Using the SharePoint Lists extension on Reporting Services 2005
I'm back! Had a great time in Egypt, had a first rank look at the total solar eclipse on March 29th. I feel like going to work again....
So, let's start with something that has been requested a few times during my vacation: how about using the Reporting Services extension for SharePoint Lists on SSRS 2005? I received some reports from people that it didn't "just work", so I installed SSRS 2005 myself and gave it a try.
The bad news is that it seems to be impossible to use the old version of the extension on the new SSRS version. I don't know why, but I had to recompile the sources against the new framework and new interfaces library. Mind you: I did not change one line of code, just recompiled. The new binaries are available for download:
Old version for SQL2000 with source code
New version for SQL2005, only binaries (but the source is the same)
C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\bin
Note the folder MSSQL.4: the 4 indicates the SqlServer instance that is used by reporting services. With SQL2005, you will often have multiple instances. Look for the one containing the Reporting Services folder.
For the reporting server, you copy the binaries to:
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
This is a different location from the SQL2000 setup. In many development environments, you will have both the designer and the reporting server running on one machine. In these cases, you copy the binaries to both places.
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\RSReportDesigner.config
You have to add two lines to this file, one to the <Data> block and one to the <Designer> block. Here we show the result, but you have to add only the last lines of each block. For the server, you'll have to make and edit to the file
C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\rsreportserver.config
In this file, only the <Data> block needs to be modified (indentical to the change described above). The resulting block looks like this (the last line has been added):
C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\rssrvpolicy.config
With these setup steps, you should be ready to use SharePoint lists as the datasource for your reporting services reports.
So, let's start with something that has been requested a few times during my vacation: how about using the Reporting Services extension for SharePoint Lists on SSRS 2005? I received some reports from people that it didn't "just work", so I installed SSRS 2005 myself and gave it a try.
The bad news is that it seems to be impossible to use the old version of the extension on the new SSRS version. I don't know why, but I had to recompile the sources against the new framework and new interfaces library. Mind you: I did not change one line of code, just recompiled. The new binaries are available for download:
Old version for SQL2000 with source code
New version for SQL2005, only binaries (but the source is the same)
Installation instructions
In SQL2005, some of the configuration details have changed, so here follows a brand new installation manual for the 2005 version.Copying the binaries
First step is to copy the compiled binaries to the folders where the reporting server and report designer expect to find them. For the report designer (the functionality you use inside Visual Studio) this is the folder:C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\bin
Note the folder MSSQL.4: the 4 indicates the SqlServer instance that is used by reporting services. With SQL2005, you will often have multiple instances. Look for the one containing the Reporting Services folder.
For the reporting server, you copy the binaries to:
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
This is a different location from the SQL2000 setup. In many development environments, you will have both the designer and the reporting server running on one machine. In these cases, you copy the binaries to both places.
Registering the extension
Now we have to let the designer and server know about the extension. For the designer, you edit the file:C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\RSReportDesigner.config
You have to add two lines to this file, one to the <Data> block and one to the <Designer> block. Here we show the result, but you have to add only the last lines of each block. For the server, you'll have to make and edit to the file
C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\rsreportserver.config
In this file, only the <Data> block needs to be modified (indentical to the change described above). The resulting block looks like this (the last line has been added):
Trusting the extension
For using the extension from the report designer in Visual Studio, you are ready now, but to run the extension from deployed reports on the server, we need one more step: the extension needs to be trusted. This is done by adding an XML block in the file:C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\rssrvpolicy.config
With these setup steps, you should be ready to use SharePoint lists as the datasource for your reporting services reports.
Labels: reporting services
