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

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

Error While Creating PPS SP2 Reporting Services 2008 Report...The Fix

jbasilico — Sun, 25 Jan 2009 01:29:00 GMT

While working on a proof this past week, I installed PerformancePoint 2007 SP2...wishing to use it with SQL Server 2008's Reporting Services. However, when creating a report which was of Reporting Services type, I recieved the following error - "Could not load file or assembly Microsoft.ReportViewer.WinForms". See image of the error below.

Well...what I learned is that Report Viewer wasn't installed by PerformancePoint 2007 SP2, so you'll need to install it on the workstations where you are going to use PPS Dashboard Designer. Luckily installing is very easy using the Report Viewer 2008 Redistributable installer found here: http://www.microsoft.com/downloads/details.aspx?familyid=CC96C246-61E5-4D9E-BB5F-416D75A1B9EF&displaylang=en.

Running a SSRS Stress Test with One User Account...Think Again!

jbasilico — Sat, 24 Jan 2009 00:13:00 GMT

Ok...so you are thinking about running a stress test against your Reporting Services 2008 environment, and you've setup your test harness (I'm biased to VS.NET Team Test 2008 with Load Agents) to use a single domain account. When you run your stress tests...you notice an interesting error like this:

HTTP/1.1 503 There are currently too many requests in progress for user: "domain\username". Please wait until the current requests have finished processing before issuing any more.

So...what do you do? Well, there's a parameter setting in the Reporting Services config files (MaxActiveReqForOneUser) that sets the number of concurrent reports that can be running at the same time for a single user...and by default its set to 20. Simply increase the number to your desired setting. See the SQL Server 2008 Reporting Services BOL for more info: http://msdn.microsoft.com/en-us/library/ms157273.aspx.

There's also a good post on this by John Gallardo: http://blogs.msdn.com/jgalla/archive/2007/01/15/load-testing-reporting-services.aspx.

Demo files Used In My BI Conference Session...

jbasilico — Tue, 07 Oct 2008 17:42:00 GMT

For those that attended my session (Designing Effective Dashboards with Msft BI Platform) at the 2nd annual Msft BI Conference in Seattle, and had asked for the demo files/projects, you can download my demo files here. The zip file contains the SQL Server 2005 Reporting Services project file, SQL Server 2008 Report Builder file for the combined sparkline and bullet graph, PerformancePoint workspace file, and the "minimum" masterpage for MOSS. Keep in mind that you'll need to alter the location of your Reporting Services installation, the Analysis Services AdventureWorks database, as well as the PPS service site on MOSS. Enjoy!

SQL Server 2008's Report Builder (RC1) Released

jbasilico — Mon, 29 Sep 2008 04:22:00 GMT

For those that were looking for the latest Report Builder tool (for use with SQL Server 2008 RTM), look no further...its been published as a web released "released candidate" for a short while already. Get the download here.

Want to know what's in this current build release?

Microsoft SQL Server 2008 Reporting Services Report Builder 2.0 supports the full capabilities of SQL Server 2008 Reporting Services including flexibile report layout, data visualizations and richly formatted text. The download includes the following functionality above the RC0 release of Report Builder:

Easy to use wizards for creating table, matrix and chart data regions.
Support for directly opening and editing reports stored on the report server.
Support for using server resources such as shared data sources.
A query designer for Microsoft SQL Server data sources.
Enhancements to the Report Builder 2.0 ribbon.

Have fun!

Nice Dundas Template for Creating Bullet Charts in SSRS

jbasilico — Sun, 10 Aug 2008 16:38:00 GMT

Well...I came across this Dundas Gauge XML Template while researching an installation issue on a recent proof of concept. In a nutshell, if you are creating "Bullet Charts" for a dashboard type report within Reporting Services, and you're using Dundas Guage controls, then you'll want to download a free XML Template that allows you to create the Bullet Chart easier. Here's the Dundas article I came across: http://support.dundas.com/Default.aspx?article=1122.

Using SAP Data with Microsoft's BI Tools

jbasilico — Tue, 08 Jul 2008 20:31:00 GMT

I often get asked by organizations how they can leverage their SAP "data" investment against the Microsoft Business Intelligence suite of tools. The set of questions usually falls into one of these four categories:

Ability to extract data directly from SAP R/3 modules for later reporting and analysis.
Ability to extract data directly from SAP NetWeaver® BI (SAP BW) for later reporting and analysis.
Ability to report directly off SAP NetWeaver® BI (SAP BW) data with Microsoft BI tools.
Ability to leverage Excel directly against SAP NetWeaver® BI 7.0 without BEx.

Well, the stock answer usually goes something like this:

