Can PowerShell script out SQL Server Reporting Services RDL files? - powershell

Is it possible to use PowerShell to script out SQL Server Reporting Services rdl files in SQL Server 2008? If so, can someone provide a code example of doing this? This would be a useful replacement for using a 3rd party tool to script out RDL files created by business users outside of my Business Intelligence department.
CLARIFICATION OF THE TERM "SCRIPT OUT"
By "script out", I mean I would like to automatically generate the underlying RDL file for each report on the server. For instance, when you code report in BIDS, you are generating a RDL file. When you deploy the file to the server, the file is somehow imported into the SQL Server ReportServer database and it is no longer a separate physical RDL file. I would like to extract all the reports from the server in a RDL file format.
I've used the RSScripter tool to extract the reports as RDL files, so I know it is possible using tools other than PowerShell. I would specifically like to know if it is possible to do it using PowerShell and, if so, get a sample of the code to do it.
CLARIFICATION ON WHY I WANT TO GENERATE RDL VERSIONS OF REPORTS
Why is it important to "script out" the reports to RDL files? I would like to check-in the RDL files to my source control system once a night to keep track of all reports created by users outside of my Business Intelligence department. I already keep track of all reports generated by my department since we develop our reports in BIDS, but I can't keep track of versioning history on reports built in the online Report Builder tool.
CLARIFICATION ON WHY POWERSHELL AND NOT SOMETHING ELSE
Curiosity. I have a problem that I know can be solved by one of two methods (API or RSSCripter) and I would like to know if it can be solved by a 3rd method.
Opportunity to expand my problem solving toolbet via PowerShell. Using PowerShell to solve this problem may provide the foundation for learning how to use PowerShell to solve other problems that I haven't tried to solve yet.
PowerShell is easier to understand for my team and me. In general, my team members and I can understand PowerShell code more easily than .NET code. Although I know this problem can be solved with some .NET code using the API (that's how RSScripter works after all), I feel it will be easier for us to code and maintain a PowerShell script. I also realize a PowerShell script will probably use .NET code, but I'm hoping PowerShell will already be able to treat the reports like objects in some way so I won't have to use the Reporting Services API to extract the files.
RSScripter doesn't support 2008 yet. In the past, I've used RSScript to script out reports. Unfortunately, it doesn't appear to support 2008 yet. This means I have to write code against the API right now since that's the only way I present know how to extract the files in an automated unattended manner.

a little late, but here you go
This PowerShell script :
1. Connects to your report server
2. Creates the same folder structure you have in your Report Server
3. Download all the SSRS Report Definition (RDL) files into their respective folders
https://sqlbelle.wordpress.com/2011/03/28/how-to-download-all-your-ssrs-report-definitions-rdl-files-using-powershell/

PowerShell doesn't provide any native, PowerShell-esque functionality for this, no. You can do this in PowerShell (as noted in the previous answer) only because PowerShell can access the underlying Framework classes. As you noted in your comment to the previous answer, it's no different from using the API in C# or VB.
The SQL Server team has not yet provided much in the way of PowerShell-specific stuff. They're primarily relying on .NET and T-SQL as "scripting languages."

I just realized the Content column in the ReportServer.dbo.Catalog contains the definition in an Image format. I wrote the following code to convert it to readable text:
SELECT CONVERT(VARCHAR(MAX), CONVERT(NVARCHAR(MAX), CONVERT(XML, CONVERT(VARBINARY(MAX), Content))))
FROM [ReportServer].[dbo].[Catalog]
WHERE Type = 2
With the above code, I can now automate writing the results to a flat file and then import the file into my version control system.

Anything that supports .Net can do this. See this Stackoverflow posting for some links to the API docs. The process is actually fairly straightforward - the API has a call to upload or download the .rdl file.
Report models are a bit more fiddly. You have to get the dependent reports (again an API call) and re-connect the data source if you upload a new report model. Again, not terribly strenuous.
Powershell should do this fine. I've variously done this with IronPython and C#. There's a also a tool called rs.exe that takes a vb.net script, tops and tails it with some includes and compiles and runs it behind the scenes.

Related

Updating media items using Sitecore Powershell Extensions

I'm looking for a way I can bulk update media items currently with Sitecore Powershell, but happy to here of any other suggestions.
I need a way of swapping out the blob value of a Sitecore media item for another media item. Is this even possible with Sitecore Powershell?
With 4.0 updated this week there will be a great way to do this using the new Remoting module functionality that Michael added as part of this issue. If you cannot hang on for a few more days feel free to contact me directly and I can pass the release binaries earlier.
I wouldn't honestly send remote files to server with the previous implementations as the files were going through serious serialization/deserialization in the process.
However if your files are already on the server there is another way that ingests files from the server file system into the media library that you can check out in a gist I've written a while back here.

What Tableau API does InterWorks uses in their Workbook SDK?

InterWorks has a Workbook SDK as part of its Power Tools for Tableau product. Does anyone know how they are able to do this? The SDK can access a workbook without Tableau Server so I don't think it's the JavaScript or REST API.
A Tableau workbook (.twb) file is in XML format. The structure may change between versions, but is relatively straight forward to follow. Most Tableau file formats are also XML. The formats ending in an x (like .twbx) are zipped directories that contain the XML file along with other files.
This means it is not too tough to read information from these XML files, or even modify them. I've edited them by hand in rare cases. Usually there is a better choice than hacking the XML internals, but you can. Just backup your file first, and don't expect Tableau support to help you if it leads to strange behavior on your workbook.
In addition to the Interworks SDK (which is a COTS product), Chris Gerrard published a free Ruby library for accessing Tableau workbooks https://rubygems.org/gems/twb (or gem install twb) and released the source on github https://github.com/ChrisGerrard/TWB, along with a few (but not all of) the scripts he's written that use the twb classes https://github.com/ChrisGerrard/TableauToolsRuby.
Chris gives some useful examples and scripts on his blog Tableau Friction, including this clever article on automatically documenting the relationships among calculated fields
http://tableaufriction.blogspot.com/2015/02/more-calculated-field-analysis-fields.html
Using twb, you can write simple Ruby scripts easily to look at workbook structure. Since Tableau can change the format when they release new versions of the software, using the SDK or twb Ruby gem could isolate your scripts from changes to the format.
Tableau has also released a Document API that supports a modest number common changes to workbooks - so you can write a script to say, update the connection string on a set of workbooks.
So you have at least four choices:
Use Interworks SDK and tools that come with support, documentation and a price tag.
Use the free open source twb library, and either reuse existing Ruby scripts or develop the ones you need. And hopefully contribute the source if you extend.
Roll your own XML parsing scripts.
Use the Tableau Document API if it supports your use case. https://github.com/tableau/document-api-python
In all cases, do backups and be prepared for some adjustments when Tableau releases a major or minor version update. Patch releases are pretty safe.

Is TFS Source Control really feasible for Dynamics CRM?

I'd really like to get a CRM solution under source control but there are a lot of issues. I was excited to see the SolutionPackager tool - thinking MS finally gave us a way to do this. However the tools to export the solution, extract it to files and check it into source control are not integrated. I'm working on a C# project that ties everything together because it's easier to work with the APIs in a single C# solution than deal with a combination of command line utilities such as tf.exe, PowerShell commandlets and plain old .cmd files.
Source files for plugins and Silverlight pages are easy to deal with but I'm looking to get all of the customizations under source control. SolutionPackager works well for tracking customizations made in the CRM interface, but fails in a lot of other areas. I want to create VS solutions for my web resources and reports but I have issues with the VS project and solution structures. SolutionPackager expects to find things where it puts them for repackaging and I'm sure it would not like to see a bunch of .sln, .csproj and .vspscc files interspersed with them.
I figured putting the VS solutions in a separate folder would be the answer but it's not easy. If I create a project for my web resources and try to put my existing .html, .css and .js files into it it wants to copy those into the project folder. I have to remember to use "Add As Link" each time. Worse yet, if I try to do the same with SSRS reports, the "Add As Link" feature isn't even available.
Has anyone done this successfully? I'm open to any suggestions.
I have seen below link but i have not get chance to implement it.when i have try it will post information.
http://blogs.msdn.com/b/crm/archive/2013/05/17/release-alm-for-microsoft-dynamics-crm-2011-crm-solution-lifecycle-management.aspx

PowerShell - Distributed Solution

I'm new to PS so I may get some of the terminology wrong.
If you want to roll out a custom PowerShell environment (snap-in) for a team of 30 developers/DBAs. What is the best way to do this... if you intend to be rolling out new functionality once a week? Does PowerShell 2.0 help in this regards?
Assumption:
There is no issue with everyone on the team installing PowerShell (v1 or v2)
Update:
Also see Jeffrey Snover's answer about v2 below.
It will depend to a certain extent on the sort of functionality changes that you intend to do. For our environment, we roll out a pretty standard PS install then add one line to everyone's profile to run a script from a shared folder on a server. Then in that script I can do whatever customization that I want to have applied to everyone.
We add the line to the machine specific MS profile (the one in %Windir%) this was an intentional choice. We do it that way so that the users essentially only get this on their production boxes. That way when they write something they can quickly log into a test box and run the script to make sure that the script will deploy without nay dependencies on these customizations.
Currently the customizations are pretty mundane. Mostly just some added functions and aliases. I also have a logger that I wrote in C# specifically for powershell so it loads that up from the dll that is in that same network folder.
Because I play around with my environment so much, I have this in my profile :)
$ProfileDir = ([System.IO.Directory]::GetParent($profile)).FullName
$localMSProfile = "$PShome\Microsoft.Powershell_profile.ps1"
$localAllProfile = "$PShome\profile.ps1"
$userAllProfile = "$ProfileDir\profile.ps1"
$userMSProfile = "$ProfileDir\Microsoft.Powershell_profile.ps1"
$allProfiles = ($localAllProfile, $localMSProfile, $userAllProfile, $userMSProfile)
This is why we added MODULE support in PowerShell V2 - it is the easiest mechanism to xcopy deploy sets of functions. The Module documentation is pretty light at this point but should be much better in a month or two.
Experiment! Enjoy! Engage!
Jeffrey Snover [MSFT]
Windows Management Partner Architect
If you are rolling out a new version of the snap-in weekly, switching version probably won't help with that part of things. However, you'll be developing on a newer platform, with the advantage of the extended functionality that comes with it.
As already suggested some scripts could ease the deployment pain to the point where you have to do nothing but maintain those scripts correctly and keep producing new builds.

