Thursday, August 11, 2011

SSRS: Migrating Reports to SharePoint Integrated Mode

This blog post covers the process of migrating a report from Microsoft SQL Server Reporting Services 2008R2 running in non-integrated (i.e. non-SharePoint) mode to a different server also running 2008R2 but running in SharePoint integrated mode.


A Little Background
This is important as it will affect the steps you need to take!

In our environment we split the various parts of the report (Data Source, Data Set, and Report) into separate files. This allows multiple datasets to share a data source, and multiple reports to share a data set. It's a fairly useful design.

If you don't do this and just bundle everything into the Report - your maintenance must be a nightmare if you have a large number of reports! - then all you need to do is the single "Migrating the Main Report File" step below.

I suspect (hope!) that most large companies will do it our way.

Finding Items To Migrate
There are three parts to a report; Data Source, Dataset, and Report.

Steps to identify the bits to move are given below.

Identifying The Report
Find the existing report you wish to migrate on the non-integrated server. In this example I'll be migrating the "AP Separation Monitor" report;



Identifying Any Datasets
Hover over the report name until it's menu appears and then select "Manage";


Click on "Shared Datasets" in the list on the left side;

Make a note of these "Datasets".

Identifying Required Data Sources
Find each of the datasets identified above and "Manage" them;

Click on "Data Source" in the panel on the left;

Make a note of this data source.

Migrating The Main Report File
Hover over the report name until it's menu pops up and then select "Edit in Report Builder";

Choose "Save as" from the Ribbon menu;

Click on "Recent Sites and Servers" at the top left on the pane on the right;

This displays a list of all the recent sites and servers you have used. If your new SharePoint server is not in the list then you'll need to create a new instance of Report Builder and create a new report on your new server (which you can then delete) in order to get the Site/Server to appear in this list.

Select the new (Integrated mode) server you wish to use.

You are now presented with a list of all the document libraries in SharePoint and you need to pick the one in which you want to save the report. I'm going to use "Reports LIVE".

This is a list of existing reports in the document library. I'm not planning on changing the name so just click "Save" (you will get an error);

The key part of the error is "The report definition was saved ...". The errors are due to the data sources not being exactly identical on the new server with what they were on the old server. Clicking on "Details" for my report I can see the error text is;

The report 'http://xxx/Reports LIVE/AP Separation Monitor.rdl' contains a reference to a dataset that is not valid. Verify that the shared datasets that are required for this report are deployed to the report server.

As we haven't moved across the datasets yet this problem is expected.

Close down report builder.

Migrating a Dataset
The process for migrating a dataset is almost identical to the process for migrating a report (so I'm not going to reproduce the image).

Hover over the data set until it's menu appears and choose "Edit in Report Builder", use "Recent Sites and Servers" to point to the new server, select the document library in which you want to save the dataset (I'd recommend a different one to the report!) and click "Save". You get an error, but it's different;

Note the key difference that you're not seeing a "The report definition was saved ...". It has been saved, but the message is much more worrying - still just as irrelevant - but it looks more worrying.

If you click on "Details" then the message gets truly bizarre;

"The path of the item '/Data Sources/NOETIX_R12TEST' is not valid. The full path must be less than 260 characters long; other restrictions apply. If the report server is in native mode, the path must start with slash. ---> Microsoft.ReportingServices.Diagnostics.Utilities.InvalidItemPathException: The path of the item '/Data Sources/NOETIX_R12TEST' is not valid. The full path must be less than 260 characters long; other restrictions apply. If the report server is in native mode, the path must start with slash."

This is a rubbish error message (Microsoft take note) but it doesn't matter as the dataset has been saved;

Close down Report Builder (you will be prompted to save again, just ignore that and click "No").

Migrating The Data Source
Don't. Just create a new one. It's genuinely not worth the hassle of migrating an existing data source - all your passwords will be cleared anyway so why bother?

On our new folder Data Sources live in the Data Sources document library;

You'll only need to do this once for each Data Source.

Connecting It all Together
Looking at the Report/ Dataset/ and Data Source information we have from the old server the structure we need to configure on the new server is;

Joining Dataset to Data Source
Go to each of the datasets on the new server hover over them until the menu appears and choose "Manage Data Sources";
This shows you (via the yellow triangle) that there is a problem with the Data Source. Click on the link (called DataSetDataSource) to get the properties;

As you can see from the error message (The linked data source could not be found) you need to specify the Data Source Link. Click on the elipse to locate it or just type the full name into the box. In the case of this example the Data Source we are after is;

http://xxx/Data Sources/NOETIX_R12TEST.rsds

(If I'm going to convert a lot of reports I tend to have strings like this in Notepad somewhere as, if you try the ellipse, you'll see that it's not exactly quick identifying the data source that way). Once you've found/ entered the Data Source click "OK and it will be verified.

Click on "Close"

Joining Report to Dataset(s)
Find the report, hover over it, and select "Managed Shared Datasets";

In this specific report we have two datasets that aren't configured correctly. Click on the link (we'll start with APSeparation Monitor);

Click on the ellipse;

As I have separated the datasets from the reports there are no datasets in the default directory (the reports directory) so click on "Up" and navigate into the datasets document library;

Select the "AP Separation Monitor" dataset (the one we recorded earlier);

The link is actually the URL of the Dataset;

http://xxx/Data Sets/AP Separation Monitor.rsd

Click on "OK" and the link will be verified.

The first dataset has now been fixed, repeat the process to fix the second dataset. You'll notice that the dataset links aren't obviously named so it's worth writing down the names from the old server (which you did earlier ... right?) rather than hoping to remember it when you get to this stage.

Click "Close" when you've completed the fix.

Test the report and you're done.

Tidying Up
Ah yes, now you've moved the report across you really should be getting rid of the old one. If it's a big migration job it really helps to not complicate things further by leaving items you've already migrated on the existing server. Equally though you don't want to break anything.

The easiest item to remove is the report - these can be deleted straight way as nothing can really be dependant on them (if you've separated everything correctly!). Find the report, hover over it, and select "Delete" from the menu.

As there is a possibility of a dataset being used in a different report you need to check. "Manage" the dataset;

Click on "Dependent Items" on the left;

As you can see the message;

"There are no items that use the "/R12/Finance/Shared Datasets/AP Separation Monitor" dataset."

Is being displayed meaning that there is nothing (now we've deleted the report) that used the dataset so we can safely delete it (go back to "Properties" on the left and click "Delete").

Now looking at the other dataset and doing the same check;

This shows that there are a large number of other reports that are using this dataset so it should be left alone rather than being deleted (why Microsoft doesn't do this check and give you a warning when you do a delete is beyond me!).

And that's it. We now have a report running on a different server. There is slightly more tidying up to do to ensure that the SharePoint details for the Report and Dataset are up to date (for example the Dataset description will not have been copied across).
Post a Comment