I thought Birt was a report generation/layout tool, like JasperReports and
many others. I don't understand why it would have anything to do with
datawarehousing.
I agree with Hans that datawarehousing is important. But I think that
should be part of BI, or other (possibly framework) functionality not tied
to presentation.
With the single exception of point 5, aren't the listed positives all
related to non-Birt functionality? Birt just manages the presentation? And
point 5 could be handled by competitors to Birt?
Cheers,
Anne.
On 22 March 2012 12:38, Hans Bakker <mailingl...@antwebsystems.com> wrote:
> Jacopo,
>
> you are making here a very negative review of the Birt integration....as
> any component sure there is room for improvement however....
>
> Some positives you did not even notice?
>
> 1. can use minilanguage for the retrieval
> 2. can use ofbiz fieldnames and entity names. (not databasenames)
> 3. can use OFBiz views.....
> 4. can fully integrate in the ERP application.
> 5. has many inbuilt output formats.
> 6. Incorporates the warehouse entities.
>
> Created/extended the datawarehouse which is essential for ordereporting.
> We have very big customers where using order reports directly on the OFBiz
> database was not possible.
>
> This warehouse function is essential for large customers
>
> I very strongly think about keeping this in the framework.
>
> BI component I agree, can go....
>
> Regards,
> Hans
>
>
>
> On 03/20/2012 06:47 PM, Jacopo Cappellato wrote:
>
>> L) framework/birt (and related dependencies/reports spread around): move
>>> to "Extras"
>>>
>>> M) framework/bi (and related dependencies - ecas/business rules and data
>>> - spread around): move to "Extras"
>>>
>>> This is an area where Hans and I are in disagreement and we didn't get
>> much feedback from others.
>>
>> So I would like to explain here why I think we should move the Birt
>> component and the Birt reports out of the framework and consider them as
>> optional tools.
>>
>> There are currently 18 reports in the applications implemented with Birt;
>> but they really seem experiments rather than something really usable; to
>> give you some examples:
>>
>> * in most of them there is this code like this:
>>
>> userLogin = null;
>> try {
>> userLogin = delegator.findByPrimaryKey("**UserLogin",UtilMisc.toMap("
>> **userLoginId","admin"));
>> } catch(e) {
>> Debug.logError(e,"");
>> }
>>
>> * all the retrieval logic (scripts) is inlined with layout definition and
>> this is something we try to avoid in all the existing screens
>> * entity list iterators are not properly closed
>> * some of the widget based financial reports have been converted to Birt:
>> their layout is still very simple and comparable to the widget based
>> versions available before Birt; so the conversion to Birt added a
>> dependencies on this component without adding real value (the rptdesign
>> files mix together data preparation scripts and ui definitions and in order
>> to maintain them you have to use the Birt designer); also some of them are
>> now broken: Income Stetements, Balance Sheet etc... This is probably caused
>> by the recent refactoring of JSR-223 but the original widget based PDF are
>> still there and are working fine...
>> * building a report with this Birt integration still requires a lot of
>> development work (similar to the one required to create a screen); but then
>> the code in the rptdesign is very difficult to maintain without the editor
>>
>> My questions are:
>> * do you really think that this way of integrating rptdesign reports is
>> the answer to fill the gap of a good reporting tool in OFBiz? Are you
>> actually using this integration for your reports?
>> * do we all agree to make this Birt integration the best practice
>> mechanism for all OFBiz reports?
>> * do you really think that we should replace all the existing widget
>> generated reports and FOP reports with rptdesign reports built using the
>> existing Birt integration under the framework?
>>
>> If any of your answers will be "no" then in my opinion it would be much
>> better to:
>> 1) make Birt integration an optional component, downloaded separately
>> 2) move the existing rptdesign reports out of the applications and keep
>> them in the external Birt component
>> 3) at this point users will have the option to use the Birt component or
>> not, but the ootb code will be clean and without dependencies on it; most
>> of all, we will not deliver reports that looks similar (ugly) but they are
>> implemented randomly with Birt or Widgets
>> 4) start evaluating, as a community, what should be the best practices
>> for ootb reports: what is the tool we want, what are the minimal
>> requirements etc... and then work together to get it in place and then
>> migrate all existing reports to it in order to have a consistent system; if
>> the community will not be able to reach a consensus on this, then we should
>> leave the decision about the reporting tool to use to the end user
>>
>> I think that the Birt integration is a nice optional component, and I see
>> that there may be interested parties, but in its current status it is not
>> something ready for becoming the primary reporting tool for the ootb
>> applications.
>>
>> Jacopo
>>
>
>
--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: (03) 9585 6788
Fax: (03) 9585 1086
Web: http://www.cohsoft.com.au/
Email: sa...@cohsoft.com.au
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
