Can Reporting Services do this?
-
I've only been looking at Reporting Services for a couple hours, but am hoping for a shortcut. Like so much of Microsoft Documentation I've got an incredible amount of information but am having difficulty understanding quite where it fits in.
We have an Intranet that is ASP.Net based. Information is generally delivered from our Data Warehouse with custom pages which solicit parameters then display data, graphics (OWC), etc.
Reporting services would appear to be a good alternative to DataGrids and manual presentation, and offer a lot of benefits.
But will they work and play well together. Where I would in the past have created a page and invoke it with parameters from a URL, instead include a report services project (not even sure if that's the right term here) that does something similar?
Perhaps more important is deployment. Right now the ASP.Net project is deployed by packaging up all the pieces and copying it to our web servers. In trying to read through the documentation about Reporting Services I never really got a good sense of what a report "is" -- how does it fit into the ASP.Net world in terms of the physical on-disk items that need to be deployed? Or (as I suspect) do I now have to deply objects that are contained only within SQL, and create a new deployment mechanism?
Maybe my needs are two simple. I was hoping for something like a much smarted DataGrid. What I think I have with Reporting Services is a complete replacement for ASP.net and a whole new deployment approach.
Would someone who has gone through all this be willing to share a high level perspective of how it all can fit together?
-
OK, first thing -- what a report *is*: Microsoft has defined an XML based report definition format (.RDL file). This is (as far as I can tell ) a fully documented format. You can create these definitions either by hand (ack!), using a Reporting Services project in Visual Studio 2003, or by using a custom or 3rd party application (nothing out there now, but there will be).
Report definitions are stored in a SQL Server database. When a report is run, it is stored as an intermediate, unrendered format. You then have the option of outputting it to a variety of formats (HTML, PDF, etc). From a deployment perspective, "reports" or report definitions are never deployed directly to a web server.
BTW, Reporting Services is simply an ASP.NET application. It is fairly easy to include RS functionality in nearly any application -- it's methods and properties are exposed via a web service. It's also very easy to create parameterized reports -- again, the report definition is not stored on a web server, but within the RS database.
If you haven't downloaded the evaluation version, do so. Install the samples and look at how things are implemented. There are not only examples of reports, but also extending reporting functionality to other applications.
-
Thanks. We downloaded yesterday and one of my programmers was looking at it, we'll get together today to see if she got it installed (I had the pleasure of being in payroll meetings all day :crazy
.How about deployment. You build a report on your development machine that you link into a web asp.net project. How can it be deployed to a bunch of other web servers and/or SQL Servers running IIS and SQL?
I.e. is it more like a dot-net program that can be packaged up, or is it more like data in a SQL database?
For example, DTS packages if you take the straightfoward approach of storing them inside SQL Server become a real nusiance in terms of software development techniques -- no integration with VSS, can't package in an MSI package, etc. So we store them in structured files on disk all the time so they look like some other program component.
How will a "report" look in terms of integrating into the deployment of a program package?
-
Wow, lot's of questions in there.
As far as deployment, there are tools for deploying command-line RDL files to other Reporting Services databases. Unless you have a highly distributed environment, you'll probably have one ReportServer database, one Report Service running, and multiple websites that reference the reporting services web service.
The reports themselves are in a SQL database. The reporting services web service can be referenced in essentially any .NET project and deployed normally.
How will a report "look" -- well, the intermediate report get's rendered into an HTMLish format -- you could, however, code it to automatically render to a PDF or something like that.
I've got a series of articles coming on Reporting Services in the near future -- hopefully the can give a direction to work in. The best thing to do now is to "play" -- you'll pick up a lot very quickly. It's worth going through BOL for the command-line tools at least. There's also a good conceptual diagram of the architecture.
Hope that helps a bit.
-
Thanks. We are (Playing).
I think you may have hit on the key -- the report is itself a different thing deployed to a different place than the web pages that might refer to it.
Our initial thought that a report was kind of sort of like a web page -- it got packaged up along with the other pages (and associated dot-net stuff) and was deployed to the web server.
But it sounds like in designing a development lifecycle for this, we need to treat them as a prerequisite but not an associated component -- a report needs to be built separately, deployed first (to the report server), and then the web pages would simply use it.
Is that the right track?
I'm much more focused on lifecycle at present, because as soon as I tell N programmers they can use it, I will otherwise have N^2 different mechanisms created for producing, source-safing, staging, and deploying them.
-
This is an excellent discussion. I'm reviewing config mgmt process with a small dev team. We are considering Reporting Services and these are questions I have, too, since I've only just installed RS on the integration server. No dev experience yet. The dev guys are not really "into" config mgmt so I feel like I'm in for a ride. Sounds like I'll be revisiting the difficulties of using VSS w/SQL Server in managing deployment of RS objects. Any best practices would be greatly appreciated!
-michael
-
This is a good discussion. If anyone reading this thread already has experience in the deployment methods of RS, please think about writing articles regarding this subject. We too are about to embark on this and best practices would be great.
-
I'm disappointed not many people here seem active with Reporting Services. Is that a sign of just lack of use, or that it did not meet expectations?
Here is where we are. I had someone well versed in ASP and ASP.Net pages try to use it for a complex reporting project that we needed done. The task was to produce a variable sized spreadsheet of data that would be used as something like a PO to vendors. Of significance is that it needed to be displayable as a web page and also be able to produce an excel file to ship off, so the export-to-excel feature was very handy.
It worked very well. She was frustrated it took so long to learn it, cursing the documentation, but from my perspective it was about 3 days to get a working prototype including server-side production of the excel download. This means NO NEED FOR AUTOMATION WITH EXCEL. We have fought so many battles with reasonable approaches to export web data to excel it is sad -- OLEDB works the best, but is limited in what you can do, CSV an similar is very limited in formatting and fairly tied to web upload, and automation works best but seems practically impossible to make work reliably server side (and microsoft agrees and recommends against it).
Reporting services seems to solve that.
Deployment is still not done, but we think we have a strategy. For us the web server will also be the report server, so we are going to treat the output RDL's as though they were web pages, and then when we deploy the web pieces we will run a script to upload them into the report server. The reports will then be a project in the general Intranet solution we have in VS2003. Or I should say projects -- you can't have any structure within a report project, so you are stuck doing multiple projects if you wanted (as we do) to basically have output web pages be reports. So I think we'll have a directory structure under a ASPX project, and a parallel structure of projects for the reports. That's ugly -- and not at all sure how many projects are practical in VS2003.
For separate, application-only (non-web-related) report projects we will do something else, not sure yet. But this so far seems the best bet for us to keep the reports tied to the web projects they relate to, and be modifiable and installable together with them.
I'd still love to hear what others are finding as good practices, especially in terms of deployment, version control in conjunction with associated applications or web projects, etc.
-
Personally I think the multi-project issue you've raised will go away as other parties bring out report developing s/w (e.g http://www.cizer.com ). What you're really trapped in with here is that you can't just add an RDL file to a (say) web project and get the RS designer interface. I agree, it would be nice if it could/would do that, but I guess it doesn't work that way with web and win apps either (ie I can't add a winform to a web app).
Did you get a solution re: proj lifecycling the RS projects? Is there any reason why you wouldn't use integrated VSS (as per say a web app), other than the occassional annoying nuances of VSS
One of the main things I like about RS is the extensability. I've been mucking around with writing custom data providers, which should (generally) mean that any previous work you've done on custom objects is of use with RS also, as you can reasonably easily get a data provider up and going off your existing objects.
Just out of interest, are you using the webservice to retrieve/render your reports for users of your app, or url calls?
Steve.
Steve.
-
I think you can add a report PROJECT to a web project and get the RS designer interface.
And once you do that then VSS integration is automatic, at least in terms of the source.
For web project deployment we probably do not do it as Microsoft intended (I'm not even 100% sure what Microsoft intended). Long ago with ASP pages we scripted the deployment, and we just did the same thing in ASP.Net. We have a "build" machine which is a clean, virgin system. We script pulling down the VSS copies and then compile everything there, and from there we copy to the web machines as desired (e.g. deploy to a test first, then production).
We plan (at least tentatively for now, we have yet to start) to simply incorporate the RDL's into this, with the caveat that a script needs to run on the web server to load them. In fact there is no real need to have the RDL on the web server at all, and we may just run the script remotely if that works out (which I think it should). But the real point is that for Visual Studio purposes we plan to treat them just as another part of the web project.
Again, at least tentatively.
cizer's tool appears aimed at end users, not sure of the relationship there to the multi-project aspects of a developer incorporating it. At least for now we have no intent to present this to end users, but rather as a presentation tool for existing projects. On the other hand, I'd love to see a graphical query designer a la Access that was aimed at the typical Excel user (i.e. non-programming, no sql, no database knowledge).
-
G'day
I haven't looked into deployment to different environments yet, but i attended a MS demo last week and this question was raised.
The reply was to use some command line apps - which he also said 'aren't documented' - to move the reports to different servers.
I will be looking into tomorrow (thurs) and let you know what i find
Greg
-
IMHO rs.exe (using vb.net 'scripts' , why no c#?!?) and rsconfig.exe are the most useful of the avail cmdline tools. Prob i have found is that if I want to take settings that have been modified from ReportManager (say change a reports auth method) I will need to write a script (or c# commandline app) to do this. If anyone finds another way of transfering these settings, i'd be grateful if you sent it on.
Steve.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply