The Eclipse Business Intelligence and Reporting Tools (BIRT) team has released Milestone 3 of BIRT 2.0. This milestone showcases some of the more important features of the 2.0 release, including library and template support, a new charting wizard, chart SVG output, a new XML data source and improved PDF and Report generation performance.

BIRT 2.0 is making significant improvements over the initial release and demonstrates that the team is committed to making a feature rich reporting tool for the Java community. But don't take my word for it, download BIRT and give it a try.

Take a look at the feature set in BIRT 2.0 M3 and let us know what you think.

Is there any plan for BIRT to generate reports in the most important business format (spreadsheets)?

Business folks despite all the nice reports wind up requiring reports in spreadsheet format which usually means Apache POI for me, it would be nice if that capability were in this excellent tool.

BIRT 2.0 Final will support CSV output.
In addition there is an Extension Point for writting your own emitter.

Hi

Does BIRT allow Sorting of date and numeric fields-- even if the underlying beans are having the fields to be displayed as strings???

I was needing some help regarding the same.
 
My problem goes like this--
I'm designing a reporting tool for my firm here for which I'm thinking of using BIRT. Since my jsp is generic in nature, the fields are unknown at the jsp in which I'm including the BIRT tool. All the fields I'm getting are in String format, since the underlying Bean itself is generic and renders itself to the tool with all String Fields of data.
Now I need to sort the columns depending on the sorting option specified in some XML. But sorting for date and numeric fields, i'm not sure.
 
Kindly suggest, should I go for BIRT.
 
Thanx
--Nagraj.

HiDoes BIRT allow ...

Did you try posting on the BIRT forum? They answer most questions pretty good.

Hi;

If you need xls or SpreadsheetML (The Office 12 format), please take a look at Windward Reports as it provides those formats.

thanks - dave

http://www.windwardreports.com

check it out

Saw the new demo http://download.eclipse.org/birt/downloads/examples/misc/BIRT/BIRT_demo_Camv3.html

It was a brilliant reporting and charting product. Having used some other charting tools (KLGroup, JFreeChart, Crystal Enterprise...), I am surprisingly excited to see such a nice reporting tool. Many congratulations to the team on a job well done!

46 mb for the runtime?? Isn't it too much? However exceptional tool!

I'm very surprised by amount of features. I have to test it. I never looked into it because I don't expected some useful result in such short time.
Congratulation to team of developers. Who is behind it (IBM)?

I'm very surprised by amount of features. I have to test it. I never looked into it because I don't expected some useful result in such short time.Congratulation to team of developers. Who is behind it (IBM)?

see the fourth link (third main link)
http://www.google.com/search?q=birt&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official

Who is behind it (IBM)?

I think the folks at Actuate contributed a lot of work on this

It looks very good so far, it could become a viable alternative to Jasper Reports (which many people use)

but two things have strucken me so far:

a) Does this thing handle subreports

b) How does it perform with really big reports (I am talking int thousands of pages of exported PDF)

Many reporting tools usually get problems with those two situations, for instances jasper can handle subreports, but has problems with correct page breaks
and many reporting tools (jasper not anymore since the last release) get out of memory errors on big reports.

Subreports - yes
Big Reports - I believe they are switching from FOP to iText to deal with pdf issue.

IMHO, if your report is 1000 or more pages then you have a book and pretty much any reporting tool is wrong for the job. Who can mentally consume that much data?

I would look at maybe using Adobes tools to do something that big.

I am using BIRT with Hibernate ("report queries") and scripted datasets. So far, so good. The only issue I am having is that my I am using a Swing client and I need to generate the report on the server (np), download the report (np) and view the report on the client (p). Every PDF viewer I have found is bundled with something else (and thus costs too much) or doesn't work.

Can happen, in my case it happened a while ago, due to a request by the customer of having all reports bound into a single huge report. And no Adobes tools did not do it in that case, too slow and too crashy.

We ended up writing our own pdf concatenator based on itext,
the concatenator was around 50 lines long and concatenated all small reports into a single big one in a matter of a handful of seconds (15-20 or so) in a single big one.

But as I said trying to push out big reports is a common use case, just check out the jasper forum, the jasper guys recently just implemented such a thing, because people constantly had the problem, and jasper ran into out of memory problems in those cases.

And yes itext is perfect for pushing out such stuff, but that only works with pdf to a certain degree, so that you can avoid to build up a huge parsing tree.
Jasper to my knowledge deals with the memory footprint problem on some tree structures by providing its own harddrive based cache where the data is stored before being "pumped" out into the target format.
As I said, never underestimate the problem if having to pump out huge reports, it happens, and it happens quite often.

Oh, I know it happens. And will continue. I just think it is the wrong way to go about it. It is sort of like asking car manufacturers how well their autos drive off cliffs. :) We need to solve the right problem. Sadly, that seldom seems to happen.

I would say your concatenator was a better way to go. I've had to deal with products that write pdfs to the HD. Very painful. Part of the pain was that they used Word to create the PDF. But people are gonna want what they want. I'm sure BIRT will have to break down and handle outputing "War and Peace".



BTW, check out yesterdays ComputerWorld Shark Tank. It talks about reports. Funny stuff.

Users once asked me solution for a problem they had: they regurlary made selections in the user dimension for people that had rights to a gift, based on certain conditions.
The data warehouse is actually the best place of doing such a query.
The problem is that most tools I know, including Business Objects (the one used) don't support reports that don't fit into memory. So these 650.000 users (name, company, address, telnr, ...) couldn't be generated.

There's nothing "bad practice" about it. The rerporting tools just don't support these type of reports very well.

BTW, the solution was to get the SQL that BO generated and have the ETL tool dump the records directly into an MS-Access database. (BTW, they used Kettle to do this... www.kettle.be)

Cheers,

Matt

Sounds like the right solution to me. When people say report they think paper. But really, why not provide a subset that they can "report" off of.

>There's nothing "bad practice" about it. The rerporting tools >just don't support these type of reports very well.
Maybe not. But I bet the users will ask for a summary report too. And guess which one they will actually use. :)