SSRS cascading report parameters using MDX queries

SSRS report parameters cascading is a regular usability requirement. In this tutorial, I will demonstrate how to proceed using MDX queries. The background to this is, that the default queries generated by the SSRS wizards are far below the standard we wish to deliver. Let’s dive in using the famous Multidimensional AdventureWorks DW OLAP Project.

Lets start by creating a Dataset for the first parameter in the cascade. Start in the Dataset Query designer as shown below.

QueryDesigner1

The MDX query I used is like this:

WITH
MEMBER [Measures].[ParCaption] AS [Product].[Category].CURRENTMEMBER.MEMBER_CAPTION
MEMBER [Measures].[ParValue] AS [Product].[Category].CURRENTMEMBER.UNIQUENAME

SELECT
{[Measures].[ParCaption], [Measures].[ParValue]} ON COLUMNS,
[Product].[Category].ALLMEMBERS ON ROWS
FROM [Adventure Works]

Next step is actually creating these report parameters, the first Parameter P_ProductCategory should be set like this:

Parameter_1

Parameter_2

The second parameter needs to be created exactly the same way once you prepare its Dataset as described in the next step.

Continue by creating another SSRS Dataset used for the second parameter P_ProductSubcategory in the cascade. This parameter value gets calculated on the fly as you pick the first parameter value.

WITH
MEMBER [Measures].[ParCaption] AS [Product].[Subcategory].CURRENTMEMBER.NAME
MEMBER [Measures].[ParValue] AS [Product].[Subcategory].CURRENTMEMBER.UNIQUENAME

SELECT
{[Measures].[ParCaption], [Measures].[ParValue]} ON COLUMNS,
[Product].[Subcategory].[Subcategory] ON ROWS
FROM [Adventure Works]
WHERE STRTOSET(@P_ProductCategory)

Notice the STRTOSET function. In case we would look for a boolean value, we could use STRTOMEMBER instead. In case we would look for multiple parameters, you would write WHERE ( STRTOSET(@P_ProductCategory), STRTOMEMBER(@ProductBooleanParameter) )

To make this work, we need to set the parameters of the second Dataset like this:

Dataset_Report

Notice you might run into an error (actually a VS bug) when writing the MDX query related to the Dataset in the query editor saying  “The query contains the XXXXXName parameter, which is not declared.” In that case, review the forum here but the solution is rather quick. Spoiler: Look for the Query Parameters icon in the top menu ( highlighted in orange box in the Query designer printscreen in the first screenshot from above) and set your parameters for the first time manually with some default value as well, that should make things work here.

Next step is creating the result dataset for the SSRS Report matrix. The query I used is trivial and is set like this:

SELECT (
[Product].[Category].[Category],
[Product].[Subcategory].[Subcategory],
[Product].[Product].[Product]) ON ROWS,
[Measures].[Order Count] ON COLUMNS
FROM (
SELECT (STRTOSET(@P_Product_Category), STRTOSET(@P_Product_Subcategory)) ON COLUMNS
FROM [Adventure Works]
)

Notice here, that in MDX you cannot use the same dimension hierarchy more then once, so you cannot use it in the SELECT and WHERE at the same time. This is the reason I decided to go for a Sub-Select, but there are many other options you can easily find on the internet. And here you go, after choosing Bikes and Clothing in the Product Category Parameter, you get only the relevant Product Subcategories, below are few screenshots of the simple SSRS Report:

Parameter_3

Report

sp_testlinkedserver in a try…catch block

Sometimes you definitely need to go with quick workarounds. I am pretty much sure I am not the only BI developer working from time to time with legacy and somehow wacky old code used for production purposes. This time I came across a legacy scheduled stored procedure filling a dataset for SSRS reporting purposes calling openrowset to run MDX query against an OLAP cube but the linked server was failing from time to time because of the weak connections. Whenever the linked server call would fail, there would be simply no reporting as the MDX results were later used in an INNER JOIN 🙂 . I kind of wonder what did the people writing this code thought back then. Anyway I needed this SP to stop failing and to have results even if the linked server connection would fail and to be informed that the linked server call failed so I could react and persist the results from the last successful run.

The solution is quite easy and so far seems bullet proof. Lets use this sample MDX code enveloped in an openrowset for example:

