Re: Next assignment - Reports

Reporting is a big topic.

On one extreme, savvy business analysts constantly come up with new ways to mine data, and they want sophisticated tools to assist. If they don't like the way the data is stored in the database, they download it to their PC and transform it to the way they want, using Microsoft Access or Visual Foxpro or something along those lines.

On the other extreme, production reports run on schedule, are stored in a catalog, and rarely viewed except conditionally, and archived to optical media.

In the middle, an operator may prefer to select a report from a menu, fill in a prompt, run it to answer a question, but normally lacks the knowledge about table relationships and tooling that a data miner needs.

It seems that WYSIWYG designers, coupled with Query designers, coupled with runtime engines are what data miners prefers, while the guy responsible for running scheduled reports in a production setting prefers runtime efficiency.

Where does the RPG programmer fit in? He'd traditionally layout a print file with labels and output fields, then write a program to read data files, write to the print file, then use the WRKSPLF command to view and work with the output.

It seems to me that BIRT and Jasper Reports are tools that might appeal to the power user (data miner), but I'm not sure how an interface with RPG would help?

Nathan.




On Tue, Apr 22, 2008 at 8:08 AM, Pete Helgren wrote:

Your post seemed to be more about execution rather than design so I didn't wade into the design side but the designer side has always been easy on one hand (the drag and drop metaphor) vs very hard (understanding the relationships between the data available for the report). The first part, I think has been solved. iReport and BIRT along with Crystal Reports and tools from Sequel all have drag and drop functionality making the actually formatting of the report quite easy. The difficulty has always been in making sure that the data presented in the report relate correctly (the joins between tables are correct). This is the hardest part of a report designer and why most report writing tools aren't end user tools. Usually you buy a designer package and a runtime package and you would never put the designer tool in the hands of an end user because they would rarely understand the nuances of how the tables relate.

When I worked for NCS I was the product manager for developing a report writing tool that "end users" could use. It became an almost impossible task when all the requirements were pulled together (this was back in 1992 when GUI's were just getting to the point of viability). We were able to solve the "join" problems by building a data dictionary that determined the proper join relationships in the background as data elements were chosen but things like totals, subtotals, counts, averages and the like were difficult. Subreports were out of the question given the technology available. Eventually, NCS decided to license a third party tool (a horrible thing that ran in Windows 3.1) and, more recently, just told customers to talk to Sequel and got a referral fee. Bottom line: Report designers are a lot harder than report runtimes.

I'll look into being able to execute BIRT reports as well as Jasper with this open source project. It shouldn't be all that difficult. The real challenge is providing a report designer. I hope to solve that using some "widgets" that handle the complexity in the background. They can also be used in HTML (Web 2.0) designs.

I plan to generally post the availability here at in Midrange of the 0.4 release today sometime.

Pete