Showing posts with label SSRS. Show all posts
Showing posts with label SSRS. Show all posts

Sunday, June 30, 2013

Reporting Services Script File

The reporting services rs utility (RS.exe), utility processes script you provide in an input file. Developers and report server administrators can perform operations on a report server through the use of the rs utility (RS.exe). Using this utility, you can programmatically administer a report server using Visual Basic .NET scripts. 
Reporting Services scripts can be used to run any of the Reporting Services Web service operations. Script files take a certain format and are written in Visual Basic .NET. Scripting can be used to copy security to multiple reports on a server, to add and delete items, to copy report server items from one server to another and more.
RS.exe is located at \Program Files\Microsoft SQL Server\110\Tools\Binn folder.  
To run the tool, you must have permission to connect to the report server instance you are running the script against. You can run scripts to make changes to the local computer or a remote computer.
Reporting Services Script File
A Reporting Services script is a Visual Basic .NET code file, written against a proxy that is built on Web Service Description Language (WSDL), which defines the Reporting Services SOAP API. A script file is stored as a Unicode or UTF-8 text file with the extension .rss.
The script file acts as a Visual Basic module and can contain user defined procedures and module-level variables. For the script file to run successfully, it must contain the Main procedure. The Main procedure is the starting point for your script file, and it is the first procedure that is accessed when your script file runs. Main is where you can add your Web service operations and run your user defined subprocedures. The minimum structure you need to execute a report server script file is the Main procedure.
Sample script.rss file:
Public Sub Main()
    Dim items() As CatalogItem
    items = rs.ListChildren("/", True)

    Dim item As CatalogItem
    For Each item In items
        Console.WriteLine(item.Name)
    Next item
End Sub 
To run Script.rss in the script environment specifying a user name and password for authenticating the Web service calls: 
rs –i Script.rss -s http://servername/reportserver -u myusername -p mypassword
Above script.rss file will list all children of a root (/) folder.

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.