SELECT a.*
FROM OpenRowset( 'MSOLAP','DATASOURCE=myOlapServer; Initial Catalog=FoodMart;',
'SELECT Measures.members ON ROWS,
[Product Category].members ON COLUMNS
FROM [Sales]')
as a
GO

So the trick is to add this chunk of code after sp_testlinkedserver which tests if we are able to connect to the specified linked server and we need to run this together in the try block. Also we might want to set the variable @err to know that an error happened. The code could look something like this:


DECLARE @err BIT = 0;

BEGIN TRY
EXEC sp_testlinkedserver N'MSOLAP';

SELECT a.*
INTO #results
FROM OpenRowset( 'MSOLAP','DATASOURCE=myOlapServer; Initial Catalog=FoodMart;',
'SELECT Measures.members ON ROWS,
[Product Category].members ON COLUMNS
FROM [Sales]' )
as a;

END TRY

BEGIN CATCH
SET @err = 1;
END CATCH

IF @err = 1
BEGIN
--FOR EXAMPLE USE AND PERSIST RESULTS FROM THE LAST TIME THE SP WAS EXECUTED..
END

Disclaimer: This is just a quick fix tutorial, I definitely agree this is not the best example of using
the try…catch block. Details on sp_testlinkedserver can be easily found here.

Build your own Data quality framework part 3/3

And here we are , at the final part of this tutorial. This third part is going to be mainly about the Data quality issue fixing and possible reporting layers. I have been working with this framework in an environment, where we’ve had SSRS reports embedded in a .NET web application. The links in the SSRS subreports for each Data quality rule would navigate you onto the specific business objects in the application and there you would fix the errors. That’s the part where I find this solution really straightforward and powerful. If you’re in a completely different setup environment, you can possibly write your own simple web page for the error fixing module or you can come up with any other possible UI you can think of. The same with the reporting module. I have used a simple SSAS Tabular model with Excel sheets pushed onto the internal Sharepoint site, but you can really go in any possible direction you can think of.

So once you have the DQ schema tables filled with rules and their results, you can easily create an SSRS report dashboard  ( dataset joining dql.ValidationResult and dql.ValidationRun tables ) looking something like this for example:

Untitled Diagram (4)

The datasets for this report are a piece of cake to come up with when you think about the data model we have from the second part of this tutorial. You can use for example:


DECLARE @CurrValidationRun_ID INT;
SELECT @CurrValidationRun_ID = ISNULL(MAX(ValidationRun_ID),0) FROM dql.ValidationRun WHERE ValidationRunEnd IS NOT NULL;
DECLARE @PrevValidationRun_ID INT = @CurrValidationRun_ID - 1;

SELECT
VR.ValidationRule_ID,
VR.ValidationRuleName,
(SELECT VRP.ValidationErrorCount FROM dql.ValidationResult VRP WHERE VRP.ValidationRun_ID = @PrevValidationRun_ID AND VRP.ValidationRule_ID = VR.ValidationRule_ID) AS PrevErrorCount,
(SELECT VRP.ValidationErrorCount FROM dql.ValidationResult VRC WHERE VRC.ValidationRun_ID = @CurrValidationRun_ID AND VRC.ValidationRule_ID = VR.ValidationRule_ID) AS CurrentErrorCount
FROM dql.ValidationRule VR;

or you can use CROSS APPLY or what ever technique you are the most comfortable with. The Data quality rule column in the table should be a link to a subreport containing the specific rule errors with links to the CRM application business objects.

When it comes to the drill down into the subreports, you need to query the dql.ValidationResultItem table but you are facing one issue here. As you’ve seen, I have used 6 ResultCol columns for the results and in the Contact with multiple invoicing addresses example you have 6 columns filled with data. But what if you had used less than 6 columns in some rules? So how can you prepare the report column layout in the specific rule results subreport? The same problem is with the SSRS matrix / table column headers. I leave this part up to your imagination.

You can go with a simplistic approach, show all 6 columns in the table report layout and have the column visibility and column header value based on some Data quality rule – specific configuration and solve this issue with an lookup expression. You could also choose a more technical approach and build dynamic SQL statements using the Data quality query metadata and prepare a dataset for a matrix style report with some pivoting / unpivoting. I would not go into more details here as everyone is working in an different environment and this is really the fun part where you can spend some time evaluating the best available options. I leave the reporting for Management up to you as well. It is really the fun part where sky is the limit and the solution is totally based on your preferences.

Conclusion:

This lightweight Data quality framework can be considered pretty easy to build yet very powerful. You can further expand the functionality in many ways. You can even make this framework call available Datasets used for example for addresses cleaning and have some auto corrections being done. You should not forget about row-level security , so the users cannot touch each others owned business entities. But the main thought behind this is to provide the users an easy to use interface through which they can easily fix the Data quality issues that they are responsible for. Just remember to keep it simple and well performing!

SSRS reports personalisation

I would like to talk here about SSRS reports personalisation. The point is, that there are situations, when you feel you could do a little more to ease the use in some specific reports.

For example you have 20 additional columns and you can show or hide these columns based on what the user chose to see last time. Obviously this solution must also contain a parameter listing all the possible columns called ShowFields. Now we know, that SSRS 2008 lets you receive parameterized reports based on subscription to reports that run on demand. When you subscribe to a report that runs on a snapshot basis, your subscription must use the parameters values defined in the snapshot. But what if you cannot use subscriptions ?

I came across 2 scenarios when report subscription was not possible. One was, that you had an browser based CRM / ERP type application which used embedded SSRS reports running from an Iframe in the app and the second was that you might have had an custom build container-browser for SSRS reports project. Personally I dont feel these options are that rare, as both mentioned were used at my last employer, and the second mentioned, the custom build container for SSRS reports was an front-end to a pretty robust financial Data Warehouse solution.

So what will be the steps in this process?

1.If the user runs the report for the first time, the ShowFields multi-valued report parameter shows all column names for this report, user might change the values chosen in the ShowFields parameter and they are being sent with SSRS global variables Windows login of the user and the report name to the stored procedure ReportColumnParameterCache_DeleteInsert residing at the end of the stored procedure displaying this report dataset

2.This SP deletes the cache from last time and inserts the current values

3.Next time the user runs the report, the ShowFields multi-value parameter default values are being filled from an UDF retrieving cached results for the current user and the current report

4.The process is repeated except that now the parameter contains fields chosen by the user last time

Let me guide you through the steps needed to accomplish this report personalization. Lets start with some DB back-end stuff. I remember when I was developing this solution, I prepared an report -level configuration table rpt.Report holding Report_ID INT set as identity column , ReportName, ReportDescription, IsActive flag and IsVisible flag ( for report listing in the application purposes – this way you could really quickly state that the report is under construction, is obsolete etc. ). The sky is the limit here. The second configuration table rpt.ReportColumn would be used for report column configuration holding ReportColumn_ID INT as Identity, Report_ID from the rpt.Report table, ReportColumnName, IsActive flag,  IsVisible flag for country-specific purposes ( when a column might be never needed for users from some country in a multi-country enviroment ) and IsAdditional flag determining whether this column is an additional or a non-additional column. The next step might be a little bit time consuming as you must fill these tables with values , but you can come up with some clever string concatenation generating insert statements in Excel.

Now you need to create a table holding the report parameter cache. It must be a quick and a narrow one for some solid performance. I called mine rpt.ReportColumnParameterCache and it had just ReportColumnParameterCache_ID as an Identity column, ReportColumn_ID, and the Windows user login UserID named ReportUser NVARCHAR(100) column. MSDN describes UserID as The ID of the user running the report. If you are using Windows Authentication, this value is the domain account of the current user. The value is determined by the Reporting Services security extension, which can use Windows Authentication or custom authentication. 

image001

And what are the next steps? We have to create a stored procedure ( lets name it rpt.ReportColumnParameterCache_DeleteInsert ) which has input parameters from SSRS report parameters UserID, ReportName (global variables) and ColumnNames ( ColumnNames would look like Column1,Column2,Column3 coming from the ShowFields report multi-valued parameter explained in the next paragraph) . Firstly this SP would delete your login-related cache for this report from the last time. I remember doing some basic measurements using time statistics and the scenario with deleting and inserting the cache rows was a little bit faster in my enviroment then any other option available. In the next step, this SP would transform the ReportName to the Report_ID from rpt.Report and then the ColumnNames into ReportColumn_IDs using a table value UDF and an inner join to the rpt.ReportColumn based on ReportColumnName and ReportName. Here are some examples how to implement a custom split-string function or in case you are lucky and already using MSSQL 2016, you can go with the internal SPLIT_STRING function. In the last step, this SP would insert these values into the rpt.ReportColumnParameterCache table. This SP has to be located at the end of the stored procedure used for retrieving the data into the report main dataset.

On the SSRS side, we need to create a report parameter holding multiple string values called ShowFields. This parameter should have available values fulfilled from a query showing available columns for this Report. The default values would be the values you have stored in your ReportColumnParameterCache table for your Windows login and this report, so in this case, it would be the result of a function containing a select, where the ReportUser value equals your Windows login (globals!UserID) and the ReportName (globals!ReportName) equals the value in the rpt.Report table.

The last step is to set the affected columns visibility in the SSRS report table / matrix based on a formula saying something like:

=iif(instr(Join(Parameters!ShowFields.Value,”, “) ,”Column1″) <> 0 and instr(Join(Parameters!ShowFields.Value,”, “) ,”None”) = 0,false,true)