Ideal Reporting Engine

If you would find it interesting, I work for Imageright (I now am supposed to say ‘a Vertafore company’) and my daily job responsibilities include develop/design reports. The following may not be of interest to you. So what is it that I do when I say design/develop reports?

We design the way that reports should appear (just the structure) and link each report with a data source which might be a .NET collection or a SQL/Oracle database. Our reports are so-called powered by LogiXml reporting engine which has some great advantages and some restrictions which are more evident as our reporting suite expands in size. So I am involved in restructuring these report definitions – the layout is rendered as html and I modify the structure as well as the style using JavaScript (jQuery of course!) and CSS. Right now the way our system is designed requires us manage and control the same things between each and every report which typically would be the same for most of the reports. Our suite has at least 30 reports and almost every report typically has the same requirements. So being a C# developer, I am pretty annoyed every day when I look at the way things has to be done with that tool. Agreed its a great tool and as I think deep about developing my own reporting framework, the complexities that might arise make me appreciate the effort the developers have put into LogiXml framework. It is a great tool if you have nice web designer and a patient report developer. The advantage of Logi is the ease of development of reports and the nightmare only starts once there are loads of reports which require constant maintenance.

Ideal reporting engine

These are my two cents on how an ideal reporting studio should work. Some of you may not agree or most of you may not but I feel it would suit people like me pretty well.

People involved

For the reports to resurface, the only people I think should be involved are

SQL Developer who understands report requirements and who can write finely tuned SQL to return the data that the report would display

Report Designer who would use our ideal-tool to just link the query that the SQL dev has given. Then he would structure the report as required making use of the “functionalities” that the suite provides. He would then style the report using local styles or style all the reports using a global theme.

So, if a report has to be changed, the SQL guy would update his query and the tool should automatically update the columns if changed.  The tool would be intuitive enough to understand what columns are returned by the query and auto-populates the columns list which would then be available for the developer for further configuration.

The report designer should also be able to link a report to any .NET object.

The report designer should also have the facility to live-preview the report. If the report requires any input parameters, it should auto generate forms with global test data that the developer can pick from.

He should also be able to set up Unit testing rules on the report data screens and as the report is being designed he should be validate the report using these rules. These rules should be configurable either locally or globally.

And! most important of all, at each stage of report generation, the reporting engine should provide option to enable live feedback on what is happening which can be either turned on or turned off.

Core developers/Automation Engineers should be able to extend or run automated tasks against the reporting tool or against the files that the tool generates. So the reporting suite should come up with an API which allows them write custom or automate repetitive tasks. Again, the main goal for the suite should be that there should not be any task that appears repetitive – everything should be configurable as global as possible.

End User should constantly know what is happening. Progress bars for me are the most stupid things ever designed. Actually the progress bars has been so misused that they no longer represent what they were supposed to. The progress bars do not actually convey the original progress of the operation instead just tell the user “hey shit head! wait as something weird is going on”. Instead, give them progress bar if they are used to seeing progress bar and at the same time, as they click the progress bar, we should display them constant updates on what is happening.

Example:
Report generation begins …..
Data being fetched … estimated 20 seconds….
Processing the data … estimated 2 seconds….
Report being sent …. estimated 1 second ….

The estimations should be made automatically by the reporting tool and it should have a proper learning framework which performs simple math which says – given 10 input parameters for this report, it takes 5 seconds. This estimation should be close enough and need not be highly accurate. This way, the user would at least know how long he has to wait and in case the report is very complex and takes more time process, they would instead perform some operation which saves them time. Once the report is up, based on the settings, the client page (silverlight/flash/applet/web page/desktop app) should grab the attention of the user.

This kind of feedback also helps report developers understand what sections of the report can be tweaked and whether it is a problem of the query or the engine itself – this is the most common problem that we have – we have no idea whether it is a query issue or the engine issue. Do not keep your developers guessing on what is happening.

Client Support

The reporting suite should be easy to deploy. The set up package should be complete and ask as little feedback as possible from the installing user. All possible installation scenarios should be identified and give the end user a smooth experience. Installing reports should be as easy as connecting to the reporting server from a provided utility and send them the configuration files or just place the configuration files in default location. No more packaging your stuff and dealing with installs.

I would like to document more about this but I will come back on this one later.

If some of you who read this feels interested, I am looking for developing such a suite using Silverlight/WCF. If you want to join hands – I am always in!