Monday, October 29, 2012

Understanding the SQL Server Reporting Services

History of Reporting Services:
Initial development began in 2000. Below Figure-1 tracks in chronological order the major events that have shaped Reporting Services. The black milestones represent the reporting technologies that Microsoft acquired to enhance Reporting Services.
Figure-1 : The Reporting Services history
Components of Reporting Servies:
  • Report Server : At the heart of the Reporting Services architecture is the report server, a web-based middle-tier layer that receives incoming report requests and generates reports. The Figure-2 shows a simplified logical view of the report server. To facilitate integration with external client applications, the report server provides two communication interfaces: URL access and a Web service. Consequently, both off-the-shelf and custom tools can communicate with the report server via HTTP or SOAP. The Report Processor component of the report server is responsible for processing the reports at run time.
Figure-2 : The major Reporting Services components
  • Report Server Database : In Reporting Services, report definitions and properties are saved in the report server database. The report server database is implemented as two SQL Server databases that get installed when you configure the report server. The report server database is a logical term for two physical databases: ReportServer and ReportServerTempDB. The ReportServer database hosts the report catalog. It stores the report definitions and management settings. The ReportServerTempDB stores temporary information about the report execution.
Reporting Services supports two deployment modes.
  • Native mode (default) : The report server as a stand-alone application server that provides all processing and management capability exclusively through Reporting Services components.
  • SharePoint mode : The report server is integrated with Windows SharePoint Services or Microsoft Office SharePoint Server. Report viewing and management happens inside the SharePoint portal.
Report Definition Language (RDL) is an XML-based schema for defining reports. RDL is an open standard proposed by Microsoft to promote interoperability of commercial reporting products.
Reporting Services Architecture:
Figure-3 : The Reporting Services Service hosts the three report server applications: Report Manager, Report Server Web Service, and Background Processor
  • Report Manager : Report Manager is an ASP.NET web application that provides report management and viewing capabilities for a Reporting Services instance configured in native mode. You can view Report Manager as a client application that integrates with the report server.
  • Report Server Web Service : The Report Server Web service handles on-demand report processing. The Report Server Web service is the primary programmatic interface for custom applications that integrate with Reporting Services. The Report Server Web service provides four Web service endpoints that expose the Reporting Services feature set to external clients.
  • Background Processor : The Background Processor application is responsible for handling all tasks that run in an unattended mode.

Tuesday, October 16, 2012

SSIS: Read customized configuration data from SQL table to multiple package variables

Microsoft SQL Server Integration Services provides multiple ways to configure the package. These package configuration types are as below:
  • XML configuration file
  • Environment variable
  • Registry entry
  • Parent package variable
  • SQL server
