rsNeatPublish Scenarios

Below is a list of options that are available to allow a flexible range of implementations.

Different Configurations

Different environments (eg. Development, UAT, Staging, ModelOffice, PreProduction, Live/Production, etc) will generally require database connection strings (data sources), target (and sometimes source locations), etc. The option most likely to be taken is to create separate configuration files. This is where individual rsNeatPublish XML configuration files are created all with potentially different connections strings, target locations, etc. Here each file is created (via rsNeatPublish.XmlGenerator, saved as say rsNeatPublish_MyApp_Development, rsNeatPublish_MyApp_UAT, rsNeatPublish_MyApp_Production, etc. Then these files are passed as override variables on the command line to rsNeatPublish as follows.

  • rsNeatPublish -x rsNeatPublish_MyApp_Development.xml
  • rsNeatPublish -x rsNeatPublish_MyApp_UAT.xml
  • rsNeatPublish -x rsNeatPublish_MyApp_Production.xml

Deploying to SSRS in SharePoint Integrated mode

If the SSRS installation is in SharePoint Integrated mode, deployed SSRS objects can be hosted within SharePoint. When this is the desire, the rsNeatPublish.XmlGenerator Globals tab provides settings to specify where the objects should be deployed to. Typically the location will be a SharePoint website where Document Libraries will ultimately reside which will contain the content (Data Sources, Data Sets, Reports, etc). The Document Libraries will have SSRS content types associated with them (either manually or by rsNeatPublish at publish time). See sample 2 on the website’s further information page (Examples and Further Information)

Data Sources already uploaded

It may be desirable to upload data sources as a one-off (eg. as they contain sensitive information), then upload other objects such as reports, data sets, etc as required. In this scenario:-

  • there could be two rsNeatPublish XML configuration files
  • one that contains details of the data sources (within the data source tab, with the SearchExternal flag set to "False")
  • the other contains where the data sources exist server side (i.e. the data source’s target path and name) with the Search External indicator on the data source set to "True", plus all of the other remaining SSRS objects (eg. reports, data sets, etc that may reference these data sources)
  • the user then runs rsNeatPublish with the first of the two XML configuration files which uploads the data sources
  • the user can then run rsNeatPublish again with the second of the two XML configuration files which uploads all of the remaining objects - and will sense that the those data source entered (with SearchExternal=True) will already exist server side and link up accordingly

Subscriptions - Delivery methods

For subscriptions there are two main delivery methods (on the Subscriptions tab, "Delivered By"). These are "E-Mail" or "Windows File Share". Both require additional parameters which are available for entry via the "Report Delivery" button for the corresponding subscription.

Subscriptions – Event Type

For subscriptions there are two event types (on the Subscriptions tab, "Event Type"). These are "Timed Subscriptions" or "Snapshot Updated". If Timed Subscription is chosen the Schedule dialog is able to be opened and schedule entered.

Data Driven Subscriptions

If the desire is to create subscriptions based on data (so called Data Driven Subscriptions), enter the requested fields (which includes data source and query/stored-procedure/etc) into the Data Driven Parameters dialog (within the Subscriptions tab). This then allows entry of columns (aliases) into the "Report Delivery Options" and "Report Parameter Values" dialogs.

Encrypt Data Source Passwords

If it is a requirement to store the data source passwords in the rsNeatPublish XML generated configuration file, the user can set the Encrypt Passwords indicator on the Globals tab of rsNeatPublish.XmlGenerator to true. Then when rsNeatPubish runs against the generated file the password will be decrypted and the data source added as expected.

Nested Folders on Target

When the target contains folders are required to be nested the folders are created if they do not exist prior to the deployment. If it is a SharePoint style deployment the first level will be created as a Document Library, then subsequent folders within the structure will be created as SharePoint folders.

Embedded Data Sources

When a report contains embedded data sources where the embedded data source configuration (eg. connection string, credentials, etc) need to change depending on the environment, this can be done via the Reports tab - an Embedded Data Sources dialog is available for each report. Within the dialog the embedded data sources can either be entered manually or fetched via the 'Fetch Embedded Data Sources' button then modified as desired.

Note that although overriding the details of an embedded data source is optional, in generally most embedded data sources should be specified within the rsNeatPublish XML configuration file - this is because:-

  • the details will probably be target environment specific
  • credentials are not saved within the report and hence without overriding, the embedded data source will be without credentials

Dynamic Data Sources

Sometimes the requirement is beyond the typical static data source. In this scenario a data source connection details can be retrieved from another data source (eg. a SQL Server table). In this case two data sources are specified:-

  • the first, a regular data source to point to where the connection details are specified - note this can be a shared or embedded data source
  • the second, a data source, whose connection details are determined by data pointed to by the first data source - this must be an embedded data source

In the above scenario the second data source does not have to be specified within the rsNeatPublish XML configuration file

The above strategy is outlined in the blog here

Hide object in SSRS Management console

When you wish to hide an SSRS object within the SSRS Management Console this can be done setting the 'Hide in Tile View' checkbox. To automate the deployment of this, access the Properties dialog for the desired object(s) (found on the far right within each rsNeatPublish.XmlGenerator tab) and create a Name/Value pair of Hidden/true. Note to 'unset' use Hidden/False

Deleting SSRS objects (reports, data sources/sets, etc) before deploy

By default, rsNeatPublish overwrites/updates target SSRS objects if they already exist. This is because updating an SSRS object is different to deleting then re-creating. From this article:-

If you are replacing a report definition, the file that you select is copied to the report server. The properties, subscriptions, report history, and security settings of the current report remain intact. If the report uses parameters, and the name or data type is different from the original report, you must reset any parameter properties that you previously set.

However if the requirement is to delete the object first there are a couple of options:-

  • the rsNeatPublish executable has a switch which isn't available within the rsNeatPublish.XmlGenerator UI that deletes the object before recreating it. This isn't within the UI because the user must be careful using it - i.e. may not want to delete objects before each run. If you would like to delete each SSRS object before deploying via rsNeatPublish use the "-d" (without quotes) switch on the command line - for a full list of switches submit the following within a command prompt:-

    "C:\Program Files (x86)\rsNeatPublish\rsNeatPublish\rsneatpublish.exe" -?

  • The alternative to deleting the reports via rsNeatPublish is to write a script (via for example rs.exe, PowerShell, etc) to delete individual files and/or folders (with children). Be careful doing this - as opposed to deleting only those files within the rsNeatPublish deployment file, this method may delete files that were not intended to be deleted.