Microsoft Business Intelligence (BI) provides easy-to-use, certified access to SAP data to help you make better, more informed decisions. With Microsoft BI, you can use the familiar tools in Microsoft SQL Server 2005 and the 2007 Microsoft Office system environment to create, analyze, and share your own reports and BI dashboards from all sources.

Using Microsoft SQL Server and Office SharePoint Server 2007, teams across your organization can collaborate on information coming from both the SAP and Microsoft environments to ensure everyone is on the same page when it comes to analyzing results and making critical business decisions.

Finally, our strategic relationship with SAP has gone commercial with the launch of Duet, our jointly developed product that allows you to easily and quickly interact with your SAP and Microsoft Office environments. For more information on Duet, visit the Duet for Microsoft Office and SAP page (http://www.microsoft.com/isv/sap/technology/duet.aspx).

Ok...but what does that translate into in terms of architecture and implementation choices? Glad you asked. :-)

Here's the high level architecture on how Microsoft interacts with SAP data (at least as of today, July 8th 2008).

Implementation of data extracts from SAP R/3
SQL Server 2005 includes support for accessing SAP data by using the Microsoft .NET Data Provider for mySAP Business Suite (see this link for more details: http://msdn.microsoft.com/en-us/library/cc185434.aspx). This provider lets you create a package that can connect to a mySAP Business Suite solution and then execute commands on the server. You can also create Reporting Services reports against a SAP server. The Microsoft .NET Data Provider for mySAP Business Suite is tested on SAP R/3 versions 4.6C and higher. Earlier versions of SAP R/3 are not supported.

You can use the Microsoft .NET Data Provider for mySAP Business Suite in the SQL Server Import and Export Wizard, the Script task, the DataReader source, and the Script transformation that Integration Services provides, as well as the data processing extensions in Reporting Services.

You must provide a select query to specify data to be imported. The query must confirm to the semantics supported by the Data Provider for SAP. For more information about the grammar for a SELECT query for the Data Provider for SAP, see Syntax for a SELECT Statement.

Once data is extracted out of SAP R/3, the destination of that data could be any relational database (such as SQL Server), and then reports (from SSRS) and multi-dimensional cubes (from SSAS) can be created from that database data. The resulting SQL Server reports/cubes could then be used within the Microsoft Business Intelligence delivery mechanisms, such as through Excel, SharePoint, PerformancePoint, etc.

Implementation of data extracts from SAP NetWeaver® BI (SAP BW) using Open Hub and SQL Server 2005 Integration Services
The SAP Open Hub service enables you to distribute data from an SAP BI/BW system into external data marts, analytical applications, and other applications. With this, you can ensure controlled distribution using several systems. The central object for the export of data is the InfoSpoke. Using this, you can define the object from which the data comes and into which target it is transferred, leveraging SQL Server Integration Services (SSIS) as the transfer/transform mechanism.

SAP BI objects such as InfoCubes, ODS objects, or InfoObjects can act as open hub data sources. You can select database tables or flat files as open hub destinations, and then use those destinations as actual sources within SSIS. To automate the extraction using SAP’s Open Hub Service, you’ll need to setup a process chain. Note that both a full and delta modes are also available as the extraction mode.

As stated already with direct extraction from SAP R/3, once data is extracted out of SAP NetWeaver® BI (SAP BW), the destination of that data could be any relational database (such as SQL Server), and then reports (from SSRS) and multi-dimensional cubes (from SSAS) can be created from that database data. The resulting SQL Server reports/cubes could then be used within the Microsoft Business Intelligence delivery mechanisms, such as through Excel, SharePoint, PerformancePoint, etc.

Note that SQL Server 2008 Integration Services will include direct support for the NW BI 7.0 OHS - http://download.microsoft.com/download/1/7/5/175af735-edab-41db-b762-1b259ec5b362/Microsoft%20BI%20and%20SAP%20NetWeaver%20-%20SSIS.pdf.

Implementation for reporting against SAP NetWeaver® BI (SAP BW) data
Through a rich extensibility model, the report authoring and report deployment features of Microsoft® SQL Server™ Reporting Services 2005 can integrate with any number of business intelligence data sources. To answer the strong need for a rich reporting tool for SAP NetWeaver® Business Intelligence (SAP BW) and to bridge the gap between these two powerful business intelligence platforms, Microsoft has developed a new .NET Framework data provider and query designer for SAP NetWeaver® Business Intelligence.

With the release of SQL Server 2005 Service Pack 1 organizations can now take advantage of SQL Server’s Business Intelligence (BI) capabilities such as Reporting Services on SAP BW Data without purchasing independent and expensive reporting solutions. SQL Server 2005 Reporting Services is now certified to run reports on SAP BW. Customers that already own or plan to purchase SQL Server 2005 SP1, will get two new components that provide support for reporting on SAP BW in the SP1 release:

• The 'Microsoft .NET Data Provider 1.0 for SAP NetWeaver® Business Intelligence’

• A new query designer to enable the creation of SAP-compatible queries for SAP BW

The new Microsoft .NET Data Provider 1.0 for SAP NetWeaver® BI is a standards based provider that uses standard internet protocols and XML for Analysis (XML/A) (an XML standard for Online Analytical Processing - OLAP) to communicate with the SAP server. The .NET provider enables users to directly access QueryCubes as well as InfoCubes and MultiProviders. Since XML/A support is built into SAP BW, SAP BW reports can be authored and developed using SQL Server 2005 Reporting Services regardless of which relational database SAP BW data is stored in. To significantly reduce bandwidth requirements and improve network performance, the Microsoft .NET Data Provider 1.0 for SAP NetWeaver® BI uses GZIP compression when communicating with the SAP BW server, enabling organizations to efficiently work with large XML documents. Security is essential for data integrity; and the Microsoft .NET Data Provider 1.0 for SAP NetWeaver® BI supports and leverages internet standards such as SSL. This enables the system to safely transmit data between your SAP BW server and SQL Server 2005, providing added protection to your essential business information.

The new custom built Query Designer enables you to rapidly build reports for SAP BW. The query designer builds SAP-compatible MDX queries to base your reports on and provides insight into cubes, cube meta-data, calculated members, functions and variables.

By connecting SQL Server 2005 SP1 Reporting Services to SAP BW data, SAP BW users can quickly and easily take advantage of the flexible, yet easy-to-use reporting capabilities of SQL Reporting Services without migrating their data to another platform. This new integrated solution makes it easy to create and manage reports on information inside any SAP BW Data Warehouse, empowering organizations to easily get important SAP business intelligence information to the people who need it. SAP BW report authoring now becomes easy-to-do, consistent and familiar using SQL Server 2005 Reporting Services. Plus, deploying and distributing reports becomes a simple one-step process that targets the Web as the reporting platform – viewing reports becomes as simple as clicking a hyperlink.

In order to use the provider, the following components must be installed:

· Microsoft SQL Server 2005 Reporting Services Service Pack 1 or later

· Microsoft .NET Framework 2.0

The provider has been developed for and tested against SAP BW 3.5. However, the provider should also be compatible with BW 3.1 and BW 3.0B servers that have been patched to a sufficient service pack level, described below.

· Support Package 30 for SAP BW 3.0B

· Support Package 24 for SAP BW 3.1

· Support Package 16 for SAP BW 3.5

· Support Package 10 for SAP NetWeaver® 2004s (BW 7.0)

For more information on using Reporting Services directly against SAP BW, follow this link: http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/UsingRSwithSAPNetWeaver.doc.

Implementation for reporting against SAP NetWeaver® BI 7.0 Using Excel (without BEx)
Users familiar with SAP’s BW or NetWeaver BI often are interested in native Excel integration with SAP’s business intelligence data. SAP only offered BEx Analyzer in the past…however some casual users weren’t interested in learning this Excel Add-on tool. Now with SAP NetWeaver® BI 7.0, Excel 2007 users can tap into the full power of SAP BI data from within the comforts of the native Excel 2007 environment.

More potential for SAP NetWeaver® BI

· SAP customers can deploy SAP NetWeaver®BI beyond the realm of classical BEx users

· Microsoft customers can continue working with Excel to leverage data from SAP NetWeaver®BI Warehouses

SAP supports the standard

· Microsoft Excel is a long established standard for reporting

· The Pivot Table is a fast and intuitive way to analyze data

· Microsoft Excel 2007 provides enhanced reporting and formatting features like “top n” analysis

Very simple prerequisites, full support

· SAP NetWeaver®BI 7.0 natively and fully supports Microsoft Excel 2007

· The prerequisites are described in Note 1134226

· No BExAnalyzer or SAP NetWeaver®BI training necessary

Trusted integration

· Microsoft Excel has been supported in the past with some known some limitations in areas like hierarchy handling or filtering

· The new native Microsoft Excel 2007 integration provides access to SAP NetWeaver®BI data in a reliable and trusted way

To learn more about this native Excel 2007 interaction with SAP NW BI, go here: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8483.

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).

