Thursday, December 25, 2014

BIRT with Hibernate using POJO-s

In previous BIRT versions there were three ways to use BIRT with your Hibernate datasource:
  1. Just plain SQL on Hibernate database.
  2. Scripting data source.
  3. Hibernate ODA data source.
Previously I've been using plain SQL, but with complex database model it becomes very difficult (a lot of properties, joins and other relationships). Scripting data source using javascript is a bit too awkward for me, and certainly adds another level of application complexity, and another level of layers where "the things may go wrong". Finally, Hibernate ODA data source from JBoss tools - this is what I wanted to use in older times, when I was using Eclipse, but for plain no-jboss application there were a lot of problem with these tools. They seem to be related to SEAM. Anyway AFAIR I had more problems with maintaining proper hibernate configuration in Eclipse (especially that it was partially annotation, and partially XML based) than the value of having working hibernate queries in IDE.

Recently, during a work on another application using BIRT, I started to think about another approach: how to delegate BIRT datasources to pure Java providers, that could be parametrized easily from runtime (without BIRT API) and which return my own arbitrary Java object models. It can be hibernate entity model, it can be something else, like for example DTO objects model, whatever I want to use in report and I consider better structured for particular reports. The most important part here is that these models would refactor easily with compiler support during the application development.

After a little research and tests it turned out feasible using BIRT POJO datasource, and now I consider it the best way of making BIRT reports from Java. The full source code of my example is on github, and the description is below.

Model + Data Set


First let's have a look on the model:



I wanted to use some associated objects in the model, to see how it works in BIRT, so what we have here is the company under which there are few departments, and our target report will be the list of departments grouped by companies, displayed directly from the database. To be more specific - directly from Hibernate queries.

The first thing is that we need some data set that can be used on BIRT design time. POJO data source is pretty badly documented and to reveal how to do it I needed to read some of BIRT sources. But what I discovered during this work is that the data set for the BIRT design time can be any class providing public Object next() method (it goes then through PojoDataSetFromCustomClass in the BIRT engine). So here is my mock data set implementation:

There are no bingings to Hibernate at all during this stage so we can prepare our object lists for the report design time independently from the database itself. My mock data set returns companies with "Mock" prefix to make it feasible to tell apart mock objects, from the real ones. Under every company there are three departments created (IT, HR and Sales).

Now we need to package everything (entity model and mock dataset) to a single jar that will be connected to BIRT for a while.

Report design


Now we can start preparing new BIRT report starting from the POJO data source:


Then we need to add our jar to data source config, and check the option below:



Now we need to configure POJO data set, giving our mock data set class name as the objects source:


The important part here is the key under which BIRT will look for the data set (APP_CONTEXT_KEY_MOCKCOMPANYDATASET). This is not important yet, but will be important in real runtime, where we will switch the mock data set to real one.

Now we can just select the POJO class, and configure column mappings:


I used property of associated Department entity here to see how the column mapping will be done. It looks good, and now on the Preview Results tab we can see how the column data is generated by BIRT from the underlying Company objects:


It fetches them as the list of departments that could be grouped by company, which seems to be good initial data set to create intended report.

On the layout view I just put the list bound to this data set, and grouped items by company id:


Now it's possible to generate mock report from the BIRT designer:

The runtime


In the runtime now what we want to do, is to replace the mock data set from the design stage, with some real data fetched from the database by Hibernate using entity model. A lot of this code is just to start the report engine, but I described below what's important here:


In line 2 we create BIRT application context, that is just a HashMap. To this map we need to pass our objects collection, under the key configured on design time. My companyRepository.findAll() method returns Hibernate Query. The "collection" passed to the application context can be Collection itself (so the list() is an option here), but I prefer to use Iterator (iterate() option), because for bigger reports it'd fetch data from database sequentially, not in a big single list.

For really inquisive people - BIRT can convert following objects to its internal IPojoDataSet representation:

  1. Any object providing public Object next() method, using PojoDataSetFromCustomClass.
  2. Collection, using PojoDataSetFromCollection.
  3. Array of objects, using PojoDataSetFromArray.
  4. Iterator, using PojoDataSetFromIterator.
In line 27, when the task is ready to run, we need to pass the application context to the task, to replace mock data set, with our real runtime data set.

The finally rendered report (all entities in database have "Company" prefix) looks this way:
Everything above can be easily built and tested from the command line from my birt-hibernate-example sources.

4 comments:

  1. Many thanks for this articles, a lot of ressources on internet skip the last part how to send datas from the application !

    ReplyDelete
  2. Very good article. Thanks. I've been searching for this information for a long time.

    ReplyDelete
  3. Great article man! There's very little out there about the topic.

    I followed your approach but I have one issue.
    In the design phase I provided a jar with the mock data-set class. The problem is, when I run the report programmatically, it still search for that jar! And fails to generate the reports because of the missing jar.

    Any idea why is looking for the JAR even if I put the dataset in the context ?

    ReplyDelete
    Replies
    1. Maybe something has been changed in recent birt version? There's an option (or at least it was) in the designer "POJO data source properties" window - "Use Runtime properties for both Runtime and Designtime". It didn't affect anything AFAIR when I was preparing this howto, but it looked as an error at the moment. I have this option checked in on the screenshot. Maybe they fixed this? Please try uncheck this option, and define jars only for Designtime, and leave Runtime jars list blank.

      Delete

Note: Only a member of this blog may post a comment.