If you select the SQL Server configuration type, a default "SSIS Configurations" table will be used to store the configurable data. But sometime you need to use customized configurable table, which SSIS does not support for automatic configuration. So below solution can be one of the way of implementation:
Lets consider our configurable table is as below:
And list of our SSIS package variables as belw:
Here variables "V_SCHEMA_NAME", "V_SCHEMA_RESULTSET" and "V_SCHEMA_ROW" are used internally for looping and data storage.
Below are the steps to create a SSIS package to read the confiuration values from SQL server table into our SSIS package variables.
Steps:
1. Add "Execute SQL Task" and set the properties as below:
Tab Properties Value
General Name Execute SQL Task - Get Schema List
ResultSet Full result set
ConnectionType ADO.NET
Connection SSISTest
SQLSourceType Direct input
SQLStatement SELECT DISTINCT [SCHEMA_NAME] FROM [dbo].[CFG_SCHEMA_CONN] WHERE [ISACTIVE] = 1
Result Set Result Name 0
VariableName User::V_SCHEMA_RESULTSET
2. Add "Foreach Loop Container" and set the properties as below:
Tab Properties Value
General Name Foreach Loop Container - Loop through each Schema
Collection Enumerator Foreach ADO Enumerator
ADO object source variable User::V_SCHEMA_RESULTSET
Enumeration mode Rows in the first table
Variable Mappings Variable User::V_SCHEMA_NAME
Index 0
3. Add "Execute SQL Task" inside the foreach loop container and set the properties as below:
Tab Properties Value
General Name Execute SQL Task - Get data for schema
ResultSet Full result set
ConnectionType ADO.NET
Connection SSISTest
SQLSourceType Direct input
SQLStatement SELECT [REPORT_CONN_STR], [PROD_CONN_STR] FROM [dbo].[CFG_SCHEMA_CONN] WHERE [SCHEMA_NAME] = @SCHEMA_NAME
Parameter Mappings Variable Name User::V_SCHEMA_NAME
Direction Input
Data Type String
Parameter Name @SCHEMA_NAME
Parameter Size -1
Result Set Result Name 0
Variable Name User::V_SCHEMA_ROW
4.Add "Script Task" inside the foreach loop container and set the properties as below:
Tab Properties Value
General Name Script Task - Store data in package variable
Script ScriptLanguage Microsoft Visual C# 2008
EntryPoint Main
ReadOnlyVariables User::V_SCHEMA_NAME,
User::V_SCHEMA_ROW
ReadWriteVariables User::V_SCHEMA1_PROD_CONN_STR,
User::V_SCHEMA1_REPORT_CONN_STR,
User::V_SCHEMA2_PROD_CONN_STR,
User::V_SCHEMA2_REPORT_CONN_STR,
User::V_SCHEMA3_PROD_CONN_STR,
User::V_SCHEMA3_REPORT_CONN_STR,
User::V_SCHEMA4_PROD_CONN_STR,
User::V_SCHEMA4_REPORT_CONN_STR,
User::V_SCHEMA5_PROD_CONN_STR,
User::V_SCHEMA5_REPORT_CONN_STR
Edit Script public void Main()
{
try
{
DataSet ds = Dts.Variables["V_SCHEMA_ROW"].Value as DataSet;

if (ds != null && ds.Tables.Count > 0 && ds.Tables[0].Rows.Count > 0)
{
DataRow dr = ds.Tables[0].Rows[0];

string schemaRptConnStr = Dts.Variables["V_SCHEMA_NAME"].Value.ToString() + "_REPORT";
string schemaProdConnStr = Dts.Variables["V_SCHEMA_NAME"].Value.ToString() + "_PROD";

foreach (Variable v in Dts.Variables)
{
if (v.Namespace.Equals("User") && v.Name.Contains(schemaRptConnStr))
{
v.Value = dr[0].ToString();
}
if (v.Namespace.Equals("User") && v.Name.Contains(schemaProdConnStr))
{
v.Value = dr[1].ToString();
}
}
}

Dts.TaskResult = (int)ScriptResults.Success;
}
catch
{
Dts.TaskResult = (int)ScriptResults.Failure;
}
}
The SSIS package will look like as below:

Monday, October 15, 2012

Creating YTD Calulation using MDX

Ytd function returns a set of sibling members from the same level as a given member, starting with the first sibling and ending with the given member, as constrained by the Year level in the Time dimension.
And
PeriodsToDate function returns a set of sibling members from the same level as a given member, starting with the first sibling and ending with the given member, as constrained by a specified level in the Time dimension.
One of these function can be used for YTD calculation in MDX queries.
Prior to use of these funtion, please check your Time Dimesion as below:
1. Time dimension attributes should have properites as shown below:
2. Time dimension should have hierarchies specified.
3. Time dimension should also have attribute relationships specified.
Now, you can add the calculated members within the cube to get the Year-to-date values, as below:

New Calulated Member
Name : [YTD Amount]
Parent hierarchy: Measures
Expression: SUM(PERIODSTODATE([Dim Time].[Fiscal].[Fiscal Year], [Dim Time].[Fiscal].CURRENTMEMBER),[Measures].[Amount])