1.       Script building

2.       Object comparison

3.       Script submission

4.       Process protection

Note These three steps are not what are formally described in the product documentation. Instead, Books Online refers to Build and Deploy processes with the Deploy process encompassing the Build process. To align the formal processes with these three steps, the script building step aligns to the Build process while the object comparison and script submission steps are the additional steps included in the Deploy process.

During the first step, a series of XML files are assembled in the project’s Bin subfolder.  These files encapsulate the information within the project required for successfully deployment. Each is recognizable through the use of one of four file extensions:

·         .asdatabase

·         .configsettings

·         .deploymenttargets

·         .deploymentoptions

The .asdatabase file contains a ASSL script defining the database and all the objects within it. The script is assembled from the individual files of the Analysis Services project and serves as the basis for the script submitted to Analysis Services in the final step.

The .configsettings file contains a listing of objects within the Analysis Services database as defined by the project associated with data storage as well as data sources. In deployments involving the Analysis Services Deployment Wizard, this file can be used to override certain information in the .asdatabase file.

The .deploymenttargets file identifies the Analysis Services instance and database to which the script is to eventually be applied.  The information in this file comes from database properties accessible within the Analysis Services project by opening the Solution Explorer window, right-clicking the database object, selecting properties, and navigating to the Deployment page.

The .deploymentoptions file contains various settings controlling the deployment process. Some of these settings are accessible through the previously mentioned database properties dialog’s Deployment page.  Others are hardcoded for BIDS deployments.

To complete the script building step, a fifth file, LastBuilt.xml, is assembled. This file, located within the Obj subfolder associated with the project’s currently selected configuration. This file records a timestamp and hash value for each object within the project. There is little to no documentation on the LastBuilt.xml file but it appears this information serves as the foundation of the following object comparison step.

Note The database properties dialog provides the means to select (and define) various configurations for your project.  Each configuration represents a collection of settings controlling aspects of the project environment as well as the deployment process. The default configuration for an Analysis Services project is Development so that the LastBuilt.xml file is often located in a subfolder called Development under the project’s Obj subfolder.

With the script building step completed, the deployment process moves onto the object comparison step. During this step, a connection is made to the targeted Analysis Services instance and a Discover statement submitted to retrieve the name, id, and timestamp associated with various database objects. The values returned are compared to the information in the LastBuilt.xml file to determine which changes need to be pushed to the Analysis Services instance.

Following this determination the process moves into the script submission step. An XMLA Alter statement based on information in the .asdatabase, .configsettings, and .deploymentoptions is assembled and submitted to the Analysis Services database.

Once the changes have been deployed, the Discover statement issued during the object comparison step is resubmitted. The results of that statement are combined with information from the deployment process to construct a final file, IncrementalShapshot.xml [sic], which is stored side-by-side with the LastBuilt.xml file. The purpose of this file appears to be to assist the next deployment cycle in determining whether a database has been altered outside of the confines of the current project. (If this is the case, this file is likely employed during the object comparison step.)

Note For the purposes of the demonstration, I am working with Reporting Services 2008 SP1 running in Native mode on my local system. In Reporting Services, I am a member of the System Administrator server role and a Content Manager in the Home directory.

The first step is to create a subscription associated with a report.  This subscription should never run on its own so you’ll assign it a run-once schedule set to end on a date in the past.

In my demo, I’m using a report-specific schedule.  I’ve read a blog suggesting the use of a shared schedule but my concern is that when I fire the event in my code, any subscription tied to that schedule will run.  You can use either type of schedule just be aware of the consequences.

1.       Open Report Manager and locate the report. In my demonstration, this is a report called Blank Report in the Demo Reports folder located under Home.

2.       Setup subscription with a subscription-specific schedule set to run once with a start and end date set to a day in the past.

Next, you need to assign the permissions required to call the FireEvent method. In my local instance of Reporting Services, I am a member of the System Administrator server role but even this role doesn’t have the required permission by default.

To assign the permission you have two options, you can modify an existing server role or create a new one.  To keep my system standard, I created a new one with just that permission and then assign myself membership in that new server role:

1.       Open SQL Server Management Studio and connect to your instance of Reporting Services.

2.       Expand the Security folder, right-click the Server Roles child folder, and select New Server Role to launch the New Server Role dialog.

3.       Assign the role an appropriate name (and description) and select the Generate events task.

4.       Click OK to create the role and close the dialog.

5.       Return to Report Manager.

6.       Open Site Settings and then the Security page.

7.       Assign yourself membership in your new server role.

With the subscription and security in place, now it’s time to start programming.  As I said earlier, the customer’s goal is to tie this all into an ETL layer that’s written using SQL Server Integration Services. So, for this demonstration, I create a package, add a script task, and enter the required code:

1.       Launch the SQL Server Business Intelligence Development Studio and create a new Integration Services package.

2.       Drag a Script task from the toolbar to the control flow.

3.       Open the Script task, select an appropriate language—VB.NET in my example—and then click the Edit Script… button to launch the Visual Studio Tools for Applications environment.

4.       From the Project menu, select Add Web Reference to launch the Add Web Reference dialog.

5.       For the URL, enter the path to Reporting Services web service’s ReportService2005 endpoint.  On my local system, this is https://localhost/reportserver/reportservice2005.asmx?wsdl.

6.       Clicking Go retrieves the metadata for the web service endpoint which populates the dialog. Modify the web reference name as appropriate – I chose rs for my web reference name—and then click Add Reference to add the reference to your project.

7.       With the web reference in place, you can now enter your code.  For my demonstration, I modified Sub Main as follows:

   Public Sub Main()

     Dim MyRs As New rs.ReportingService2005()

     MyRs.Credentials = System.Net.CredentialCache.DefaultCredentials

     Dim MySubs As rs.Subscription() = _

      MyRs.ListSubscriptions("/Demo Reports/Blank Report", Nothing)

     Dim MySub As rs.Subscription = MySubs(0)

     MyRs.FireEvent(MySub.EventType, MySub.SubscriptionID)

     Dts.TaskResult = ScriptResults.Success

   End Sub

Let me pick apart this code a bit.  I first declare a new object, MyRs, which represents the web service interface.  I establish my identity with the interface leveraging my active Windows credentials.

 Then I open the collection of subscriptions associated with my report, /Demo Reports/Blank Report. I then grab the one subscription tied to my report and fire the event associated with it before completing the routine.

So, how do I know the subscription I want is the one with an index of 0 in the subscriptions collection?  Well, in my example, there is only one subscription.  In the real world, you’ll need to look at the subscription’s properties or some other mechanism to determine which one to fire.