Object Promotion Process for Microsoft BI Objects

jbasilico — Tue, 15 Apr 2008 04:59:00 GMT

With Integration Services, Reporting Services, and Analysis Services, their respective business intelligence objects (packages, reports, and cubes) are designed through the Business Intelligence Design Studio (BIDS), which is really the Visual Studio shell incorporated with special SQL Server 2005 business intelligence project templates installed. Using BIDS, or Visual Studio 2005 with the BI templates installed, allows the developer to deploy the projects directly to a server environment. This works fine for a development environment where the developer most likely has access and permissions to deploy objects to the server, but what about Q/A, Beta (Test), and Production environments? Most likely, organizations do not want their developers impacting installed objects on their test and production environments…for obvious reasons. Therefore, a change management/object promotion process must be utilized against the business intelligence environment, allowing non-developer resources to quickly and easily deploy new object types.

Also of consideration is object versioning. When working with Visual Studio, there are multiple product options that allow versioning and check-in-check-out of project objects. From Microsoft, two products exists that enable versioning/checking object code, those being Visual Source Safe, and Team Foundation Server.

The process for deployment "object promotion" to non personal-development environments is accomplished through three different options:

1) Use BIDS/Visual Studio 2005 to open the project/solution, and then deploy the data sources and reports to the appropriate server. The project object allows for multiple configuration settings, and is an exposed set of properties that can identify development, QA, test, and product environment settings.

