User defined reports with SSRS - asp.net

I have an web application which serves SQL reporting services reports via the reportviewer control. Because of the complexity of some of the reports I use rdlc reports attached to business objects.
Now I would like to expand the system and allow some form of user-defined reports. Ideally I would like the users to connect their reports to the same business objects I use to create the rdlc reports.
Is there a control that allows users
to create/edit their own rdlc files?
Can rdl files be attached to
business objects?
Any hints/tips for writing my own
control to edit rdlc files? (I would
think this is a lot of work
and would only attempt if there is
no suitable answer to 1 or 2).
All my development has been done in VS 2005 with SQL 2005 but I could upgrade if new features in 2008 help with the solution.

This isn't much of an answer, but at my company I have put together our own Report Builder.
We have about 30 or so Reporting Service reports that our users can access through the web or desktop application. What we wanted to do was give our users the ability to take any given section within those reports and create their own.
If there is a report we have built for them but they don't want to see the graph, they can create the same report with out it. If they want to combine parts from 4 different reports to make one summary report they can drag those sections around on our custom builder and save it.
The report builder I had to put together pulls down all the different sub-reports they have chosen and reads through the XML adding them to a Report Builder Template XML file I have created. I then have to aggregate all the parameters so as to not ask for them more than once (parameter names do have to be unique across all reports if you don't want them aggregated). This new report XML is deployed to the server and the users can access them when ever they want.
I've also given them the ability to create their own cover pages, headers, and footers by dragging text boxes, images, global variables (date ran, created, ran by, page number, etc... anywhere on a blank canvas. I then convert all the items they've drug around and resized on this canvas in to another report XML file and deploy it as a sub-report that they can add to their custom reports.
Yes, this has taken quite a bit of work, but our users love it. We're in the process now of allowing them to create a report with special groupings so the report can be ran at different levels.
So it is possible, but there is no easy answer. =) I'd be glad to give advice to anyone who asks, but a direct copy of the code is a violation of my contract, but I'll do what I can outside of that.

I think SQL Reporting Services isn't meant for this kind of customization. You can hide and show controls and subreports, but stuff like interactive grouping etc isn't there.
You might look into a third-party reporting framework like Telerik's.

Related

MS Word template with loops, tables and charts

For our SaaS (LAMP) product reporting we are currently using JasperReports. We find it too cumbersome to develop reports with and the output in Word unworkable. Moreover, a couple of customers request to be able to develop simple reports themselves (to be used as mail merge). We would therefore like to develop templates right in Word. The idea is to have an application/webservice that would receive the Word template and JSON data from the LAMP application and return the filled-in report. The report has to support:
Loops inside content (repeating a document section several times while filling in array data)
Filling in tables (populating rows from array)
Filling in chart data in pre-created charts (from array)
This is the functionality we are using in JasperReports right now. Are there existing solutions to this? I've found quite a lot that can substitute simple variables, but no info about the the above three points. Will it be a lot of effort to write one from scratch? I would prefer a Windows OpenXML-based solution rather than a Linux PHPOffice-based one as I presume the former would handle the text split by spell-checker and language tags (though I'm not sure).
Windward and Docmosis are both commercial products that support the features you've listed and they are intended to be added to your application to provide reporting capabilities. Neither is are not OpenXML based. They can use Word documents as templates and perform the data merge into different output formats. Please note I work for Docmosis.
Aspose Words is another tool and it can populate a template but most of the power is through code rather than controls/directives in the template. Given your OpenXML thoughts, perhaps this is more what you are looking for.
More tools are recommended here in StackExchange.
I hope that helps.
ReportBox is a Web based reporting solution that can be used by any software application to generate documents and reports in Microsoft Word/ Excel/ PowerPoint/ HTML(DocX/Xlsx/PPTx/HTML) using OpenXML.
The process starts by building a Microsoft Word/ Excel/ PowerPoint/ HTML document as a template and uploading to ReportBox portal. Your application either sends data to ReportBox or ReportBox can pull data from your application database, which is then merged with the template to produce the finished report. Please note that I work for GreenThoughts.

Have a Crystal Report but not the XSD - how to extract it?

I have a Crystal Report used in an ASP.NET web application that I've just come into a project I'm assessing/turning around.
The reports are called from a web page or web service and are sent an ADO.NET dataset - using ReportDocument.SetDataSource for some tables with a relation etc - all defined largely in code - initially loaded from the database, but it looks like some data is even altered after load in the datasets. (don't ask)
I have several XSDs (and a whole bunch of source repository history) but none seem to match the report, and trial and error to find the right one is taking way too long.
I have added some data in the code, but I cannot get the report to allow me to add fields until I update the report data source, but I don't have the original XSD to point it to. I have to get the report updated to solve immediate needs and then I can address the strategic direction of refactoring this design/architecture.
Is there a way to extract the XSD from the Crystal Report?
In the end I used ds.WriteXmlSchema() to write the schema to a file and then pointed the report at the file to fix it up.

Reporting platform for Asp.net - with excel/pdf/word export

I am looking for a reporting platform for our asp.net application, which will allow the report to be exported in excel (for tabular data), or PDF/Word (for document reports like Invoice prints).
Are there any standard options available?
I tried Rdlc, but it does not seem to help in the second case (at least I dint see a way, if you can please enlighten me :) ).
Currently we are using Interop for excel export (I know its not recommended for asp.net, we are planning to switch soon), use rtf templates for word reports (which also makes them somewhat customizable) and we dont have pdf export (planning to build it). But it seems like a waste of effort if standard controls are already available!
Cheaper the better! Free rocks!!
What's the issue with Rdlc? You can create any kind of format into it. For invoice prints etc you can use list data region. Its used for free flow kind of stuff. Its like ASP.NET repeater. In your case, you will have only one row of data.
Edit: even Crystal reports has equivalent functionality. As said, you will have only one row of data for invoices etc.
In both Crystal & RDLC, you can even supply multiple rows of data to your free flow report and generate multiple invoices in one go. Can be very helpful feature for users.

Excel Upload to database table

I'm looking for the best solution to allow our users to upload XLS spreadsheet so that they can be used to populate tables in our data warehouse (DW).
Our users are heavy Business Object (BO) users, and BO lets you export to XLS. When they have data in a spreadsheet that needs to be loaded to the DW, they need a process to upload the data in the XLS to the DW's db. As a result, we end up with many of these "interfaces" when I think that what we really need is a programmatic automated feed. Using Excel as a data source for inter-system feeds, in my gut, just seems like a bad idea to me.
Question #1: I'd like to see if you agree and why or why not.
OK, there is no swimming against that tide, so I now take as a given that XLS uploads are here to stay for us. Now I need to find the best solution. First, I'll explain what we do now and then what I don't like about it:
Via web pages, we provide empty XLS files (no rows) with a defined set of columns. Each file is intended to be used to update a different target dest table. In each spreadsheet is an "upload" button. Pushing the Upload button results in the macro in the spreadsheet serializing the contents of the file to CSV and FTPing the data to server folder. Periodically, a scheduler fires off an Informatica ETL job that uses the CSV file as input and loads the data into a custom XLS-specific staging table and then, if the records pass edits, into the appropriate target table. Any errors encountered are logged to an error table. For each XLS file uploaded, the data ends up in a separate staging and error table that is specific for the file.
Some of the things I don't like include about our process are:
1) The macro code in the XLS is too exposed, includes passwords for example, can be tampered with and there are issues ensuring that the users are using the latest XLS templates.
2) Business Rule edits are placed in the ETL program, where they should probably be, but because we would like to catch the errors ASAP, i.e, in the spreadsheet, edits are also added to the macro code. This results in duplication of business edits. I want these rules in one place and centrally controlled. IMHO, I think putting any macro code in the XLS introduces a maintenance issue, even calls to stored procedures (some of which we have) or calls to web services (we haven't yet tried to call .NET Web Services from XLS macros.)
3) Every XLS file upload template has its own process with distinct set of staging and error tables and a custom screen for reporting errors encountered. It seems like we need a more generalized re-usable solution.
Besides often getting data exported to XLS from BO, the users like also Excel because it is easier to edit a large number of records and less clunkier than editing individual records via a web interface.
This is the general direction that I am thinking:
First, I want the users to have the ease of editing of Excel with editing, but without including embedded macros in the spreadsheet. I experimented with Farpoint's Grid with Excel compatibility...
http://www.fpoint.com/netproducts/spreadweb/tour/excel.aspx
...and I found that it was quite easy to allow a user the ability to open up an XLS file that resides on their PC and have it open up in a browser and be able to easily access the data read from server-side .NET web code. Excel isn't running locally in their browser, but the functionality of Excel is reproduced, presumably through a lot of client sided scripting that I expect would be a real pain to duplicate myself. You can even cut and paste from a local spreadsheet into the web's spreadsheet. This sounds great, by biggest problem is cost. Our company is near death and won't allow us to purchase any new software.
Next, I want to identify the common components across all spreadsheet upload processing and come up with generic processing code. For example, I imagine a table which defines each of our spreadsheets and the format of each including the column names and data type definitions, perhaps in terms of their destination columns instead of hard coding. Based on this table template definition, I can generate XLS templates for download from this table definition. I can also perform simple generic edits to ensure that the data entered matches the table definition. And one common web page can be used to present the data and allow report data type mismatch errors and allow for the user to correct them. I would also define a common table for storing the data in a "staging" table, using a table with two columns, submission #, row num, name and value, perhaps. No more "custom everything" is the goal.
Next I need to decide where to put the business rules. My dept's mgt firmly believes that all loading of data should be done by Informatica ETL batch processes and therefore the rules/edits belong "in Informatica". I have zero experience with Informatica tools, I am more of a .NET guy. I am therefore unsure as to how these rules are implemented but I suspect that they are not reusable in the sense that they can be used by a .NET web page to validate a particular record against. You see, in some cases, when the user is not performing a bulk upload, they do have the ability to edit a specific record and I would like the same edits that were applied by the ETL bulk insert process to be applied to an individual update attempt to a single record via a web page. If the solution to write a single web service or stored procedure that can be called from either the web page doing an update of a single record or called thousands of times for each record in a bulk upload? The latter sounds inefficient.
Your thoughts on anything above would be very much welcomed.
From a cost perspective, the efforts you'll need to go through to re-create spreadsheet functionality on the web will exceed the cost of Farpoint or other controls. Even if you made $20 an hour, do you think you could complete a working product in under 2 weeks? I think you have the facts on your side when you discussed maintenance issues if you allow ETL functionality to exist in Excel - you have twice the amount of work to maintain the transformation rules. I think you need to convince management that in order to create a maintainable, robust solution you need some flexible utilities.
Farpoint is a good choice. There is also SpreadsheetGear that is a .Net engine that interprets Excel macros and can run on a web server. It has a Win32 control that allows you to create a WinForms solution with very Excel interface functionality. Last time I checked there was no web control for the product. It does an excellent job of providing Excel capability for processing large amounts of data.
Good luck. I think you will find a good solution since you seem to have a good grasp of the pro's and con's of all the different potential solutions.

