Tips, Tricks, and General Info on the Msft BI Platform : Sharepoint

Getting Excel Web Access Errors with SSAS 2008?

jbasilico — Tue, 15 Dec 2009 19:21:00 GMT

If you are having issues getting Analysis Services 2008 data being refreshed through Excel Services, take a look at the trusted providers within MOSS. By default, MOSS only trusts up to SQL Server 2005, simply because SQL Server 2008 wasn't out when MOSS 2007 was released.

To correct, you'll need to add a Trusted Data Provider as follows:

Provider ID = MSOLAP.4
Data Provider Type = OLE DB
Description = Microsoft OLE DB Provider for OLAP Services 10.0.

For full explanation/steps that walk through the "fix", follow this link.

Setting Report Builder 2.0 as the Default ClickOnce Report Builder Version (Native and MOSS Integrated)

jbasilico — Thu, 18 Jun 2009 20:40:00 GMT

Once you've installed SQL Server 2008's SP1 (download here), I'm sure you'll want to have Report Builder 2.0's click once feature activitated. By default, SSRS will still call Report Builder 1.0 application. Here are steps needed to enable click once for Report Builder 2.0

To change the default ClickOnce application in Report Manager for "Native" mode:

Start Report Manager
Click Site Settings.
Click General in the left pane.
In Custom Report Builder URL, type /ReportBuilder/ReportBuilder_2_0_0_0.application.
Click OK.

To change the default ClickOnce application in SharePoint Central Administration for MOSS Integrated mode (note you'll need to download the SP1 update for MOSS Integrated mode, plus the Report Builder Click once update as well...both found here):

On the Start menu, point to Administrative Tools and then click SharePoint 3.0 Central Administration.
On the Central Administration page, click the Application Management tab.
Under the Reporting Services section, click on Set Server Defaults
In Custom Report Builder URL, type: /_vti_bin/ReportBuilder/ReportBuilder_2_0_0_0.application.
Click OK.

Implementing SSRS Reports from SharePoint Server 2007 List Data

jbasilico — Fri, 27 Mar 2009 05:38:00 GMT

There are three fundamental methods for implementing reports against SharePoint Server (MOSS) 2007 list data: direct MOSS table query, web service query, and finally third party tools which implement the web service interfaces. Although the direct table query of the MOSS database structures might seem like the easy answer, the tables and relationships within MOSS are quite complex, and thus the effort to create such a direct report is not suggested. This leaves the web service implementation…either called from your own Reporting Services queries, or called indirectly through your Reporting Services queries which leverage 3^rd party tools. The choice becomes a matter of build versus buy…depending upon the level of developer experience and available funds for 3^rd party tool’s purchase(s).

The following links describe the three various methods for MOSS list reporting using Reporting Services 2005.

Query directly against MOSS databases

http://www.mssqltips.com/tip.asp?tip=1323

Query using MOSS web services

http://www.teuntostring.net/blog/2006/03/update-reporting-over-sharepoint-lists.html

Query using 3^rd party tools for data extensions (Enesys)

http://www.enesyssoftware.com/Products/EnesysRSDataExtension/Overview/tabid/72/language/en-US/Default.aspx

Effective Dashboard Design Practices

jbasilico — Fri, 13 Jun 2008 16:35:00 GMT

Through conversations with many customers, I’ve been asked either directly or indirectly what makes a dashboard good in terms of design. Put it another way…what are some design best practices to make a dashboard more effective at conveying the “data” message.

Well…here’s the list of dashboard design best practices that I try to follow. How many do you follow already?

1. Keep the dashboard to a single web page that viewable in a single screen. If additional detail is needed, have that detail (or related data) be navigation to different pages on the dashboard.

2. Make sure there is context to all data elements presented on the page…meaning if presenting a number (let’s say sales revenue by quarter to quarter comparison), is the latest number good or poor.

3. Keep “like” data grouped (arranged) within the dashboard.

4. Keep precision and detail of data to a minimum. For example, to conserve space on a page, instead of showing $3,000,000 show $3m. Think of “detail data” in the same light…does it really make sense to show all that detail if it is better served on a subsequent dashboard page.

5. Don’t use pie charts or radar charts on a dashboard.

6. Use a uniform color scheme and object rendering as appropriate –put in other words, don’t just use a cool image/representation of data “just because”.

7. Don’t use bright colors in charts/graphs…use either light colors or even grayscale. Use the bright colors for highlighting important information, like yellow or red KPI status.

8. Keep most important data (aka data your want the user to see first) in the upper left, least important data in lower right. Also keep in mind relative size to one another…for example; a large colorful graph in the lower right may overpower the important data in the upper left.

9. Don’t over complicate the dashboard page(s) with design elements…aka, fancy gauges, images, etc. Not only do these designs waste space, but they draw the user’s attention away from the important data.

10. Reduce non data pixels as much as possible…meaning do away with borders, gradient fill colors, grid lines, extra images, etc. The simpler the better.

11. Use “sparkline” and “bullet” graphs to represent data. Both can be achieved within Reporting Services 2005/2008 (as seen below).

Creating UDM Report Builder Models in SSRS-MOSS Integration Mode

jbasilico — Thu, 31 Jan 2008 19:04:00 GMT

I've seen this question come up on many a proof...and that is how do you generate Report Models off an Analysis Services UDM (OLAP cube) once you've put SQL Server 2005 Reporting Services into Microsoft Office SharePoint Server (MOSS) Integration Mode. Well, when not in MOSS integration mode, it was rather simple...just deploy the data source to Analysis Services and then either use Report Manager or SQL Server Management Studio to generate the "model" off the data source. So now you’re staring at the MOSS UI, but don't see a way of generating the UDM based model...well, you’re probably missing some MOSS configuration to enable report model generation. The configuration you need is to enable multiple content types for the library your working with (for example the data connections library for the "Reports" subsite in MOSS), and then add report server types to that library. I normally will go ahead and add the "Report Builder Report", "Report Model" and "Report Data Source" content types to the library. For full details on how to configure these content types in MOSS, refer to this BOL section from SQL Server 2005.

Once you've added these content types to the library...actually creating the Report Model from the UDM is rather easy, and it’s just two steps: 1) Create the Report Data Source (if not already deployed to the MOSS site), and 2) Create the Report Model. With the new content types added to your MOSS library, both of these steps are as easy as clicking on the "New" item from the MOSS menu, and picking the correct item (either data source or model). Obviously you'll want to generate the UDM model based from the UDM data source you created in step 1. For full instructions on creating the Report Model from within MOSS, review this BOL section from SQL Server 2005.