Crystal Reports .Net Guidance

We have been using .Net and Visual Studio for the last six years, and early on developed a number of web based reporting applications using the .Net version of Crystal Reports that was bundled with Visual Studio. I'm unimpressed with that product: It seems incredibly difficult and convoluted to use. We had to make security changes, install various extra software, and so on.
Now, we are moving to VS2008 and version 3.5 of the .Net framework, and the time has come to redevelop old applications. Our Crystal .Net developers are long gone and I face a decision: Do we stick with Crystal or move to something else? We have the "full" version of Crystal Reports XI at our disposal.
We produce PDF versions of data extracted from various databases. Some apps use the built-in Report Viewer but this seems redundant with the flexibility of grid views. We still need to produce printable PDFs in the grid or in a downloadable Excel format.
Is Crystal Reports .Net worth persisting with, or should we work out how to use version XI?
Alternatively is there a simple and low cost way to generate PDF reports without using Crystal?
I have experience with reporting in CrystalReports (trying lite version bundled with Visual Studio), ActiveReports from DataDynamics (4 years, full version), Reporting from Telerik (trying trial version) and XtraReports from DevExpress (last one year).
I think ( and not only me :) ), the CrystalReports are most uneficient tool ( developer productivity ) from this tools. The DataDynamics are much, much more better, bud is littlebit buggy :(. Last year we decided to change reporting suite - we have choosen a XtraReports ( with source code ), and I'm totaly happy. The price is little, no bugs ( to now :) ), wonderfull support, and ( the most important ) the productivity was grown a lot.
I recomend you DevExpress's or Telerik's reporting tools.
I would recommended i-net Clear Reports (used to be i-net Crystal-Clear). It can read your existing *.rpt files. Has a better and easier-to-use API (which I admit is not saying much...).
Like you, I've had poor experiences with Crystal Reports, and my gut instinct is to post "avoid it at all costs" in all caps with lots of exclamation points. However, I've had my afternoon nap today, so I'll post like a grownup.
If all you're looking to do is pdf-ize (yes, it's a real word, damnit!) then you might look into some of the PDF widgets like ABCPDF and the like. It's relatively easy to pop a well-formatted web page into a PDF document and be done with it.
However, if you need tight report formatting, consider sticking with crystal reports -- you have a big investment and knowledge base in the technology. Or, alternately, you could switch to ActiveReports or SQL Server reporting services.
I guess the cost/benefit analysis is the cost of retraining your dev team, and investing in the new technologies.
Move away from CR: just get a good PDF generator and Excel engine for .NET, and feed those using your own database code. You can use all the powerful .NET features, including LINQ, without having to wrestle with the Crystal Reports runtime and its woefully inadequate documentation and support.
I can suggest that the built in Microsoft reporting framework works adequately. You can do local reports or MS SQL server based reports. There is a client control that displays reports and can export to formats such as pdf and Excel. Visual Studio can handle report design for the stack.
As far as if it is better than Crystal Reports, I'd say check it out and see if you like it any better or worse. I've worked with the Microsoft Report Viewer more than Crystal Reports but both seem to be fairly similar. Offhand, Crystal Reports seems to be a more advanced reporting tool but more complicated.
I'm not sure about how to utilize the Microsoft Report Viewer infrastructure outside of Visual Studio. If you are using Visual Studio it should all be available in there and you can follow the online help instructions for deploying the pieces for your servers to your servers.
I have used ActiveReports from DataDynamics and Crystal Reports. Of these two, I would recommend ActiveReports above Crystal based on ease of use and, more importantly, future maintenance.
We use Crystal in our shop too. We are currently on 8.5, which is way old and is no longer supported by SAP. We tried to upgrade to CRXI recently, which involved an entirely new API. We had to shelf the effort due to other priorities. While working on the upgrade I found support for CRXI on a number of forums. Google it.
I believe you can find a cheap way to generate PDFs without using Crystal. I believe Adobe gives the creation part away for free. I would visit their site and look into it.
I would recommend staying with Crystal only if you had a lot of reports that were already using that technology.
Get out of Crystal Reports. They are poor.
Check out SQL Reporting Services. It works very well with .NET. Try it out. There is a learning curve, but when is there not?
IMO, you should consider other criteria as well such as:
Cost of the software
Integration with your .NET applications
API and Programmatic flexibility (All said and done, there are always the "customizations" and tailoring. For such scenarios , developers eventually fall back on programmatic solutions vs. out of box
Now, in my experience (having used both Crystal Reports and SSRS(2005/2008) , though Crystal Reports does come with a friendly set of API, it fails in many basic criteria and developers end fighting the software. This is I say based on my experience with SSRS where developers are far more comfortable with. For starters, it uses XML extensively and the provision to use custom code assemblies does not harm either.
--I think you would where I am getting at---
"Consider & Evaluate SSRS*. If you are hesitant at first, then do a Proof of Concept and test your requirements. I have a feeling you will be pleased with what you see
especially considering your requirement of using PDF format.
Developers, especially , MSFT specialists will thank you
Leverage the Programmatic rendering of the reports (though it sounds fancy , trust me , its not more than handling an API call
For e.g.:
public Byte[] Render
(
string Report,
string Format,
string HistoryID,
string DeviceInfo,
[Namespace].ParameterValue[] Parameters,
[Namespace].DataSourceCredentials[] Credentials,
string ShowHideToggle,
out string Encoding,
out string MimeType,
out [Namespace].ParameterValue[] ParametersUsed,
out [Namespace].Warning[] Warnings
out string[] StreamIds);
Member of [Namespace].ReportingService
)
--- where Format will be "PDF"
Hope you find this relevant