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
rsNeatPublish -x rsNeatPublish_MyApp_Development.xml
rsNeatPublish -x rsNeatPublish_MyApp_UAT.xml
rsNeatPublish -x rsNeatPublish_MyApp_Production.xml
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
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
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
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
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 the article https://technet.microsoft.com/en-us/library/ms159153(v=sql.105).aspx:-
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.