SharePoint

PowerPivot, Silverlight PivotViewer, Excel Services, Performance Point, Project Crescent from STL BI Use Group

Kevin Shyr — Fri, 20 May 2011 02:21:41 GMT

Meeting notes:

· Reporting Services is now incorporating Dundas Tools for better UI tools (I thought this was done a while ago)

· New to Reporting Services 2008 R2: visualization tools like data bar, sparc lines on row level

· Why should you use Microsoft Reporting Services? It is a big ASP .NET extensible application. If you want customization, you can easily build on top of this.

Reporting tools in addition to Reporting Services reports:

·         Silverlight PivotViewer Control (hosted on web server):
   http://www.silverlight.net/learn/pivotviewer/
    http://www.microsoft.com/silverlight/pivotviewer/

· Excel Services (hosted in SharePoint, managed service configuration):
http://msdn.microsoft.com/en-us/library/ms546696.aspx

·         PowerPivot (can be used in Excel 2010 Professional as standalone add-in; when sharing is required, it needs to be deployed to a SharePoint 2010 and SSAS 2008 R2):
    Note: this builds an in memory cube and MDX, when deployed to SharePoint, the cube is built in the SQL server. It can also be built the other way around where a cube is built first, then use PowerPivot to create report. There are plenty of data source adapters available, including Teradata, Oracle, DB2, oData, etc.
    http://www.powerpivot.com/

·         Performance Point (hosted in SharePoint Server Enterprise, replaced Proclarity):
    Enable drill down
    http://technet.microsoft.com/en-us/library/ee661741.aspx

· Project Crescent (coming soon)
http://team.silverlight.net/announcement/project-crescent/

Discussion:

Naturally, the discussion took a turn on “What tool should I use when?” The official response from the presenters is:

· If we have only 1 user, then maybe start with PowerPivot

· Enterprise level reporting should build cubes, then UI is based on User requirement

· Anything else is in the grey area

My take is that if I work for a company with access to a SharePoint Enterprise server, then I would definitely let the report user build the report in Excel using PowerPivot. When the report is ready, then we can reconcile the differences and migrate the single-user report to use Enterprise cube and hosted in SharePoint.

Resources:

· http://www.bidn.com/

· http://pragmaticworks.com/Resources/PragmaticMinutes/Default.aspx

· http://pragmaticworks.com/Products/Business-Intelligence/BIDocumenter/Default.aspx Database Edition is free

SharePoint 2010 and SQL Server 2008 R2 BI

LifeLongTechie — Wed, 13 Jan 2010 18:21:15 GMT

Just saw a presentation on SharePoint 2010 and SQL Server 2008 R2 BI Integration. There are some cool stuff that will be out soon.

The presentation focused on PowerPivot and Performance Point server. A end-business user can access her/his datasource, pull in some external data (like weather condition), and create a spreadsheet using PowerPivot. This spreadsheet, in addition to being hosted on SharePoint, can be incorporated through Performance Point by a SharePoint developer, and build a Cube in Analysis Services using that spreadsheet. How cool is that!

And MSRS is going to use Silverlight heavily. Can't wait to see what it'll look (well, expectation is low based on the existing UI. haha)

Final note on creating PDF using SSRS and SSIS

LifeLongTechie — Tue, 08 Dec 2009 20:19:51 GMT

Business Scenario:

The client gets some kind of feeds that writes into a process table of their client processing system. The data is stored directly as the raw XML file inside a SQL data column. The XML could store multiple enrollment information for the same member. We need to use this info to determine whether a member is eligible, then insert into a staging table.

The staging table is then used as a feed to drive a report that generates an image for each claim and sent off to the different provider.

Some of the staging table info need to go out to another partner.

Solution:

We used this (this) to extract the info out of the XML data to put them into the staging table.

We select some rows from the staging table and pass the claim ID to a script component to call the report URL to generate the images (TIFF)

We used this (this) to output the info to another XML file format for BizTalk to pick up and send info to trading partner.

Tips:

We have the report server set up in SharePoint integrated mode. The trick is to go into the SharePoint Administration site and find where the site is pointing to as the Report Server. Once you find that, then the report URL to call is just:

[Report Server location in SharePoint Administration Site/ Integration settings]?[full path (starting with http) to the report RDL including the extension]&rs:Command=Render&rs:Format=PDF&ClaimID=[whatever claim ID that is passed in]

If you want TIFF as output, then use rs:Format=IMAGE

Benefit:

The client can stick to MS SQL Standard edition. This represents a savings of hundreds of thousands of dollars!
There is really no good way to pass in a dynamically generated value to a variable in a RS report.
We can schedule the report to run in the off business hours.

Performance issue with SharePoint Services 3.0 and SQL Reporting Services 2008 in integration mode

LifeLongTechie — Thu, 29 Oct 2009 07:34:34 GMT

I'm having an issue here at a client site. The report we designed runs fairly quickly in DEV, it takes 8 seconds for the report to render. We now have the report deployed to the production SharePoint site and it's taking 1 minutes 8 seconds to load.

Both reports point to the same database, so there is no difference on the data side. It's past 5 PM here so there is nobody on the SharePoint site, either. There is a slight difference in the hardware: the prod has 0.5 GB less available memory than DEV, but has dual-core CPU while DEV is single.

The report doesn't even deal with a lot of data. It's about 2000 records and 180 pages. The stored procedure executes in 2 seconds. There is almost no data manipulation on the report; there are some group sum calculations, but that's it.

One thing we find interesting is that executing on DEV resulted in 100% CPU usage, while it barely made a blip on either core of the CPU on prod. So I started to wonder whether there is a setting to elevate the priority of the reporting services executables.

Appreciate any thought or suggestion.