Web-based Reporting In Java

Every application has 3 kind of blocks; parameters, transactions and reports. Reporting is a fundamental part of applications. It begins with a “one page” printing then expands to “Business Intelligence” reporting. Reporting is interpretation and analysis (via SQL) of raw data and presenting it in readable and printable format (via Reporting Tools). As function widens, SQL and reporting tools differentiate a lot. Data warehousing (OLAP) is such a special analysis and reporting area.

Your web-based reporting journey will probably begin with figuring out that web-pages are not printer-friendly. So we need a reporting tool. Reporting tools are not just an ordinary tool in your toolbox. It determines your application success and it is important as much as transactional processing (OLTP). If you can’t show the data as desired, it has no meaning for end users.

In web-based applications, reporting has some difficulties:
1- Determining Reporting Tool: There are many commercial and FOSS solution out there but their web-enabled reporting capabilities are questionable. If it is commercial, it will introduce license cost and increase your solution cost for your customer. If it is FOSS, then you are dependent to voluntary open source developers. In our case, we had tried to use FOP (XSL-FO based) many years ago for our reporting requirements, we couldn’t overcome the problems of localized fonts and can’t get timely responses and fixes. Businesses and projects can’t wait.

2- Integrating to Your Applications: Reporting is not only composed of design tool, it has a runtime engine that you should integrate with your JDK. If it works in your application JVM, than JDK version compatibility is important. If its run-time is detached, than it is going to be another problem to use your business objects in the reporting environment. If your server is Unix-based, reporting tool platform-dependent MS-Office (Excel) features may not work.

3- Printing: This is the most problematic topic. In web-based reporting, we used Internet Explorer’s “Print Template”s that solves web-page printing problems (via MeadCo's ScriptX product). It solves graphical printing problem. Even you can write your own templates. What about dot-matrix or label printing that you have to communicate with printer directly (Raw Printing). Here, we had to write a custom ActiveX component for this purpose. Another problem is server-side printing. If your client doesn’t want to install someone’s printer driver, you have to use server-side printing. You only install printer drivers on server then your client can print via your print-server. Another point is that many reporting tools claim that they can easily handle printing problems with PDF-reports. I don’t think that PDF is a good presentation format for “default” report format. I think first format should be HTML, it is lightweight, faster and can be dynamic (i.e. drill-down). Then report should be converted to any format including PDF. A final note, we can’t use Java’s printing API since our pages are JSP (HTML).

4- Report-Design: In desktop applications, reports can be easily generated with drag&drop ease. In web reporting tools, this function is generally missing or weak. Reporting tools generally brings desktop-based design tools. Report generation is also a part of reporting. Every report producer user had to install this application that we lose web-based application advantages.

My other observation about reporting tools/frameworks:
Reporting Scripting Language: Although this is not related with web-based architecture, but I have to write about it here. Most of reporting frameworks brings a new scripting language that I thoroughly object. Why are we inventing a new language that we already have Java? A new scripting language brings a new learning curve, a new cost. “To make report programming easy” can’t be a reason since most of the report writers are programmers.

Dot-matrix Printing: Our search for text-based reporting function in Reporting Tools ended with no result. There was no direct support from Reporting Tools for this function. In our case, this was a major function that resulted to write our own reporting frameworks and tools. Your reports can be printed text-based not graphics-based. This can be achieved with some printing commands (i.e. ESC/P2) that may differ among dot-matrix vendors. Graphics-based printing within dot-matrix results low-quality prints, pagination problems, long-printing job, and high toner consumption.

XML Report Design: We developed XML design (clean and simple) feature on top of our current API set. Up to this feature, we were developing reports programmatically. XML reporting enabled us dynamic design which report designers can change every part of report without recompiling. In our XML design search, I was surprised how complicated the XML structure of other tools. I am not sure if everything can be done via GUI design tool without touching XML and its complexity adds another cost (We know in IDE GUI design, this doesn’t work all time and we have to touch to the low-level codes).