2) Use a scripting engine (for Reporting Services that scripting engine is RS.EXE, for Analysis Services it’s ASCMD, and for Integration Services it's DTUTIL) to develop a script that deploys, installs, and secures objects to a particular target server. (Note – There are several sample scripts that come with SQL Server 2005 for reference).

3) Use application interfaces to create a custom deployment tool. For example, the Reporting Services management web service endpoint (http://<Server Name>/ReportServer/ReportService2005.asmx?wsdl) could be used to accomplish the same deploy, install, and securing of Reporting Services objects that the RS.EXE scripting command implements.

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.

Implementing Parent-Child Relationships in Report Builder - Well Sort Of...

jbasilico — Sun, 27 Jan 2008 22:34:00 GMT

Ok...everyone should know by now that SQL Server 2005's Report Builder doesn't support parent child relationships within a report model (think about the classic employee to supervisor hierarchy...or for another example, how a company may roll up into a parent company/entity). So...how do you overcome this limitation of the SQL Server 2005's Report Builder/Model? Well, unfortunately there isn't a simple answer or solution...but there is a partial workaround. The workaround leverages SQL Server 2005's Common Table Expressions (CTE) and a compromise by the business users.

First...lets tackle the compromise by the business users. Since a parent-child hierarchy can be infinitely long...you'll need to pin down from the business users the anticipated largest depth of the hierarchy. For example, does the employee to manager hierarchy have three levels, or four levels, or five levels deep? Once you determine the longest "known" depth of the hierarchy, you'll use this knowledge to create a recursive query within the database to produce known levels for traversal.

The next step is to create a recursive query within the SQL Server 2005 database. If you need to learn about the recursive query CTE, then read this SS2K5 BOL entry, or check out this great blog entry on the topic. The CTE based recursive query should give you a result set something like "parent, child, level". Once you have the recursive query in place, you'll then want to construct a view from the CTE, whereby you'll leverage the view to join the identifier parent and child pairs to the decode table to return identifier names (assuming your model is normalized in this manner) down to the number of levels deep as compromised by the business users.

Once the recursive query is defined, you'll most likely then create a named query with Report Builder's "Data Source View" (DSV). This named query can be simple, or rather complex depending upon your database model and the number of custom Report Builder "click through" reports you want developed. Meaning, if you want a custom click through report for level 1 versus a different custom click through report for level 2, you'll need to create two separate named queries within the DSV, since an entity can only have one custom report per scalar or aggregate value. (For more information on creating custom click through reports for Report Builder, view this SS2K5 BOL entry).

Ok...that's it. You should now be able to traverse a parent-child relationship successfully within Report Builder...albeit with a compromise from the business end-users.

Implementation of Sparkline Type Reports within Reporting Services

jbasilico — Thu, 10 Jan 2008 06:55:00 GMT

As with any dashboard implementation, an intuitive user interface design is desired, thus leveraging the latest concepts in dashboard user interfaces. One of those concepts is to display Sparkline type charts. A “Sparkline” is a word coined by Edward Tufte to describe “small, high-resolution graphics embedded in a context of words, numbers, and images.” Sparklines are “word-sized graphics” which can be used to add context to data in a sentence. More than that, though, Sparklines are word like graphics that can be used almost as words.

To implement Sparklines within Reporting Services is rather easy…in fact, the charting object within Reporting Services can be shrunk within a table object, thus producing the Sparkline image.

Do note though that placing many inline Reporting Services charts within a table will put more processing burden on the Reporting Services server, since each chart needs to be determined and rendered.

Other than leveraging the chart object within Reporting Services, there are a few third party solutions that “plug into” the Microsoft BI Platform to allow Sparkline and other visualization techniques. One such offering is from BonaVista Systems – through a product called MicroCharts. For more information visit this link: http://www.bonavistasystems.com/Products_SparkLinerforMicrosoftBI.html.