email article printer friendly

Build Reporting into Applications
Generating human-consumable output for your J2EE applications doesn't have to be like pulling teeth
by Peter Varhol

November 2003 Issue

It's a common enough scenario in any application development group. Your application does what it's supposed to do: accepts user input, crunches numbers, and produces the correct output. But it still doesn't satisfy the requirements, and it doesn't look like it ever will. The problem is the way the data is presented to the users. It's not that it's impossible to achieve the look and feel demanded by the users, but it's time-consuming and difficult to code. The JSP page designer is taking days to painstakingly prepare each one, which is putting the entire project behind schedule.

And it gets worse. The code to implement the reports is extensive, and while it's been segregated out of the page itself, it still requires testing. Testing takes still more time in a schedule that doesn't have the slack necessary to perform enough testing. And there are bugs in the code, which requires development resources to track them down and fix them. Moreover, while your team struggles to meet the requirements originally laid out, the users are putting in requests for additional reports. Business requirements change, after all, and enterprises have to respond rapidly to adapt when information needs shift. The need to respond quickly includes development projects, which have to deliver applications when they can help the business stay competitive or gain an advantage.

Does this sound like a familiar situation? For development groups that prepare reports manually for their applications, this scenario can be an ongoing nightmare. Perfectly usable applications can become derailed with such a seemingly innocuous issue of how to best deliver information to their users. And pity the maintenance programmers who have to go back in and change reports when user needs change after the application is already in production use. In many cases, the code is spread out among different components, poorly documented and difficult to understand, making modification and testing still more burdensome.

Fortunately, there are alternatives to hand-built report pages. Commercial software vendors such as Crystal Decisions (see Figure 1), Actuate, and ReportMill provide engines that can be embedded in applications and used to deliver high-quality reports from within your J2EE application. Depending on the format you need, at lease some of these solutions may also work with other types of applications, including those employing J2SE and even J2ME standards.

I'm not advocating a commercial reporting solution for all application needs. Commercial engines cost money, after all, and tight budgets often preclude buying software to integrate into custom applications. And if the software is targeted for hundreds or thousands of end users, a per-user or per-server licensing fee can quickly add up the costs. And sometimes it's simply not necessary to use a commercial reporting engine. The data output needs may be relatively simple, or there are only a couple of reports that will rarely change needed in the application.

For J2EE and other Java applications that produce human-consumable output, the decision on how to produce that output is one of the most difficult architectural trade-offs to be made. There are a number of factors to consider in the trade-off analysis, including features, report formats, performance, and cost.