If you are using BIDS to develop reports for Reporting Services in SharePoint Integrated mode, you may find some of the deployment options somewhat confusing. Paths in Native mode must be relative, white in integrated mode, they must be absolute. To get to the deployment options, you right click on the project from the Solution Explorer window, and select Properties.
The highlighted areas are the ones that we need to be concerned with. The TargetServerURL property is the most important of the bunch, as you are essentially telling Visual Studio where to find the Reporting Services Web Service. The value that you select here should be the root of the site collection where the report is contained. Basically, because the SharePoint front end is now the report server this makes sense, and the property makes sense in native mode, but for integrated mode this property should be called TargetSiteCollectionURL.
The xxxFolder parameters all behave the same way, and they should contain the complete path to the container for each one (which easily could be the same value). The path should include everything including http, the site collection,the path to the site,the library, and if used, the SharePoint folder. In integrated mode, if you replace folder with Library, or even better, path, this will make more sense.
Ever Since SQL Server 2005 R2, it has been possible (with varying degrees of difficulty) to tightly integrate Reporting Services with SharePoint. What this means is effectively discarding the management and user interfaces that come with a Reporting Services native mode installation, and managing and use all reporting through the SharePoint interface.
This has really nice benefits for those managing the Reporting Services environment, mainly because you can simply leverage your SharePoint storage and security infrastructure instead of having to create and maintain another one simply for reports. Users benefit from a consistent user experience, and are easily able to create filtered reports through the Report Viewer web part.
Integrated mode is however not without its complications, and with the release this week of SQL Server 2008 R2 (which includes some very nice Reporting enhancements), I thought that I’d go over them. Here are some of the more important moving parts:
Reporting Services Add-In must be installed on EACH front end web server in the farm
Reporting Services database must be created in SharePoint integrated mode
Anonymous access must be disabled for the target application
The machine hosting Reporting services must be a member of the SharePoint farm
If everything that you’re running is on a single server, you really don’t need to read any further. In that scenario, everything is straightforward. But if you’re not on a demo system, or you have more than 3 users, chances are that your farm is distributed, and least broken out into one Web Front End (WFE) and one SQL Server.
As I’ve mentioned previously,The Reporting Services add in now installs as a prerequisite with SharePoint 2010,which makes the first point a no brainer. However, if you have SharePoint 2007 and multiple web front ends (your query servers count), you need to install the add in. Also if you add a new Front End server down the road, don’t forget the add in.
If you’re currently have a Reporting Services server running in native mode, and you’re looking to upgrade to SharePoint Integrated mode, don’t expect an enjoyable experience. You can’t upgrade your existing native mode database to integrated mode, you’ll need to export everything, create a new database in integrated mode, and move everything into it. You can however switch back and forth on the server side if you need to, but as you do, it’s all or nothing.
One thing that I wanted to do was to take an election results analysis demo that I’ve recently done with SQL Server 2008 R2 mapping and expose it to the world. Unfortunately, that’s not going to be an option because you can’t run the application in anonymous mode with the plug in. If you have this requirement, then Integrated Mode is not for you.
Finally, the big requirement is that the machine running Reporting Services must be a member of the SharePoint farm. Typically you only install the SharePoint bits on the WFEs and the Index servers, and the SQL Server itself is left alone. Basic guidance from Microsoft indicates that now you need to install the SharePoint bits on the SQL server and then join the farm. This may be daunting to those that have yet to “enjoy” the challenges of running a multiple WFE farm. It also might be a particular challenge if you don’t “own” the SQL server itself.
My preference (typically, not always) is to take the other approach, and install Reporting Sevices itself (none of the other services, database engine, etc) on one of the SharePoint front end servers. In our case, we have a 3 server farm (one front end, one indexer/query/central admin, and one SQL, and Reporting Services is on the Indexer/query/central admin box (I need a better name for it).
In this scenario, the Reporting Services databases themselves still live on the main SQL server, but the services and rendering all happen from the WFE machine. This makes for a very low touch solution in terms of your SQL server, and is much easier to maintain. This model also also allows you to get going with the new features available in SSRS R2 without having to first upgrade your central SQL server.
One caveat – with 2007, I always found that it was a requirement to also run the Central Administration application on the machine with Reporting Services. I don’t know if that was a true limitation, or something that I was missing. I haven’t yet tried it using R2 and 2010, but when I do, I’ll come back here and update this. Also – if you know something I don’t, please feel free to enlighten me!
I ran into an odd error today while installing the RTM of SharePoint 2010 on a clean server farm. I had built everything up from scratch on current versions, including SQL Server. I had applied SP1 and run all Windows updates. When I got to the point of actually running the Products and Technologies Configuration Wizard, I received an error stating that my SQL Server was running an unsupported version of SQL, version 2007.100.2531.0. Yes, it was 64 bit, as was everything else. I thought that was rather odd, and thought I’d try to find something newer.
Cumulative Update 6 for SQL Server 2008 is available so I thought I’d try applying that. Lo and behold it worked, and I continue to install away.
I just hope that it’ll be just as happy with SQL Server 2008 R2….
The latest version of Reporting Services, due out any day now, has built in support for mapping. This is a very welcome addition and adds significantly to the “cool” factor. I recently completed a quick demo project using public data available from Elections Canada, and I will be sharing some observations over the next few days. I’m a newbie to mapping, so I’m sure that that the GIS folks out there will think this is quaint, but this really does take a technology that was previously available to a select few, and make it available to a much broader audience, something that Microsoft is particularly good at.
Firstly, I have to mention that this was built using the November CTP of SQL Server, and was implemented on SharePoint 2010 beta. Technology Preview on Beta would typically be a recipe for frustration, and while there were bugs, it went together surprisingly well.
There are essentially 2 major data components to a map report,the spatial data and the analytic data. The spatial data contains the map elements themselves,and data that will be used to relate to the analytic data, where the analytic data contains the data that is to be mapped. In my first example, I have data that describes all of the riding boundaries in Canada, along with their metadata (riding number, province, etc). I also have election result data that can be grouped by riding number, so a relationship is created between them. I’ll demonstrate below.
You can create a map in any Reporting Service report, either using the Report Designer in Business Intelligence Design Studio (BIDS), or by using the new Report Builder end user application. Using BIDS, you need to drop a map control onto the design surface to start the map wizard, and Report Builder gives you the option at create time.
The wizard then prompts you for your spatial data. You have 3 choices as shown above. The map gallery lets you choose from the full list of pre-packaged maps available in the product consisting of a grand total of 1 country, the USA. To be fair, this is by design. There are so many border disputes in the world that the US is the only safe bet. In fact, as a Canadian, we share a border with 4 different countries, and unless I’m mistaken, we have border disputes with three of them. This leads us to the next choice, the ESRI Shapefile. These files are the de facto standard for spatial data, and are readily and freely available from the public domain. The Shape files used in this example came originally from Elections Canada. Finally, SQL Server, starting with 2008 supports a spatial data type. This is essentially a series of polygons. It’s a little known feature, and spatial data is supported directly within Management Studio, as can be seen below:
Whenever a query result contains spatial data, a little “Spatial results” tab appears which allows you to visualize the results.
Which one to choose? Well importing the shapefile directly is fast, but using SQL data gives you much more flexibility from a querying standpoint. Also, if the gallery or shapefile are chosen, the data is embedded directly in the report, which is not the case with SQL.
Luckily there’s an excellent little utility available from SharpGIS that makes it very easy to just move your shape files up to SQL.
The next screen you see will depend on your choice, but in the case of SQL you can either choose a shared dataset that has the spatial data, or you can create an embedded dataset for this purpose. Once the data has been defined, you can configure the map’s viewport.
Here you set the zoom level, and can set the panning parameters. You can also choose the type of data that the map is to use – in this case polygon, but other options are point and line (for single point and route type data). Also of note are the two options at the bottom. You can choose to embed map data in the report (removing reliance on the back end data for the map data, effectively creating a snapshot). The second option is to add a Bing Maps layer – allowing you to add the richness of Bing Maps to your visualizations. However, this can only be done if your map data is geographic. Geographic data maps directly to real geographic positions (latitude and longitude) whereas planar data is simply a set of shapes that fit together.
The next window allows you to choose your visualization.
The basic map will only show the data in the map itself, and required no further data. the color analytical map essentially fills in the regions according to analytical data, and the bubble map positions analytical data on the map. Additional layers can be added to any map after the fact. In our example, we choose the Color Analytical Map.
The next screen prompts us to either choose a shared dataset that contains our analytical data, or to create a new dataset. Once we have selected the data to use, the next dialog box allows us to establish the relationship between the map data and the analytical data. In our case, the field FED_NUM in the map data corresponds to the EDANum field in our election results data.
Finally, we choose a theme (which defines the “chrome” of the report), the field to use to determine our our colouring, the patterns to use to visualize the data, and what to display as a label, if anything.
And that’s all there is to creating a basic map! at this point, you can click run in Report Designer, or preview in BIDS, and you should see the results of your analysis as below, which in our case are the results of the Canadian 2008 General Election on a riding by riding basis.
Many things need to be adjusted further (zoom, which color to use for which party, and a number of other things), and I’ll cover some of these in a future blog post, but as you can see, the map wizard is quite capable of delivering immediate results.
I’m pretty disappointed with Windows Virtual PC (the latest version). It’s April 2010, and it still doesn’t support 64 bit guest operating systems, which I believe is a pretty glaring omission. I’m a big fan of Microsoft’s server virtualization (Hyper-V) but the client side is just so lacking, I’ve been forced to find another solution. For a number of reason (chief among them video performance) I do not want to put Server 2008 on my laptop.
Microsoft actually forced the issue themselves. The latest waves of server releases (SharePoint, SQL Server) are 64 bit only. As a developer/architect I need to run these servers from my laptop, which makes it impossible to use Windows VPC. Originally Windows VPC also required hardware virtualization, which made it unusable on some of our systems, but they have recently removed that restriction. Good.
I was originally a VMWare user, and I only switched to VPC after I noticed that it performed considerably better on Vista 64 bit systems. VMWare had become a dog. I was also hoping that using Microsoft virtualization would make it easy to move VMs between client systems and Hyper-V. Alas, that was not to be the case.
Given all that, I recently installed VMWare 7, and I’ve been quite impressed with its capabilities and its performance. Don’t get me wrong,it would be much simpler,and cheaper for me as a Microsoft Partner to use MS technology across the board, but until such a time as they support 64 bit guest operating systems (which is something they have been very quiet about), it’s simply not an option for me.