View Full Version : BIRT 2.1 and Pentaho 1.6 RC2

09-10-2007, 12:25 PM
I am having problems trying to run BIRT with Pentaho. The sample report I am using does not use any parameter.

The error I am getting is:
Error: BIRT.ERROR_0007 - error running report samples\MySQL\clientes.rptdesign - org.eclipse.birt.report.engine.api.EngineException: The design file has error and can not be run. (org.pentaho.plugin.eclipsebirt.BIRTReportComponent)



09-11-2007, 09:51 AM

I changed the Logging Level to TRACE on the Action Sequence and noticed that the error message on Pentaho\pentaho-demo\jboss\server\default\log showed that the Report Design version was incorrect. I was Using Birt 2.1.3 while Pentaho includes the BIRT plugins for 2.1.0.

How difficult would be to add Birt 2.2 compatibility to Pentaho? If anyboidy has any suggestions I would like to try it.

09-11-2007, 10:34 AM
Just replace the birt jar file in the third party libs

09-11-2007, 12:53 PM
I am using BIRT 2.2 in 1.6RC using the route describe at



09-12-2007, 02:46 AM
Thanks to the replies I was able to have Birt 2.2 working with Pentaho 1.62 RC2.

I am wondering if it would be feasible to have the Birt runtime features available as well. For example, Table of Contents, Pagination, Abililty to Export, etc.

Thanks again,



Make sure to also copy your jdbc drivers to pentaho-solutions\system\BIRT\plugins\org.eclipse.birt.report.data.oda.jdbc_2.2.0.v20070615\drivers

09-12-2007, 02:52 AM

You can export a Report to PDF or HTML; a patch for Excel Output is available on JIRA: http://jira.pentaho.org/browse/BISERVER-316 .
Setup your ActionSequence for example to ask for an output format "html", "pdf" (or after the patch) "xls".


P.S. with regards to the drivers, I use JNDI in production to lookup the right datasource ; my production datawarehouse is a different from my development one. My drivers reside in the lib-directory of the app-server.

09-12-2007, 11:07 AM
Hi Klassjan,

Thanks a lot for your support. I can now show a proof of concept for the implementation of Pentaho. There are 2 things missing that I would need in order to have this ready for production:

1) Multicompany support. I find your comment about JNDI interesting because it seems that it would be the way to support this. The need we have is to generate reports for an ERP system. The system has 7 databases. Same schema one for each company. I want to enable the user to select the company for the report - add a menu somewhere - and then when when a report is selected I would need to swap the JNDI reference based on the company to report on. Can I do this with the Action Sequence?

2) If at all possible I would like to keep the BIRT Report Viewer Interface when viewing reports in Pentaho. My users can change the parameters, preview the report and select if they want to export within the viewer interface. If we were to use this as an option with the Action Sequence the result would not be as interactive.

Thanks again for your support. I am extremely excited about the whole functionality that Pentaho adds to our current BIRT reports.



09-12-2007, 02:36 PM

1) My thoughts would be to define the 7 various datasources in your appserver; define a reportparameter in birt to tell what datasource to use and use the scripting API to set the datasource to a value (for example using if-then-else constructions) using the JNDI parameter; I haven't looked into this and I don't know if all the API hooks exist. When this works, you could create an Action Sequence with the "company choices" and feed this parameter in the report-parameter.

2) I've looked into the source and integration the BIRT Report Viewer would be more difficult. Currently the platform invokes the BirtReportEngine and sends the data to a predefined outputstream, so it can be used in various environments like "batch distribution" or "process in background". An approach would be to create your own xaction-type and supporting JavaClasses that would generate HTML output with a specific redirect header / call to the webapp containing the report-viewer and pass all the variables in the URL string. In this way, you cannot use it for burst-reporting. You also might want to look into the security when the viewer will run in a separate webapp.

As said, I haven't looked into these things deeply and this is just my trail of thoughts... feel free (anybody) to contribute.