HTML Reporting Solution

What good components and packages are available for generating HTML reports based on report definitions? I have a truly horrific project where each report is a dedicated aspx page that builds one fantastically big HTML string, which it then assigns to a 'reportBody' Label control.
Standard grids are not a good solution as they provide no grouping capability, but I'm open to buying a grid that is friendly for grouping, printing, and exporting. FYI is one reporting engine option I'll be looking at. What else is there? SSRS may not be an option, as MSSQL may not even be an option.
BTW, this is an ASP.NET web site.
You can try ActiveReports.net
You can use i-net Clear Reports (used to be i-net Crystal-Clear). It has many different output formats like HTML, PDF, Postscript, etc. It can print and of course it supports grouping. It is platform-independent. You can it also use together with your ASP.NET. It support many different database like MS SQL, Oracle, MySQL, etc. But also other data sources are possible. The free and fully functional report designer is very easy to use.
Also, the pricing is far below other reporting tools such as Crystal Reports.
you can still use RDLC reports, and just build them in local mode (no SQL SERVER required). I routinely feed my RDLC reports data from the results of function calls rather than have them intimately tied to the database.
The DevExpress ASPxGridView has proven to be an excellent tool for this job.
Standard grids are not a good solution
as they provide no grouping capability
If you want to create your own, I can give you some advice. First, you could probably create the groups with ROLLUP or COMPUTE statements or similar in your SQL and use a grid.
I went the following route: reports are data-driven, so that I know which columns can be grouped and which ones need totals computed. I use a standard DataGrid, and in the ItemDataBound event, I keep a running total for any columns that require it, and then detect changes in the group column. When detected, I insert a group total, reset the running totals and insert out a new group header.
I did a quick prototype of this in a day. But by the time you work out all the little details to give the reports all the features they need, and make them look just right, you'll spend quite a bit of time and end up with a small mountain of code.

Resources