Creating and Using Silverlight and WPF User Controls

One of the fundamental design goals of Silverlight and WPF is to enable developers to be able to easily encapsulate UI functionality into re-usable controls.

You can implement new custom controls by deriving a class from one of the existing Control classes (either a Control base class or from a control like TextBox, Button, etc). Alternatively you can create re-usable User Controls - which make it easy to use a XAML markup file to compose a control's UI (and which makes them super easy to build).

In Part 6 of my Digg.com tutorial blog series I showed how to create a new user control using VS 2008's "Add New Item" project item dialog and by then defining UI within it. This approach works great when you know up front that you want to encapsulate UI in a user control. You can also use the same technique with Expression Blend.

Taking Existing UI and Encapsulating it as a User Control

Sometimes you don't always know you want to encapsulate some UI functionality as a re-usable user control until after you've already started defining it on a parent page or control.

For example, we might be working on a form where we want to enable a user to enter shipping and billing information. We might begin by creating some UI to encapsulate the address information. To-do this we could add a control to the page, nest a grid layout panel inside it (with 2 columns and 4 rows), and then place labels and textbox controls within it:

After carefully laying it all out, we might realize "hey - we are going to use the exact same UI for the billing address as well, maybe we should create a re-usable address user control so that we can avoid repeating ourselves".

We could use the "add new item" project template approach to create a blank new user control and then copy/paste the above UI contents into it.

An even faster trick that we can use within Blend, though, is to just select the controls we want to encapsulate as a user control in the designer, and then "right click" and choose the "Make Control" menu option:

When we select the "Make Control" menu item, Blend will prompt us for the name of a new user control to create:

We'll name it "AddressUserControl" and hit ok. This will cause Blend to create a new user control that contains the content we selected:

When we do a re-build of the project and go back to the original page, we'll see the same UI as before - except that the address UI is now encapsulated inside the AddressUserControl:

We could name this first AddressUserControl "ShippingAddress" and then add a second instance of the user control to the page to record the billing address (we'll name this second control instance "BillingAddress"):

And now if we want to change the look of our addresses, we can do it in a single place and have it apply for both the shipping and billing information.

Data Binding Address Objects to our AddressUserControl

Now that we have some user controls that encapsulate our Address UI, let's create an Address data model class that we can use to bind them against. We'll define the class like below (taking advantage of the new automatic properties language feature):

Within the code-behind file of our Page.xaml file we can then instantiate two instances of our Address object - one for the shipping address and one for the billing address (for the purposes of this sample we'll populate them with dummy data). We'll then programmatically bind the Address objects to our AddressUserControls on the page. We'll do that by setting the "DataContext" property on each user control to the appropriate shipping or billing address data model instance:

Our last step will be to declaratively add {Binding} statements within our AddressUserControl.xaml file that will setup two-way databinding relationships between the "Text" properties of the TextBox controls within the user control and the properties on the Address data model object that we attached to the user control:

When we press F5 to run the application we'll now get automatic data-binding of the Address data model objects with our AddressUserControls:

Because we setup the {Binding} declarations to be "Mode=TwoWay", changes users make in the textboxes will automatically get pushed back to the Address data model objects (no code required for this to happen).

For example, we could change our original shipping address in the browser to instead go to Disneyland:

If we wire-up a debugger breakpoint on the "Click" event handler of the "Save" button (and then click the button), we can see how the above TextBox changes are automatically reflected in our "_shippingAddress" data model object:

We could then implement the SaveBtn_Click event handler to persist the Shipping and Billing Address data model objects however we want - without ever having to manually retrieve or manipulate anything in the UI controls on the page.

This clean view/model separation that WPF and Silverlight supports makes it easy to later change the UI of the address user controls without having to update any of our code in the page. It also makes it possible to more easily unit test the functionality (read my last post to learn more about Silverlight Unit Testing).

Summary

WPF and Silverlight make it easy to encapsulate UI functionality within controls, and the user control mechanism they support provides a really easy way to take advantage of this. Combining user controls with binding enables some nice view/model separation scenarios that allow you to write very clean code when working with data.

You can download a completed version of the above sample here if you want to run it on your own machine.

Dynamic LINQ (Part 1: Using the LINQ Dynamic Query Library)

LINQ (language integrated query) is one of the new features provided with VS 2008 and .NET 3.5. LINQ makes the concept of querying data a first class programming concept in .NET, and enables you to efficiently express queries in your programming language of choice.

One of the benefits of LINQ is that it enables you to write type-safe queries in VB and C#. This means you get compile-time checking of your LINQ queries, and full intellisense and refactoring support over your code:

While writing type-safe queries is great for most scenarios, there are cases where you want the flexibility to dynamically construct queries on the fly. For example: you might want to provide business intelligence UI within your application that allows an end-user business analyst to use drop-downs to build and express their own custom queries/views on top of data.

Traditionally these types of dynamic query scenarios are often handled by concatenating strings together to construct dynamic SQL queries. Recently a few people have sent me mail asking how to handle these types of scenarios using LINQ. The below post describes how you can use a Dynamic Query Library provided by the LINQ team to dynamically construct LINQ queries.

Downloading the LINQ Dynamic Query Library

Included on the VS 2008 Samples download page are pointers to VB and C# sample packages that include a cool dynamic query LINQ helper library. Direct pointers to the dynamic query library (and documentation about it) can be found below:

• VB Dynamic Query Library (included in the \Language Samples\LINQ Samples\DynamicQuery directory)
• C# Dynamic Query Library (included in the \LinqSamples\DynamicQuery directory)

Both the VB and C# DynamicQuery samples include a source implementation of a helper library that allows you to express LINQ queries using extension methods that take string arguments instead of type-safe language operators. You can copy/paste either the C# or VB implementations of the DynamicQuery library into your own projects and then use it where appropriate to more dynamically construct LINQ queries based on end-user input.

Simple Dynamic Query Library Example

You can use the DynamicQuery library against any LINQ data provider (including LINQ to SQL, LINQ to Objects, LINQ to XML, LINQ to Entities, LINQ to SharePoint, LINQ to TerraServer, etc). Instead of using language operators or type-safe lambda extension methods to construct your LINQ queries, the dynamic query library provides you with string based extension methods that you can pass any string expression into.

For example, below is a standard type-safe LINQ to SQL VB query that retrieves data from a Northwind database and displays it in a ASP.NET GridView control:

Using the LINQ DynamicQuery library I could re-write the above query expression instead like so:

Notice how the conditional-where clause and sort-orderby clause now take string expressions instead of code expressions. Because they are late-bound strings I can dynamically construct them. For example: I could provide UI to an end-user business analyst using my application that enables them to construct queries on their own (including arbitrary conditional clauses).

Dynamic Query Library Documentation

Included with the above VB and C# Dynamic Query samples is some HTML documentation that describes how to use the Dynamic Query Library extension methods in more detail. It is definitely worth looking at if you want to use the helper library in more depth:

Download and Run a Dynamic Query Library Sample

You can download and run basic VB and C# samples I've put together that demonstrate using the Dynamic LINQ library in an ASP.NET web-site that queries the Northwind sample database using LINQ to SQL:

• Basic Dynamic LINQ VB Sample
• Basic Dynamic LINQ C# Sample

You can use either Visual Web Developer 2008 Express (which is free) or VS 2008 to open and run them.

Other Approaches to Constructing Dynamic LINQ Queries

Using the dynamic query library is pretty simple and easy to use, and is particularly useful in scenarios where queries are completely dynamic and you want to provide end user UI to help build them.

In a future blog post I'll delve further into building dynamic LINQ queries, and discuss other approaches you can use to structure your code using type-safe predicate methods (Joseph and Ben Albahari, authors of the excellent C# 3.0 In a Nutshell book, have a good post on this already here).

Table Partitioning in Sql server

Table partitioning is the concept introduced in sql server 2005. Its used to enhance faster database accessibility.
It may be either Horizontal partitioning or Vertical partitioning.
Horizontal Partitioning:In this type, the rows will be segregated as two tables (Old table and new table). Its a logical seperation placed in different file groups.If i want to access most recent data frequently when compared to old data then horizontal partitioning paves the way for this. It's highly advisable to implement this concept in multi processor environment.Schema remains the same in horizontal partitioning.
Vertical partitioning:Its nothing but segregating the columns of the table, part of the column in one table and other part of the column in other table(in case of partitioning into two tables).

Table valued parameters

It's a new T-SQL enhancements done in sql server 2008 which allows us to pass the table as parameters for our stored procedure. In the client server architecture we used to pass individual rows from the front end and its get updated in the backend. Instead of passing individual rows, Microsoft released a new enhancement referred to as table value parameters where they are providing a flexibility to pass the table as a parameter from the front end.


Features:
1. Processing speed will be comparitively very faster.
2. We have to declare the table as a Readonly one. DML operations cannot be done on the table.
3. From the front end we have to pass the data in the form of structures.
4. Reduces roundtrip to the server
5. Processes complex logics at a stretch in one single routine.


-- Am trying to create a table "EmployeeTable" with three fields.
CREATE TABLE EmployeeTable
(id int,
[name] varchar(100),
designation varchar(100))

-- Creating a stored procedure "TableValuedSampleProc" to insert the rows.
CREATE PROCEDURE TableValuedSampleProc (@id int, @name varchar(100),@designation varchar(100))
AS
BEGIN
insert into EmployeeTable values (@id,@name,@designation)
END
-- Executing the stored procedure
EXEC TableValuedSampleProc 1,'one','manager'
EXEC TableValuedSampleProc 2,'two','sr tlr'
EXEC TableValuedSampleProc 3,'three','tlr'
SELECT * FROM EmployeeTable
-- Am trying to create a table type "EmployeeTableType"
CREATE TYPE EmployeeTableType AS TABLE
(ID int, [name] varchar(100),designation varchar(100))
-- Creating the stored procedure in insert the data using Table type.
CREATE PROCEDURE EmployeeTableTypeProc (@EmployeeTempTable EmployeeTableType READONLY)
AS
BEGIN
INSERT INTO EmployeeTable
SELECT * FROM @EmployeeTempTable
END
-- Building a temporary table type
DECLARE @TempEmployee EmployeeTableType
INSERT INTO @TempEmployee VALUES (1,'one','manager')
INSERT INTO @TempEmployee VALUES (2,'two','sr tlr')
INSERT INTO @TempEmployee VALUES (3,'three','tlr')
-- Executing the stored procedure by passing the temporary table type
EXEC EmployeeTableTypeProc @TempEmployee
-- Checking the existence of data
SELECT * FROM EmployeeTable

pivot table

One of the most requested pieces of code on the Internet forums about SQL Server these days, is the code for making a crosstab query. There was no native support for that in version 6.5. Not even version 7.0 or version 2000 had this support.
So when Microsoft announced that SQL 2005 would support crosstab queries we all (well, at least me) cheered and anticipated that this should solve a number of difficulties. Many of us have worked with MS Access since version 2.0, and in this application, pivot tables are breazes.



declare @SQLTable1 table (id int,Studentname varchar(100))
declare @SQLTable2 table (id int,Marks int)
-- inserting the data into the table variables
insert into @SQLTable1
select '1','one' union all
select '2','two' union all
select '3','three' union all
select '4','four'
insert into @SQLTable2
select '1','90' union all
select '1','20' union all
select '1','80' union all
select '2','78' union all
select '2','67' union all
select '3','89' union all
select '3','65' union all
select '3','98' union all
select '4','78' union all
select '4','76' union all
select '4','45'
select * from @SQLTable1
select * from @SQLTable2
--Creating rownumber in the cte
;with lakshmi as(
select a.id,a.Studentname, b.Marks,
row_number() over ( partition by a.id order by a.id) as rn
from @SQLTable1 a inner join @SQLTable2 b on a.id=b.id
)
--select * from VenkatCTE
-- pivoting the rows in the cte
select id,Studentname,[1] as Subject1,[2] as Subject2,[3] as Subject3
from lakshmi
pivot
(
min(Marks) for rn in ([1],[2],[3])
)
pvt
order by id

Undocumented Stored Procs

sp_MSgetversion

This extended stored procedure can be used to get the current version of Microsoft SQL Server. To get the current SQL Server version, run

EXEC master..sp_MSgetversion

xp_dirtree

This extended stored procedure can be used to get a list of all the folders for the folder named in the xp. To get a list of all the folders in the C:\MSSQL7 folder, run:

EXEC master..xp_dirtree 'C:\MSSQL7'

xp_enum_oledb_providers

This extended stored procedure is used to list of all the available OLE DB providers. It returns Provider Name, Parse Name and Provider Description. To get a list of all OLE DB providers for your SQL Server, run:

EXEC master..xp_enum_oledb_providers

xp_enumcodepages

This extended stored procedure can be used to list of all code pages, character sets and their description for your SQL Server. To get a list of all code pages and character sets, run:

EXEC master..xp_enumcodepages

xp_enumdsn

This extended stored procedure returns a list of all System DSNs and their description. To get the list of System DSNs, run:

EXEC master..xp_enumdsn

xp_enumerrorlogs

This extended stored procedure returns the list of all error logs with their last change date. To get the list of error logs, run:

EXEC master..xp_enumerrorlogs

xp_enumgroups

This extended stored procedure returns the list of Windows NT groups and their description. To get the list of the Windows NT groups, run:

EXEC master..xp_enumgroups

xp_fileexist

You can use this extended stored procedure to determine whether a particular file exists on the disk or not.

Syntax:

EXECUTE xp_fileexist filename [, file_exists INT OUTPUT]

For example, to check whether the file boot.ini exists on disk c: or not, run:

EXEC master..xp_fileexist 'c:\boot.ini'

xp_fixeddrives

This very useful extended stored procedure returns the list of all hard drives and the amount of free space in Mb for each hard drive.

To see the list of drives, run:

EXEC master..xp_fixeddrives

xp_getnetname

This extended stored procedure returns the WINS name of the SQL Server that you're connected to.

To view the name, run:

EXEC master..xp_getnetname

xp_readerrorlog

This extended stored procedure returns the content of the errorlog file. You can find the errorlog file in the C:\MSSQL7\Log directory, by default for SQL Server 7.0.

To see the text of the errorlog file, run:

EXEC master..xp_readerrorlog

xp_regdeletekey

This extended stored procedure will delete an entire key from the registry. You should use it very carefully.

Syntax:

EXECUTE xp_regdeletekey [@rootkey=]'rootkey', [@key=]'key'

For example, to delete the key 'SOFTWARE\Test' from 'HKEY_LOCAL_MACHINE', run:

EXEC master..xp_regdeletekey @rootkey='HKEY_LOCAL_MACHINE', @key='SOFTWARE\Test'

xp_regdeletevalue

This extended stored procedure will delete a particular value for a key in the registry. You should use it very carefully.

Syntax:

EXECUTE xp_regdeletevalue [@rootkey=]'rootkey', [@key=]'key', [@value_name=]'value_name'

For example, to delete the value 'TestValue' for the key 'SOFTWARE\Test' from 'HKEY_LOCAL_MACHINE', run:

EXEC master..xp_regdeletevalue @rootkey='HKEY_LOCAL_MACHINE', @key='SOFTWARE\Test', @value_name='TestValue'

xp_regread

This extended stored procedure is used to read from the registry.

Syntax:

EXECUTE xp_regread [@rootkey=]'rootkey', [@key=]'key' [, [@value_name=]'value_name'] [, [@value=]@value OUTPUT]

For example, to read into the variable @test from the value 'TestValue' from the key 'SOFTWARE\Test' from the 'HKEY_LOCAL_MACHINE', run:

DECLARE @test varchar(20) EXEC master..xp_regread @rootkey='HKEY_LOCAL_MACHINE', @key='SOFTWARE\Test', @value_name='TestValue', @value=@test OUTPUT SELECT @test

xp_regwrite

This extended stored procedure is used to write to the registry.

Syntax:

EXECUTE xp_regwrite [@rootkey=]'rootkey', [@key=]'key', [@value_name=]'value_name', [@type=]'type', [@value=]'value'

For example, to write the variable 'Test' to the 'TestValue' value, key 'SOFTWARE\Test', 'HKEY_LOCAL_MACHINE', run:

EXEC master..xp_regwrite @rootkey='HKEY_LOCAL_MACHINE', @key='SOFTWARE\Test', @value_name='TestValue', @type='REG_SZ', @value='Test'

xp_subdirs

This extended stored procedure is used to get the list of folders for the folder named in the xp. In comparison with xp_dirtree, xp_subdirs returns only those directories whose depth = 1.

This is the example:

EXEC master..xp_subdirs 'C:\MSSQL7'

XML Parsing in c#

XmlTextReader xmlReader = new XmlTextReader(strPath);

int iTab = 0;

// Read the line of the xml file

while (xmlReader.Read())

{

switch (xmlReader.NodeType)

{

case XmlNodeType.Element:

Hashtable attributes = new Hashtable();

// We add the attributes to the hash tables

bool isEmptyElement = false;

PrintWhiteSpace(iTab);

// Print the start of the element

Console.Write("<" + xmlReader.Name);

isEmptyElement = xmlReader.IsEmptyElement;

if (xmlReader.HasAttributes)

{

// If element has attributes

for (int i = 0; i <>

{

xmlReader.MoveToAttribute(i);

attributes.Add(xmlReader.Name, xmlReader.Value);

Console.Write(" " + xmlReader.Name + "=" + xmlReader.Value);

}

}

// Prints the end of the element

if (isEmptyElement == true)

{

Console.WriteLine(" />");

}

else

{

Console.WriteLine(">");

iTab++;

}

break;

case XmlNodeType.EndElement:

iTab--;

PrintWhiteSpace(iTab);

Console.WriteLine("");

break;

case XmlNodeType.Text:

PrintWhiteSpace(iTab);

Console.WriteLine(xmlReader.Value);

break;

default:

break;

}

}

Reporting Services Architecture

we'll look at how Reporting Services is put together. We will walk you through the various processing components, data source extensions, and rendering extensions and take a closer look at how the Reporting Services Web Service works. This chapter also includes a series of illustrations to help you visualize each component.Once you have completed this chapter you will have a good understanding of the Reporting Services "big picture". This knowledge will carry you through the following chapters and help you draw it all together.

This chapter covers:

• The reporting lifecycle
• Reporting Services features
• Report Server components
• Data Processing Extensions
• Delivery extensions
• Report Server databases
• The Reporting Services Web Service
• Report Designer
• Reporting Services tools

THE REPORTING LIFECYCLE

Before digging into the architecture of Reporting Services, you need to understand the fundamentals of reporting lifecycle. Reporting platforms can be evaluated by their support for the following areas—authoring, management, and delivery. We will take a look at what is included in each of these phases and later see how Reporting Services implements them. Take a look at the reporting lifecycle block diagram shown in Figure 2-1:

Authoring

The authoring phase is concerned with the actual development of reports. Authoring generally includes the following features:

• Connecting to a data source
• Writing database queries
• Creating report layout
• Creating report parameters
• Setting report properties such as height and width

These capabilities are important for the initial development of the report. They must be flexible enough to handle diverse reporting needs and structured enough to be easy to use.

Management

After developing the report, you move into the management phase, which is concerned with setting properties of reports specific to the production environment. These properties include:

• Data source connection information
• Default parameter values
• Security permissions
• Report caching
• Report execution schedules
• Report delivery schedules

Management phase is generally performed by the administrators. Most of the user access to reports is defined in this phase.

Delivery

The delivery phase looks at how reports get to the end users. Delivery includes:

• Providing an end user interface for browsing reports
• Publishing reports on a specific schedule
• Delivering reports to end users

A common concept in reporting platforms is push/pull delivery. Push delivery constitutes the reports that are sent to the user. Pull delivery constitutes reports that can be accessed on-demand by the user . Users are required to take the effort to get the report information. The report could be emailed to the requestor of the report, or published to a specified fileshare.


REPORTING SERVICES FEATURES

Having seen the main phases in a reporting platform, let's look at the specific features in Reporting Services that make the three phases of reporting services possible. In this section, we will look at the Report Designer, Reporting Services, and the programming interface, and then move on to the specific components that make these features possible.

Visual Studio .NET 2003 Integration

Any respectable reporting platform must provide report writers with a rich set of design tools. Microsoft has created a designer to do just that. Because of the integration with Visual Studio .NET, users can take full advantage of the established development features. The designer also gives several design options to fulfill the users reporting requirements.

The Report Designer is fully integrated with Visual Studio .NET 2003. Through this integration, the Report Designer can take advantage of a number of established tools. Let's take a closer look at what the designer has to offer.

Query Designer
The query designer allows users to visually create data source queries. It works with multiple data sources and should be familiar to people already working with Microsoft products. Users can graphically drag and drop database objects to create SQL queries. They can also switch to a generic query designer to create freeform queries.

Server Explorer
The Visual Studio .NET Server Explorer allows users to view and work with multiple servers. This is extremely helpful when working with Microsoft SQL Server. Users do not have to switch from the Report Designer to other tools to view database objects. They can simply open the Server Explorer and browse for the specific object.

Visual Source Safe
Visual Studio .NET also integrates with Microsoft Visual Source Safe. Report writers can easily store and maintain the version history of their report files. This can be an invaluable tool when working on both large and small scale reporting projects.

Report Designer
Microsoft has created a couple of new Visual Studio .NET templates that allow you to create Reporting Services Report Projects. These Report Projects give you a graphical interface for creating their report definition. This interface displays the data sources used by the report, the layout of the report and also allows you to preview a report before it is published.

The Report Designer also provides a number of controls to facilitate report writing. You can create table reports, matrices, and freeform lists. The ability to combine these controls gives you even more possibilities.

If you want more control over the actual report definition, you can simply switch to Code view and see the XML generated by the designer. Working with the XML might seem a bit complicated, but when you need to do a search and replace a given word, this can be invaluable. It also lets you see a little more of what is created under the covers. Unlike other proprietary formats, XML allows you to easily read and debug report definitions.

Report Server Features

The Report Server is the main component of Reporting Services. It takes care of all report processing, data access, security, and rendering. For a while now, I have looked for what I truly felt was a service-based application—you hear a lot about it in development circles. I believe Microsoft has hit it on the head with this one. Reporting Services is truly a serviced application. Microsoft has elegantly encapsulated all the reporting functionality into one neat package. In this section we'll take a quick look at what's available.

Central Report Storage
Reporting Services creates one central store for your reports. This eliminates the need to deal with a bunch of messy fileshares. On a recent client engagement, I used it to help consolidate all of their different report areas into a hierarchical structure. This is easily accomplished with features available in Reporting Services. Central storage also makes it much easier for your users to access their reports—no more searching a bunch of directories for the item you want!

Security
In any reporting environment, you will have the need to secure certain items. Reporting Services integrates with Windows security to create a flexible role-based security model. This model allows you to create roles with a number of different permissions. You can then assign Users and Groups to these roles.

Reporting Services security is really the combination of three different items:

• Role definitions: A set number of tasks that can be performed. These include item-level roles which apply to reports, folders, resources, and data sources, and system roles, those that apply to the Report Server site.
• Securable object: Securable objects include reports, folders, resources, data sources, and the Report Server itself.
• Windows users and groups: The combination of a role definition, securable object, and a Windows user/group creates a role assignment. This security model encapsulates the common features needed in a reporting system and gives you the flexibility to adopt it in your organization.

Report Delivery
Once you have created your reports, you will need an easy mechanism to deliver them. Reporting Services follows the standard push/pull model for reports. Push/pull refers to the ways in which a user can access information.

When you go to a web site and view stock quotes, you are pulling information, hence the push/pull part of the model. Users must be able to access information freely. Reporting Services allows users to navigate through the web to see listings of available reports.

Let's say you order a book online from http://www.amazon.com/ (hopefully this book). After you enter your credit card information, email address, and so on, and press Buy, Amazon sends a receipt to your inbox. This is an example of a push report. Email is just one delivery method for push reports. Reporting Services supports both email and fileshare push deployment along with the ability to create your own delivery extensions.

To take maximum advantage of a truly effective reporting system, users should have the ability to grab information when convenient and get information delivered on a regular basis.

Scheduling
Along with being able to deliver reports via email or a fileshare, a reporting system must have some mechanism to send these items on a regular basis. Reporting Services relies on SQL Server Agent schedule and execute given tasks. Scheduling features in Reporting Services allows individual users and administrators to subscribe to reports on a schedule they define.

But, delivering information is not the only area where a scheduling tool comes in handy. If we think about what part of generating a report takes the longest, it is generally the actual retrieval of data. Reporting Services helps you eliminate some of this wait time by scheduling reports to execute (retrieve their data) on a regular schedule. So, if you update your sales information every Sunday, you could easily schedule a report to run early Monday morning. So when users come in on Monday, they'll have quick access to their information.

Programming Interface Features

When selecting a reporting platform, it is crucial to be able to extend that platform and incorporate it in existing systems. Microsoft has provided a web service interface for accomplishing these goals. Through the web service, you have complete access to the Reporting Services platform. Anything from rendering reports to creating subscriptions can be performed programmatically.

Open Architecture
Why did Microsoft use a web service interface? Web services are built on an open architecture. This means you do not need to have Microsoft development technologies to take advantage of them. The key to web services is that they are built on industry standard technologies. Through the use of XML, SOAP, and HTTP just about any platform can call and use web services.

Complete Access
Not only did Microsoft create a platform-neutral programming interface, they also let you do anything you need to through the interface. It is common to work with an API where the developer has limited control over what happens. With Reporting Services, the world is really open to you. If you just don't like the administrative tools that come with Reporting Services, you could write your own.

Most people do not go to this extreme, but it is important to have the flexibility. This means that as an application developer you can add any part of Reporting Services you need into your application. A common example would be creating your own custom interface for rendering reports. You could make it much easier for your users to get the report in exactly the format they want. Another example would be creating your own subscription interface. You might already know the users email information, so they click a few buttons and the subscriptions are done.

The possibilities for using the Reporting Services Web Service are only limited by what the product can do. This should be incredibly good news to all the code junkies out there.

REPORT SERVER COMPONENTS

Now that we have taken a look at what Reporting Services can do, let's get down to the nuts and bolts of how it works. In this section we will focus on the various components of Reporting Services. We'll move through processing of the report and data to rendering and delivering reports.

Report Processor

Report processing is the main driver in the Report Server. The Report Processor is responsible for handling user requests and returning the appropriate report and data. Along with this task it also performs caching of reports to improve performance. Let's take a look at the individual components that constitute report processing.

The main job of the Report Processor is to combine the report definition and report data to create and return this data.

Report Request Handling
When a report request is received, the report processor takes the following steps:

1. It determines which report is being asked for and retrieves the report definition from the Report Server database.



2. The report processor asks for the report data. This is a call made into the data processing extensions (more on this in a moment).



3. The Report Server combines the two into an intermediate format. The intermediate format is then sent to the rendering extensions for delivery.

Report Definition
The report definition is an output format and a neutral representation of the report. Reporting Services was designed to support numerous output formats, so the report definition is not aware of how the report will actually be rendered. The report definition defines the query and layout of a report. These are things like the tables contained in the report, their position in the report, and number of columns. The query information is then used to retrieve data and to combine it with the layout. Once the report definition and data are combined, they form an intermediate format.

Intermediate Format
The intermediate format is an internal format of the report used by Reporting Services for rendering and caching. It is this format that is sent to the rendering extensions. It is a combination of both the data and report definition. The size of the intermediate format will depend mostly on the data that is returned.

Caching
The report processor also handles the caching of reports. When working with a reporting solution, the main bottleneck in report performance inevitably is the execution of queries. To solve this problem, Microsoft has developed a number of caching strategies. These strategies offer various performance gains and flexibility. The basic premise of a cached report is that we stored the report definition and data together. Thus when a user requests a report, the only thing that needs to be performed is the actual rendering. Rendering by comparison with other activities, is a relatively inexpensive part of the report processing in terms of server resources. Let's take a look at each of the caching strategies.

Session Cache
Since Reporting Services works over HTTP (we will talk more about this later), it must maintain some information about each user request. This is referred to as session information. If the same user asks for the same report in a relatively short period of time, it does not make sense to query that information again. So, when a user makes an initial request, the report definition and data are stored in the session cache. Session cache is used with on-demand reports (reports not cached).

Cached Instances
Cached instances also store the report definition and data, but they must expire at some given time. This time frame could be an hour, week, or month. The actual start time, however, is not defined. With a cached instance, the first user that requests the report has to wait for the query to process. After this initial request, the timeout is started. Once the report expires, the next user requesting the same information will have to execute the associated query.

This caching strategy is perfect if you have slower changing data, or even data that changes frequently but is not critical to update as soon as it changes. A good example of this would be stock quotes. They update constantly. It would be incredibly taxing on software systems if they had to keep up with this rapid rate of change. So, instead of updating every millisecond, stock quotes are generally updated every five to ten minutes.

Snapshots
The final type of caching strategy is the snapshot. Like the name implies, it is a snapshot of the data at a given point in time. Unlike cached instances, snapshots have a defined start time and not definite end time. Let's say you have a group of users that needs summary reports every Monday at 7:00 am for a weekly meeting. You are in the data warehousing group and have jobs that process data late Sunday night in preparation for the meeting. Once the data is processed, it does not change. This data is also very large and takes a long time to query. In that case, it makes perfect sense to store the reports right after the information is available. This way when people come in Monday morning to run the reports, they are kept ready and the users will not have to wait for any query processing. Therefore, by using snapshots, data is made available at a specific time within minimum amount of processing time.

Working again from our example above, a week goes by and you are again ready to run your reports. Would you want to get rid of the previous week's information? Certainly not—as soon as you do someone is bound to ask for it! So, you need a mechanism to store that information away. Reporting Services gives you the ability to store a history of report snapshots. That way, even though the new snapshot has been created, the old one is still available.

Report Processing Illustrated
Figure 2-2 shows the process of requesting a report and moving through the Report Processor:


DATA PROCESSING EXTENSIONS

Now that we have seen the Report Processor, let's take a look at how the actual data is retrieved. Data is returned to the Report Processor through the Data Processing Extensions. The Data Processing Extension that is used will depend on the data source defined in your report. We describe the common functions of all these extensions and then those that are supported by Reporting Services.

Data Processing Defined

Data Processing Extensions are used to return data from a given data source. The architecture in Reporting Services supports the .NET managed providers and allows you to create extensions for your own particular data source.

The common functions that all Data Processing Extensions perform are as follows:

• Connect to the data source
• Pass parameters to the query
• Run the query on the data source
• Return a list of field names from the query
• Move through the rowset to retrieve data

Supported Providers

Reporting Services supports the .NET managed providers for returning data. These include SQL Server, OLEDB, ODBC, and Oracle. Since they are managed providers, they take full advantage of the .NET Framework. Using these four data providers, users should be able to connect to just about any data source. Let's take a look at some common providers.

SQL Server Provider
Using the SQL Server provider, users can retrieve data from SQL Server tables, stored procedures, views, and User Defined Functions (SQL 2000). The SQL Server managed provider is optimized to connect to SQL Server. Extra layers such as OLEDB and ODBC have been removed for optimal performance.

Oracle Provider
Although Reporting Services uses SQL Server to store its metadata, you can use Oracle as a source for your reports. Like the SQL Server managed provider, the Oracle managed provider is optimized for Oracle and removes extra layers such as OLEDB and ODBC.

OLEDB Provider
The OLEDB provider gives report writers a great deal of flexibility. Using this provider, you can query a number of different data sources. The following is a list of just a few:

• Microsoft Analysis Services
• Microsoft Access
• Microsoft Excel
• Microsoft Directory Services

ODBC Processing Extension
ODBC works through the .NET OLEDB managed provider. The ODBC Processing Extension allows users to access any system with a compatible ODBC driver. This opens the door to reporting on a number of legacy systems, such as dBase and FoxPro. ODBC drivers have been written for most of today's database systems.

Be careful when using an ODBC driver. It is possible to connect to SQL Server, Oracle, and a number of data sources listed earlier. If you use an ODBC driver to connect to these data source instead of the native .NET managed provider or OLEDB provider, you could seriously hamper query performance. With your data sources, look for a .NET managed provider first, then an OLEDB provider, and if neither of these options is available, use an ODBC driver.

Data Processing Extensions and Data Providers

Along with the four .NET managed providers, users can also create their own custom Data Processing Extensions or data providers through the Reporting Services API. This allows users to expose the functionality of their data source to the end user and achieve some performance gains. The .NET Framework also allows the creation of .NET data providers. Since Reporting Services supports .NET data providers, this would be another viable option for connection to your custom data source. The role of Data Processing Extensions in relation to the report processor and the data source is shown in Figure 2-3:

Supported Rendering Extensions
Reporting Services also supports a number of different rendering extensions. When creating a report in Reporting Services you are creating them in a neutral output format. In the report, you define the query, the fields, and how they should be laid out. It is the job of the rendering extensions to take this information combined with the data and create a useful output. Often, this is not an easy task. Let's take a look at some of the supported extensions. Microsoft has provided seven different rendering extensions. Each of these can be used to return report information.

Excel
The Excel rendering extension takes report data and outputs it to Excel. This is a common format for many users, especially for those users who will perform further analysis on the information.

The Excel rendering is more sophisticated than competing reporting platforms. Many reporting platforms lay out reports in a banded format. If you are familiar with Microsoft Access, you will understand the different bands for data detail, grouping headers and footers, page headers and footers, and report headers and footers. While this type of banded report does offer an extremely flexible report design, it does not always translate well into an Excel document.

By incorporating table and matrix controls in reports, users can create report layouts almost like they would in Excel. This type of layout lends itself nicely to rendering in Excel.

At the time of writing, Excel rendering is limited to Office XP and Office 11.

PDF
Microsoft also provides a rendering extension for PDF Format, which is probably the most popular document format on the web. It is clean and easy to read and has printing capabilities. You would most likely choose this format for reports that are widely distributed but not analyzed by the end users. The reports that are in PDF format cannot be altered. Some common examples would be invoices, inventory pick tickets, weekly sales summaries, and a company's public financial documents.

PDFs also support document map functionality. This feature in Reporting Services allows you to define bookmarks within your report. Once the report is rendered, users can click on links to easily navigate to different areas of the report.

End users can download Adobe Acrobat Reader for free and you do not need a license to distribute PDF documents generated by Reporting Services.
HTML
Probably the most common output format for reports in Reporting Services is HTML. Since both the Designer Preview and Report Manager work in this view, reports can be rendered in HTML 4.0 or HTML 3.2. The .NET Framework looks at the user request to determine which browser is being used and then renders the report in the appropriate HTML format.

HTML rendering is good for interactive reports. By navigating to a web site, a user can easily manipulate report parameters to find specific information. HTML rendering also supports dynamic visibility, which gives users the ability to drill down to detailed information and supports document maps for easier navigation. Users can also render reports to HTML with Office Web Components. This allows for even greater manipulation of report information.

HTML rendering, however, is not good for printing. HTML pages are truly meant for displaying information. Most web applications will allow users to click a link and print printer friendly information. In Reporting Services, users can simply export a report to PDF or Excel and print it from there.

Web Archive (MHTML)
Web Archive or MHTML is commonly found in email messages. MHTML stands for MIME Encapsulation of Aggregate HTML Documents and these files have a .MHT extension. Generally an HTML document references a number of external resources such as images and style sheets. Although HTML allows for rich formatting of documents, it is hard to transport them when they reference other independent objects. MHTML takes care of this by encapsulating the externally referenced information such as images into one document.

MHTML documents are useful when sending out subscriptions. If users would like to view reports through email without opening an attachment, then MHTML is the appropriate format. One thing to note though is that not all email clients support this standard, so check your User Communities setup first.

CSV
The Comma Separated Value (CSV) format takes the report definition and data and transforms it into a flat file. This type of output is not appropriate for reading. It is suitable as a data exchange format. You might have customers with legacy systems that are very good at parsing and consuming flat files. In this case, you could electronically send reports in CSV format to these users. They could in turn consume the data and report on it or manipulate it how they see fit.

TIFF
The Tag Image File Format (TIFF) is a widely used format for storing document images. Many facsimile programs use this format to transfer data. Many organizations store documents in document management systems such as SharePoint Portal Server. Reports rendered in TIFF format would be excellent candidates for this type of document system. You could place historical snapshots of reports into your document management system and then remove them from the Report Server. This would allow you to take advantage of common document management features such as indexing.

XML
The Extensible Markup Language (XML) is very different from CSV rendering, but can serve many of the same purposes. XML is a structured markup language that lets you define data. Reporting Services uses this markup in a number of areas. When reports are rendered as XML, they include both the report definition and data, much like CSV rendered reports. Similar to CSV files, XML files are designed explicitly for the exchange of information. You could send XML rendered reports to customers or other applications for additional processing, or you could run the XML rendered report through an XML Transform document to control the standard formatting of the document.

Customized Extensions

Along with the seven supported rendering extensions, the Reporting Services API also allows users to create their own rendering extensions. So, if you want to output a report to a Word or a GIF file, you could create your own extension. Report rendering is illustrated in Figure 2-4:

Scheduling and Delivery Processor
The Scheduling and Delivery Processor has two major functions, creating report snapshots and delivering subscriptions. These tasks hinge on the use of Microsoft's SQL Server Agent. The SQL Server Agent is responsible for queuing scheduled events. Reporting Services monitors these events and takes appropriate action as and when required. Scheduling and delivery have been encapsulated together because they use similar functionality. In both cases, Reporting Services is watching for a given event, processing the report, and then either storing that processed report or delivering it. Let's take a closer look at both the scheduling and delivery areas.

Scheduling
Scheduling refers to the actual setting up of the report execution and delivery schedule. When we store report schedules, this information is relayed to the SQL Server Agent to queue the request at the appropriate time. Both users and administrators can define schedules for report execution and delivery.

Delivery
Delivery deals with the mode of delivery of reports in Reporting Services. Users can have reports delivered via email, a fileshare, or a customized delivery extension, you will see more on delivery extensions in the forthcoming sections.
There are two types of subscriptions available in Reporting Services, standard and data-driven subscriptions.

Standard Subscriptions
Users can create their own subscriptions through Report Manager or a custom interface. Additionally, administrators can also create subscriptions for users. When setting up a standard subscription, information such as parameter values and rendering format can be set along with a schedule for report delivery.

With standard subscriptions, users can define their own schedule for receiving a report. This is important for small scale reports and gives users a great deal of freedom in how they receive certain information.

Data-Driven Subscriptions
Data-driven subscriptions offer a great deal of flexibility when delivering reports. You can create reports for any number of users, use different rendering formats for each user, and even change report parameters for each. This allows you to create a very custom report experience for users with a minimal amount of work.

Think of a large retail organization where each store in the organization has a store manager. Each week the store manager receives the sales numbers from the previous week. The report is identical for each manager except for the reference to the actual store. So, using data-driven subscriptions, you could dynamically set the store report parameter for each report and then email these individual reports to each manager. In the end you have created only one report, but quickly tailored it for a number of different users.

In both standard and data-driven subscriptions, the delivery of these reports is event-driven.

Schedule-Based Events
One of the common methods of determining when reports are to be delivered is doing so through some sort of schedule. The report could be delivered every month, week, day, or at any such pre-decided interval of time. Reporting Services gives users a number of different options when setting schedules. These schedules can be either specific to a given subscription or shared through Reporting Services.

Let's imagine that your organization has a set of reports that have their underlying data updated every Sunday evening. Executives for a Monday morning meeting can use this information. You could define a shared scheduled that contains information such as "Weekly, Monday, 6 am". This shared schedule could then be used for any number of reports. If later you decide that sending the report at 6 am does not meet new requirements, you could simply edit the shared schedule and thereby change the schedule for each report using it.

Snapshot Update Events
Delivery of reports can also be triggered by the update of snapshot reports. Many reports in an organization have set intervals after which they are updated. For example, data for a monthly sales report is always updated on the last day of the month. Once this has happened, the data is frozen and does not change for an entire month. If you want to create a report from this information, does it make sense to query the database each time the report runs? No, the information at this point is static. So, we create a snapshot of the data at the end of each month and store the entire report. At this point when users display the report you no longer have the overhead of a database call.

If we were going to update our reports according to a given schedule, it would only make sense to deliver them to the appropriate users when they are ready. Reporting Services allows users to set their subscriptions based on updates to snapshots. Through this method, we do not have to worry about setting a defined time when we think the report will be done processing; instead it will send off the delivery when report processing is finished.

Scheduling and Delivery Processor Illustrated
The following set of illustrations (Figure 2-5) will walk you through the various tasks performed by the Scheduling and Delivery Processor. Let's begin by handling the initial subscription and then move on to running snapshots and delivering subscriptions.

Now that we have seen how report schedules are created, we can look at both snapshot processing and subscriptions processing (Figure 2-6).

The final piece of scheduling and delivering is subscription processing. In Figure 2-7, you can see the individual steps in the processing of report subscriptions.

Delivery Extensions
Delivery extensions are tied heavily to the Scheduling and Delivery Processor. They are used when sending subscriptions to users. Microsoft has provided two delivery extensions and given users the ability to develop their own. Reporting Services comes with two delivery extensions—email and fileshare. Let's take a look at each.

Email

The email delivery extension allows users to receive reports directly in their inbox. You can specify the rendering format that you would like the report to be delivered in and whether or not to include a web link to the report. Depending on the rendering extension used in the report, users will either see the report directly in their mailbox or receive it as an attachment. As mentioned earlier, you could use the Web Archive (MHTML format) to embed reports and their images in an email message.

To send email deliveries, Reporting Services must be able to communicate with a valid SMTP server. This setting is initially set when installing Reporting Services.

File Share

Reports can also be delivered directly to a fileshare. For this, Reporting Services must have Write permissions to the share. You can also specify credentials to use when sending reports to a fileshare.

Custom Extensions

Along with the supported extensions, Reporting Services also allows for the creation of custom delivery extensions. Say you like monthly reports to be delivered directly to a printer after they have been processed. You can create your own delivery extension and then schedule a subscription to use this delivery extension. In the Reporting Services sample folder, you can find an example for creating a delivery extension for a printer. Delivery extensions are illustrated in Figure 2-8.

Report Server Databases
Reporting Services relies on SQL Server for storing its metadata. This allows for greater scalability in large reporting applications. This also allows you to take advantage of features inherent to SQL Server, such as backup and transaction logging.

Reporting Services uses two SQL Server databases to store data, ReportServer and ReportServerTempDB. In the next section, we will take a look at the major components of each database and describe how they are used. We will also take a quick look at a Data Transformation Service (DTS) package provided for monitoring information.

ReportServer Database

The ReportServer database is the main store for data in Reporting Services. It houses all report definitions, data sources, schedules and delivery information, security information, and snapshots and snapshot history. There are a series of tables for each functional area. The database schema is open and generally easy to follow.

Updating or querying these database tables is not recommended, but an understanding of how they are arranged should give you a better understanding of how Reporting Services works.

The following table lists some of the tables in the ReportServer database and their related functions:

When working with Reporting Services, it is important to pay close attention to the ReportServer database. It contains all critical information related to Reporting Services and should be backed up on a regular schedule.

ReportServerTempDB Database

As the name implies, the ReportServerTempDB database stores temporary Reporting Services information. User session information is stored in the ReportServerTempDB. Because Reporting Services communicates using HTTP, no state is maintained between the client application and the server. Session state about the reports that the user is running must be stored between each server call. The ReportServerTempDB stores this information in a SessionData table.

ReportServerTempDB also stores report cache information. When a report is set as a cached instance, there is no definite time when that report is executed. It depends on which process requests the report first. Once the report is executed, the intermediate format and data are stored in the ReportServerTempDB database. If this database were to fail, the cached information would be lost. But, since it is executed when a user views the report, there is no real loss of information. Snapshots, on the other hand, are not stored here. Their execution time is usually at a set moment to ensure that the data on the report is correct. Therefore, this information is stored in the more permanent ReportServer database. Reporting Services will not be able to function without the ReportServerTempDB database.

It is not ncessary to backup the data in the ReportServerTempDB.

Viewing Execution Information

As mentioned earlier, it is not recommended to view or modify the underlying SQL Server tables. It is also very difficult to analyze execution information in the ReportServer database. So, Microsoft has provided a DTS package for moving this data out of the ReportServer database.

To use the DTS package, you must first create a database to hold execution log information. Microsoft provides a number of scripts in Reporting Services to help with this task. Once the database has been created, you can use the DTS package to move information into it. Once the information has been moved to the new database, you can run queries against it or maybe even create a Reporting Service report.


THE REPORTING SERVICES WEB SERVICE

One of the most outstanding aspects of Reporting Services is its open programming interface. Everything that we have seen so far can be performed through the Reporting Services Web Service. The Reporting Services Web Service is a set of functions you can use to render, subscribe to, and publish reports.

Reporting Services takes advantage of technologies already implemented in Internet Information Server (IIS) and the .NET Framework. Both these components provide the backbone infrastructure for web services. IIS performs web request handling and routing along with some security. The .NET Framework provides classes for consuming and publishing web service interfaces.

To understand the Reporting Services Web Service, you must first understand the underlying technology.

Web Services

Web services have really been a hot topic over the last few years. With them comes the promise of various applications exchanging information freely with one another. No more complicated interfaces for calling code on disparate systems—just one set of standards that everyone can follow.

The standards are what make web services so inviting. In the past, different companies have come up with their own standards for interfacing different sections of code. COM for example is a specification that allows code written in Visual Basic to talk to code written in C++. This is fine if you are working on Microsoft platforms, but what if you want your Visual Basic application to use functionality in a COBOL application. You would have to write some cumbersome code to make this happen. Let's take a look at the standards that make web services possible.

Open Standards

There are a number of open standards that make web services possible. When you think of code communicating with other code and all the tasks that entails, you quickly find some similarities. First of all, you need some transport mechanism for sending information.

One of the most widely adopted standards for sending information is Hypertext Transfer Protocol (HTTP) which is the default standard for web communication. It has the ability to send information back and forth between remote machines and has a huge implementation base. All major platforms today support sending information via this protocol. Now that we have a transport mechanism, we need to package (or address) the information.

Simple Object Access Protocol (SOAP) is a messaging protocol designed specifically for the distribution of information via HTTP. SOAP messages define a standard to package data and send it across the Internet. Some of this information includes header information for the message, security information, and the actual message body of itself. SOAP also uses XML as part of its protocol. So, you've got a package and a way to send it—now all you need is the message.

Web service messages are sent encoded in XML. This allows services to have richly defined interfaces and yet be able to use the structure of XML. It also allows other systems to easily read and manipulate data.

Visual Studio .NET Integration

Visual Studio .NET has complete support for using web services. Consuming web services is almost as easy as working with objects in the .NET base classes. Using the Visual Studio .NET IDE, you can easily add web references to your projects and get full access to a web services. Using the Reporting Services Web Service through Visual Studio .NET allows you to take advantage of the IDE built-in functionality.

Although Visual Studio .NET makes it easy to work with web services, it is not the only development option. Because web services are built on open standards, any development tool supporting these standards can be used to work with them. For example, if you want to integrate Reporting Service functionality into your Microsoft Office applications, you can. Through Visual Basic for applications, you can write code that calls web services and therefore can call Reporting Services. You might want to build a list of reports into an existing Microsoft Access application. This could be easily accomplished in a few lines of code using the Reporting Services web service.

Available Features

Any feature that you use in the Report Manager interface can be used or accessed through the Reporting Services Web Service. There are no special calls from the Report Manager to Reporting Services.

Here is a list of just a few things available through the Reporting Service Web Service. The rest of the book will go into detail on these topic areas:

• Rendering reports through various rendering extensions
• Publishing reports programmatically
• Creating snapshot reports
• Adding snapshot reports to history
• Creating subscriptions
• Modifying data sources

The list could continue on with a number of different features. Just remember that anything you do in Report Manager can be done through the Reporting Service Web Service.


REPORT DESIGNER

Creating reports in Reporting Services is very straightforward. Microsoft has provided a set of tools that allow you to easily build and publish your reports. In this section, we will take a look at how the Report Designer is incorporated in Visual Studio .NET and also explain the RDL file created by the designer.

Visual Studio .NET

Microsoft has chosen Visual Studio .NET as the standard development tool for their products. Along these lines, they have incorporated the Reporting Services Report Designer into Visual Studio .NET. Visual Studio .NET provides a number of other features other than the Report Designer.

Once you have installed the Reporting Services, there are a couple of project templates added to Visual Studio .NET. Inside Visual Studio .NET you will see a folder called Business Intelligence Projects. This folder contains both the Report Project Wizard template and Report Project template. Choosing either of these project templates will load the Report Designer.

Report Definition Language (RDL)

Now let's take a look at what exactly the Report Designer does. The Report Designer allows you to visually layout reports and build their underlying queries. This information is used to create an, RDL file. An RDL file is a XML document that defines the elements of a report. It is this file that is eventually published to the Report Server. Once the file is published, the report definition is stored in the ReportServer database. Any subsequent publishing of the report replaces most of the definition stored in the ReportServer database. You will learn more about RDL in Chapter 11.


REPORTING SERVICES TOOLS

There are a couple of tools included with Reporting Services. These tools allow you to publish reports, modify data sources, set security information, and a number of other tasks. Each of these tools relies on the Reporting Services Web Service. Anything that you can perform with these tools can be written in your own custom code. Let's take a look at a couple of the major tools, Report Manager and RS.EXE.

Report Manager

Report Manager is the main management tool for Reporting Services. It provides the following functionality:

• Report management
• Uploading RDL files
• Managing folder hierarchies
• Setting data source credentials
• Managing default parameter values
• Creating linked reports
• Creating execution snapshots
• Setting caching options
• Security
• Setting server-level and item-level security
• Defining Reporting Services Roles
• Assigning Windows Users and Groups to roles
• Report delivery
• Viewing reports
• Exporting reports to different rendering formats
• Defining report subscriptions

We will take a closer look at the Report Manager in Chapter 5.

Report Server Command-Line Utility (RS.EXE)

Reporting Services also comes with a command-line utility to simplify management of reports. After installing Reporting Services, you will find a file named RS.EXE. This utility contains a reference to the Reporting Services Web Service and allows users to call any of the service methods. To use the Reporting Services command line utility, you must first create a Visual Basic .NET input file. This file contains one main procedure and then instructions for working with the Report Server. The commands in the Visual Basic .NET file rely on the Reporting Services Web Service to perform their tasks. This file can then be passed into the command-line utility for execution.

A common example of this would be deploying development reports on a set basis. You can create a command line utility that checks for files updated in the Report Definition files. Once file changes are found, you could then use the Reporting Services command line utility to publish these files to the report server.

Reporting Services comes with a few samples that demonstrate how to perform various tasks using RS.EXE.

REPORTING SERVICES ILLUSTRATES

Now that we have seen all the components that make up Reporting Services, let's take a look at an overall illustration. Figure 2-9 shows the different components of Reporting Services and how they are grouped. Notice that the actual functionality of Reporting Services is all encapsulated in one area. The databases storing data for the Reporting Service are separate. This means that we can physically separate the different components of Reporting Services to take advantage of web farm configurations (multiple servers combined to distribute processing), allowing us to create highly scalable applications.

Also notice that all calls to the Reporting Service go through the Reporting Services Web Service. This means that you can create your own custom front ends and have complete access to the Reporting Service.