Creating Reports with BIRT

Question

I checked out basic tutorials for BIRT and I felt that BIRT is highly database-centric. I have a totally different situation.

I have to generate reports from a different kind of data source. The data to be published is created on the fly (that's the work of another module) and I have complicated data structures holding the data (like List of Maps). I can't have a template, as it all depends on user interaction. But the data structure contains all the data that is required to create each report, namely column names, number of rows, and values of a row.

I'm really confused how to create reports from this kind of data source. BIRT only supports POJOs. Is there any way that I can specify a map as a dataset and a Java class as a data source? Or if not, what are the alternatives?

Answer 1

You have several different options:

1) Use the Scripted Data Source and pass in your list/map structure through the Application Context. In your report you will do something like this in the initialize event:

var myData = reportContext.getApplicationContext().get("myPassedInValue");
reportContext.setGlobalVariable("data", myData);

Then, in the fetch event of the scripted dataset, iterate through the list/map as necessary.

2) Create an ODA plugin that handles your data structure explicitly. This is a lot more leg work, but it makes designing the report easier.

3) Build the report and data programmatically using BIRT's Design Engine API.

Answer 2

I would argue BIRT is among the more data-agnostic tools out there. Any reporting tool is going to be data-centric; data are what you are trying to present to your users. BIRT (as you point out) has extensive support for both RBDMS and non-RDBMS sources (like POJOs).

I think POJOs are a logical fit here given your application-driven data collection. The issue is not in accessing the data; BIRT can do this easily via a POJO (plenty of references to this at the BIRT Exchange ). The issue comes into play with how you then intend to use the data in the report itself.

The most important dependency in the report's architecture is the ability for the various controls you are leveraging to communicate data to the user to apply the collected data in a meaningful way. The controls (charts, tables, etc...) care about two things: data types and column names (for access reasons). These two things are critical if a control is going to request an element from the data set and successfully apply it to the resulting canvas.

The first issue of column names can be easily handled by creating generic column names and simply populating those columns from your POJO as the data set is assembled at run-time. There will need to be some consistency and logic as to how the columns are managed across the data set and component layers, but that is doable. You also cannot add columns to the data set at run-time, but you can try and architect a maximum number of columns at design time and populate what is needed at run-time.

The second issue of data types can be a bit more limiting and requires more planning prior to implementation. If you were to name the first element in the data set Val1 (in keeping with the previous paragraph) and typed it as a string, it MUST remain a string each time you populate the data set or else you will see a run-time error. If you are not doing tons of calculations with the data, this can be overcome with data-type conversions as you translate the POJO into the data set at run-time.

So there are ways to do what you are looking to do. The implementation requires a great deal of planning both for the structure of the data set and the layout of the controls that leverage the data set. Remember that every event in the report's life cycle can be overridden with scripting, giving you a lot of leverage and flexibility.

Lastly, if you want to do all this at runtime, with a strongly-typed data set, you can. You will need to use the BIRT APIs to generate your reports with code. Anything you can do in the WYSIWYG Eclipse designer can be done with the extensive APIs in code. Check out BIRT Exchange for that as well. I would recommend looking into Report Libraries (another great feature of BIRT) to pull these complex items into a reusable portfolio so you only have to do a lot of this heavy lifting once.

Answer 3

What you may need to do is build your report from code based on your data. You did not describe your situation in enough detail to say so for sure. And building from code should be the done only in rare cases because it requires a program change for any change. But if your needs for control are outside of any reporting tool, then look at that approach. If you do take this approach, then you can use iText for PDF generation, OpenXML for DOCX/XLSX/PPTX, etc.

With that said, can you create an XML file from your POJOs? It is an extra step, but if you can, then you can feed that to most any reporting system, as long as the schema of your XML is constant. This would be a much better approach as you would keep the reporting layout, formatting, and logic in the reporting tool. Saves you a boatload of time and makes revisions a lot easier.

If you do go the XML route, please take a look at Windward Reports . (Disclaimer, I'm the CTO at Windward.) With Windward you design the reports in Microsoft Word, Excel, or PowerPoint - which makes report design and editing fast & easy.

For general information, I suggest java-reports and reporting-software . The key to a system that works well for you is one where the design tool is a natural fit for your style - so try several.