Introduction
The purpose of this article is to review the rsNeatPublish (www.rsneatpublish.com) toolset, which allows automated bulk publishing of SSRS 2008R2/12/14/16 objects to SSRS instances (native and SharePoint Integrated). The review will assess the software based on functionality offering, the user experience, help/support available, and pricing.
Background
Automating deployment of SSRS 2008R2 (and beyond) reports, and related artefacts, have been a little ignored when it comes to an out of the box “hands-off” solution. Typically the options are:
- Using Visual Studio, which is not ideal, as it’s a development tool, not a release management tool, and doesn’t accommodate all artefacts such as subscriptions.
- Write SQL scripts to directly inject the required meta-data into the SSRS database tables directly. This is not recommended for various reasons.
- Write script/code that interacts with the SSRS supplied web service ReportService2010, via RS scripter [rs.exe], PowerShell cmdlets, or a console application written in VB.NET or C#.NET, based on examples provided over the Internet.
The Problem
The problem with the third option is that the examples don’t seem to cover all deployment scenarios needed. For example, deploying to native/SharePoint-Integrated, subscriptions (standard and data driven), shared VS embedded data sources, and multi-valued parameters all need to be accommodated. Also, the examples aren’t general enough and hence often have limitations. The limitations include detection of the link requiring prior knowledge of the objects being linked, problematic linking of objects because of reference Vs name confusion, many to many relationships, etc.
As well, ideally we could record all settings in a convenient location (i.e. within source control, so we have a history of changes and can track against a task ID). A comprehensive settings file would allow an easily repeatable (in total) upload process to create/refresh/migrate a CI (continuous integration), Staging, or Live environment. And, it is one thing to have a repeatable process for reports, data sources, and data sets, but it is another to include all SSRS artefacts, such as the schedule of a subscription, the report a subscription is for, a linked report, etc. within the automated deployment scope
Further, typically SSRS objects like data sources (both shared and embedded) are different for each environment. Hence ideally the configuration for all objects that are defined the same for all environments (like reports) would sit in a 'common' configuration, while the data source configuration could be environmentally specific.
Overview
The rsNeatPublish toolset consists of two applications:
- a client UI application (called rsNeatPublish.XmlGenerator) to capture/save the required meta data (to deploy to the target SSRS instance)
- a console application (rsNeatPublish), which reads the meta data from a file captured/saved in the client UI application, and deploys the SSRS objects (via the ReportService2010.asmx webservice) to the target SSRS instance.
Installation
There are two basic user scenarios:
- Scenario I (Developer user): the client UI (rsNeatPublish.XmlGenerator) as well as the console application (rsNeatPublish) are deployed so that the configuration data captured (within the UI) can be tested to make sure all deployments are as expected
- Scenario II (Release Team user and/or automated deployment and/or continuous integration process) – the console application (rsNeatPublish) is installed to run standalone from the command-line.
rsNeatPublish and rsNeatPublish.XmlGenerator are separate installs. Both are very simple ‘Next’-type installations.
Scenario I – Developer user
To create the rsNeatPublish configuration file, open the rsNeatPublish.XmlGenerator UI (see Figure I)
Figure 1 - rsNeatPublish.XmlGenerator UI – Opening (General) tab
The initial screen (Globals tab) prompts for source and target related settings and focuses on high level configuration (SSRS webservice, source/target location, etc) and behaviours. The remaining tabs collect the SSRS object source/targets (data sources, data sets, reports, subscriptions, etc). Most of these settings can be populated via importing of the Visual-Studio/BIDS SSRS project file as shown in the rsNeatPublish automated input demo (which involves confirming the project file settings are correct and importing the SSRS project file (.rptproj) via File | Import). If the SSRS project file is not available, no problem, settings can be entered manually as in the demo here.
Importing the SSRS project file will populate most SSRS objects (i.e the high level settings mentioned above, data sources, data sets, and reports – these will appear within the General, Data Sources, Data Sets, and Reports tab of the rsNeatPublish.XmlGenerator UI respectively)
However, what about artefacts such as subscriptions and linked reports that aren’t specified within the SSRS project ? The settings for these are entered manually within the rsNeatPublish.XmlGenerator UI – subscriptions under the Subscriptions tab (see Figure 2), linked reports under the Linked Reports tab (see Figure 3), etc.
Figure 2 - rsNeatPublish.XmlGenerator UI - Subscriptions tab
Figure 3 - rsNeatPublish.XmlGenerator UI - Linked Reports tab
Once all of the SSRS configuration is in place, the deployment can be tested via the rsNeatPublish.XmlGenerator interface’s Publish! | Save and Publish to Server (see Figure 4 below)
Figure 4 - rsNeatPublish.XmlGenerator UI - Save and Publish to Server
When satisfied all desired SSRS objects are deploying as expected, the data captured by rsNeatPublish.XmlGenerator can be saved to a file (File | Save), for editing (File | Open) at a later time. The file (stored in XML) holds all the configuration information required and can be stored in source control for retrieval at your convenience.
Scenario II - Release Team user (and/or automated deployment and/or continuous integration process)
This workflow assumes
- as mentioned, the rsNeatPublish console application only is required to be installed on the machine that the deployment will be taking place from (be it release team user’s workstation, deployment server, build server, etc).
- the rsNeatPublish SSRS configuration file has been created (typically via Scenario I above). The person/process responsible for the deployment can then simply issue something like the following (to deploy all SSRS objects detailed in the file to the desired target SSRS instance):-
"C:\Program Files (x86)\rsNeatPublish\rsNeatPublish\rsNeatPublish.exe" -x "C:\Projects\Ripline\rsNeatPublish.Tests\Data\AdventureWorks Sample Reports 2012\rsNeatPublish.xml"
…where "C:\Projects\Ripline\rsNeatPublish.Tests\Data\AdventureWorks Sample Reports 2012\rsNeatPublish.xml" is the path of the file created via rsNeatPublish.XmlGenerator
Key Features
The rsNeatPublish toolset
- supports all SSRS object types (including data sources [shared and embedded], data sets, reports, linked reports, subscriptions [standard and data driven], and resources/images).
- accommodates the targeting of native and SharePoint integrated SSRS instances
- is a general solution that detects links between reports, data sets, and data sources automatically and doesn’t assume objects exist server side before execution (although they can if needed). As well, passwords can be displayed/stored encrypted if desired
- because the client UI (rsNeatPublish.XmlGenerator) can both import the SSRS project file (.rptproj) and immediately test the deploy, there is a very small getting started window
- if no project file is available the source SSRS objects/folders can be entered manually – wildcards are supported
- allows objects that are the same for all environments (such as reports) to be configured in a common deployment file while (if required) those that need to specific to the environment (such as data sources, subscriptions) can be placed in separate customised deployment files
- as it is executed from the command-line, the console application, rsNeatPublish can easily be integrated into almost any automated deployment tool (eg. TFS, Octopus Deploy, Team City, Cruise Control, NAnt, etc). There are a number of override switches and settings which can be used to standardize the deployment across environments
- has a number of different sources of help (context sensitive help in the client UI application, technical reference document, demonstration videos, getting started and technical assistance on the website, and of course email sales & technical support)
Documentation and Support
Help is available to get started as well as more complex scenarios on the rsNeatPublish getting started page. For assistance within the rsNeatPublish.XmlGenerator client UI, context sensitive help is available for each field
Technical support is available (pre- and post-sales) via the manufacturer’s support email address support@rsneatpublish.com. A response to queries is typically within the day (generally within a few hours). Product enhancement requests can also be made via the support email address.
Licensing and Pricing
Licensing is based on a CAL basis. The model is against the source machine/device that requires rsNeatPublish (the console deployment application) installed. That is, a machine that has rsNeatPublish installed, can deploy objects to any reachable SSRS instance.
So given a team that may have 1-2 SSRS developers, a build & deploy server (which may be shared among other teams), the licencing for a given team ranges for say 1-3 CALS.
Note that rsNeatPubish.XmlGenerator (client UI application) is available for free with at least one paid license of rsNeatPublish (console deployment application).
Licensing is as per the pricing page on the rsNeatPublish pricing page.
Conclusions
You’ll generally find most things about rsNeatPublish fairly intuitive. If you’ve ever tried to upload SSRS objects (reports, data sources, data sets) and/or created subscriptions, linked reports, etc you’ll quickly understand the workflow. The terms/headings used are similar to the upload screens within the Microsoft SSRS Report Manager UI.
Because the licensing model is based on the source machine, the price-point is quite reasonable given the scope of the functionality on offer.
Ratings below are a mark out of 5
Functionality on offer | 4.5 | A functionally rich experience for the user |
Ease of use | 4 | The data capture client UI is intuitively laid out and combines well with the deployment console application to provide a logical coupling |
Getting started speed | 4 | The project file import and ability to test the deploy within the client UI quickly gets the user deploying |
Help available | 4 | Context sensitive help and demos at hand to the user |
Value for money | 4 | Pricing structure is in general fair and relatively inexpensive |
Ease of installation | 4.5 | Vanilla ‘Next’ style installation |
Overall | 4-4.5 | The tool is filled with features that would benefit any organisation that utilizes SSRS reports. And its ROI allows it to be accessible to teams whether large or small. |
