Re: Lose Weight Program for OFBiz - Birt and BI
+1 for Adrian.
IT departments use specific tools. And they would like to integrate those tools
with OFBiz. So any reporting tool should go in Extras and End User should
download them as per their need. We just need good documentation around all
these efforts to help end users.
Thanks
--
Divesh
On Mar 20, 2012, at 8:01 PM, adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz, instead
of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
We could include a metadata interface that external reporting tools to
can use to generate reports.
-Adrian
On 4/3/2012 10:27 AM, Divesh Dutta wrote:
+1 for Adrian.
IT departments use specific tools. And they would like to integrate those tools
with OFBiz. So any reporting tool should go in Extras and End User should
download them as per their need. We just need good documentation around all
these efforts to help end users.
Thanks
--
Divesh
On Mar 20, 2012, at 8:01 PM, adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz, instead
of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
Which is one of reasons to have mostly unused things (not only BIRT) out of OFBiz. BTW from this POV the POS is not a problem, since it's not a webapp, it runs only at demand... Jacques Anne wrote: Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- 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/
Re: Lose Weight Program for OFBiz - Birt and BI
I think BIRT should be moved to Extras. The main reasons being: - we're still not (IMO) giving enough power to the users themselves to create reports - not every company wants to use BIRT and nor should they have to - the engine is large, the integration is lightweight and last time I looked the API was pretty poorly documented IMO the best thing we could do for reporting in OFBiz is to provide some type of HTTP based data provider interface. Virtually every reporting tool can consume CSV or XML formatted data from web resources and it would allow user's to cut up the data any way they liked via their reporting tool of choice (even something like Excel could be used). We could consider creating some new entities and a UI for controlling what data can be published and to who, possibly even creating a UI that allows dynamic view entities to be constructed and published. Even this idea is possible to deploy as a hot-deploy component so doesn't necessarily need to exist in the framework but it's certainly a much more generic and accessible approach than what we have with BIRT (which it should be noted wasn't chosen for it's features but rather because it was the only one with a permissive license for inclusion). Regards Scott On 26/03/2012, at 8:25 PM, Jacques Le Roux wrote: Which is one of reasons to have mostly unused things (not only BIRT) out of OFBiz. BTW from this POV the POS is not a problem, since it's not a webapp, it runs only at demand... Jacques Anne wrote: Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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.
Re: Lose Weight Program for OFBiz - Birt and BI
Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- 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/ -- 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/
Re: Lose Weight Program for OFBiz - Birt and BI
Thank you Anne. Perfect. I think options like this can be made visible through some documentation. At least inside the code through comments. I know it's there for BIRT. On Sun, Mar 25, 2012 at 8:09 PM, Anne a...@cohsoft.com.au wrote: Just for the record, we disable the birt container. I don't like loading things I know aren't being used. Cheers, Anne. On 23 March 2012 22:33, Mansour Al Akeel mansour.alak...@gmail.com wrote: in the config for base: base/config/ofbiz-containers.xml: !-- load the BIRT container -- base/config/ofbiz-containers.xml: container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- 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/ -- 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
Re: Lose Weight Program for OFBiz - Birt and BI
in the config for base: base/config/ofbiz-containers.xml:!-- load the BIRT container -- base/config/ofbiz-containers.xml:container name=birt-container class=org.ofbiz.birt.container.BirtContainer/ This is what loads Birt. Not sure if there's something else needed to load it. Can this be temporary used until OSGI is introduced. OSGI makes it easy to load and unload any component. So (if done properly), no integration in the framework should be done. In this case Birt component should contain the logic to load its self when deployed into OSGI container. So those who needs it can just install it with one command. In the mean while, cleaning the code base will make it easier to look into the messy code in framework, and remove what is not needed. Which will help bringing new things like OSGI to the table. On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote: +1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- 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/
Re: Lose Weight Program for OFBiz - Birt and BI
Le 22/03/2012 04:47, Hans Bakker a écrit :
Hi Anne,
Birt has several advantages in the current integration and we use it
often on the warehouse entities. These entities are mostly not in the
BI component but in the application components.
Jasper reports and all others do not use the ofbiz framework but work
on the JDBC driver directly or even worse only work on mysql or are
mostly commercial.
Just to correct this, Birt is integrate currently in OFBiz (and tks a
lot for the work :) ), but jasper to if you load the interface. By
default you can use JDBC driver with these tools, put all have an api to
integrate it. Last time we work on integration with open office, it's
just a data preparation by the technical interface. If Birt move on
extra, a goal will be the simplify integration between service engine
and report layer.
Nicolas
Integration with Birt is using the ofbiz framework and works on any
data base that ofbiz runs on.
Regards,
Hans
With BI i mean the BI screens/forms, not the entities.
On 03/22/2012 09:47 AM, Anne wrote:
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 Bakkermailingl...@antwebsystems.com
wrote:
Jacopo,
you are making here a very negative review of the Birt
integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
From your remarks it seems then that it introduces dependencies from applications.
This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.
warehouse entities and reports on them belong to the applications, not
to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
From your remarks it seems then that it introduces dependencies from
applications. This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
I mean the framework should know nothing about applications
6. Incorporates the warehouse entities.
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.
warehouse entities and reports on them belong to the applications, not
to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
From your remarks it seems then that it introduces dependencies from
applications. This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
sure...but then i do not understand your comment...where do i indicate
there is a dependency from the framework on an application? Warehouse
entities are stored in the application?
On 03/22/2012 06:14 PM, Jacques Le Roux wrote:
I mean the framework should know nothing about applications
6. Incorporates the warehouse entities.
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
dependencies from applications to Birt in the framework?
sure because Birt is part of the framework.
warehouse entities and reports on them belong to the applications,
not to the birt application.
Regards,
Hans
On 03/22/2012 05:11 PM, Jacques Le Roux wrote:
From your remarks it seems then that it introduces dependencies from
applications. This is a part of what we are trying to avoid
Jacques
Hans Bakker wrote:
Jacopo,
you are making here a very negative review of the Birt
integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
On Mar 22, 2012, at 12:43 PM, Erwan de FERRIERES wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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. Please note that all the above points are covered also by screens/FOP; and the code in screens/FOP is cleaner and implements the MVC pattern as all the other screens. You didn't mention the only one reason that really makes meaningful to consider this Birt integration: after you have manually implemented (in the traditional way) controller entries, screens to run the reports and the data preparation code (that needs to be inlined in the Birt report definition) you can use the Birt designer to implement the ui. This is in my opinion a nice to have for an optional component but not enough to make it the default reporting engine for OFBiz. 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 These ones are not part of the Birt integration but are instead part of the BI framework that I originally designed (and you have expanded): in fact I still see a big potential for this tool, that it is for its nature optional and external to OFBiz (ideally it should run in a separate db) and I really hope to see it more exposed tomore contributors in the future if delivered as an optional application. I very strongly think about keeping this in the framework. BI component I agree, can go Regards, Hans I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? In its current status I don't see how this could happen; it was not a good move that some of the ootb reports have been converted to Birt because now we have another technology for reporting that it is not enough to become the primary tool; the reports generated using this tool in its current form are simply not good enough to stay; if we will ever want to deliver with the framework an official tool for reporting then its requirements/features should be carefully evaluated before taking a decision Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? I don't think that adding more Birt reports to OFBiz to make the OFBiz applications more dependent on this imperfect Birt integration would be the right way to go. Instead we should rather gather all the requirements, design/select the proper tool (Birt of what else) and then integrate it properly and finally convert all the application reports to it. But even if we will reach that point I would see some potential to treat it as an optional/separated tool (but this can be discussed). In summary my opinion is: for now *this* Birt integration should go to Extras and improved there; interested users will get it from there (together with the reports); if the community thinks we should have a default reporting tool packaged in OFBiz then we will start the architectural/requirement design phase (at that point we could even bring back again some of the existing Birt code, if we think it is the right way to go). Jacopo -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - Birt and BI
+1 to Mansour's comments. I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and Groovy I currently 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. (points are from Hans earlier email, though maybe my idea of fully integrate isn't the same as Hans). I presume I can also incorporate the warehouse entities, and use minilang (Hans' other two points), though I haven't yet tried either. Maybe it is easier to do these things with Birt, but I don't have any difficulty with JasperReports. More importantly to me, if I decide to drop JasperReports and move to something else later, it won't be very difficult. I am sure Hans integration of Birt would be very useful for those who use Birt, and I expect they appreciate his effort. If Birt was in Extras, perhaps some of those people would be more likely to contribute to its maintenance. Cheers, Anne. On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote: I don't know why birt is integrated with Ofbiz. A reporting tools, is an add-on to any database driven system, and not essential for the over all functionality. Yes all of us need reports, and most of the time we use a reporting engine, but why can't it be separated from the code base, and used as a separate application ? From my perspective, the core should contain only components needed to bring it up to a functional state. Entity Engine, Service Engine, fall under this category. Some may argue that UI should be considered as well, and this is valid argument. But when it comes to reporting engine, I don't think so. On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES erwan.de-ferrie...@nereide.fr wrote: Le 22/03/2012 02:38, Hans Bakker a écrit : Jacopo, you are making here a very negative review of the Birt integrationas 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 I'm in two minds about BIRT. It's a fine tool to make reports, but underused in OFBiz. If the concerns Jacopo has about it were resolved, will it be kept in framework ? Also, creating more of those reports (with not available features in FOP), will this go in the right way to keep it there ? -- Erwan de FERRIERES www.nereide.biz -- 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/
Re: Lose Weight Program for OFBiz - Birt and BI
Currently, rptdesign is used in specialpurpose applications like ebaystore
and scrum, but also in core applications (accounting, order and product).
We have to provide reports in our applications, as it would be difficult to
maintain the concept of completeness of functionality without them.
Endusers requirements always dictate some kind of reports in applications.
I prefer to have a working solution ootb in OFBiz. Birt delivers that at
the moment.
Removing it creates another proposition issue (on top of all the others we
can think of why OFBiz is hard to sell).
Replacing it by something else would dictate roadmapping.
Regards,
Pierre
Op 20 maart 2012 12:47 schreef Jacopo Cappellato
jacopo.cappell...@hotwaxmedia.com het volgende:
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
Re: Lose Weight Program for OFBiz - Birt and BI
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for
other applications and they would prefer to integrate that tool with
OFBiz, instead of learning/using a new tool that comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to
maximize ready-to-use report and for small company which have not yet a
real reporting tool.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
+1 birt to extra
and there will also a jasperReport in extras
Le 20/03/2012 15:34, Mansour Al Akeel a écrit :
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM,adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz,
instead of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
From: Olivier Heintz holivier.lis...@nereide.biz
Le 20/03/2012 15:31, adrian.c...@sandglass-software.com a écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my experience, IT departments are already using a reporting
tool for other applications and they would prefer to integrate that tool with OFBiz, instead of learning/using a new tool that
comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to maximize ready-to-use report and for small company which have
not yet a real reporting tool.
Then we have fo.ftl files and PDF rendering. Minimalistic but working.
Jacques
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
+1 for Birt to extras.
Most of the useful reports OOTB are currently fo.
+1 to JasperReports in extras. I'm happy to volunteer for that one.
Cheers,
Anne.
On 22 March 2012 04:59, Jacques Le Roux jacques.le.r...@les7arts.comwrote:
From: Olivier Heintz holivier.lis...@nereide.biz
Le 20/03/2012 15:31,
adrian.crum@sandglass-**software.comadrian.c...@sandglass-software.coma
écrit :
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz,
instead of learning/using a new tool that comes bundled with it.
It will be nice if there is a default solution in OFBiz kernel to
maximize ready-to-use report and for small company which have not yet a
real reporting tool.
Then we have fo.ftl files and PDF rendering. Minimalistic but working.
Jacques
-Adrian
Quoting Jacopo Cappellato
jacopo.cappellato@**hotwaxmedia.comjacopo.cappell...@hotwaxmedia.com
:
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/
Re: Lose Weight Program for OFBiz - Birt and BI
Jacopo,
you are making here a very negative review of the Birt integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
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 integrationas
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
Re: Lose Weight Program for OFBiz - Birt and BI
Hi Anne,
Birt has several advantages in the current integration and we use it
often on the warehouse entities. These entities are mostly not in the BI
component but in the application components.
Jasper reports and all others do not use the ofbiz framework but work on
the JDBC driver directly or even worse only work on mysql or are mostly
commercial.
Integration with Birt is using the ofbiz framework and works on any data
base that ofbiz runs on.
Regards,
Hans
With BI i mean the BI screens/forms, not the entities.
On 03/22/2012 09:47 AM, Anne wrote:
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 Bakkermailingl...@antwebsystems.com wrote:
Jacopo,
you are making here a very negative review of the Birt integrationas
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:
Re: Lose Weight Program for OFBiz - Birt and BI
Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
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?
Currently, we work on a POC to use content for reporting, the report
mechanism is selected by the template type. We implement our first
reports with openoffice but I don't see blocking to use birt, jasper or
other. With this methods, all report engine can move on Extras and when
you deploy, you select for specific report the content thus the desired
engine.
My vision : by default Apache OFBiz embed Xsl-fo and when you download a
other report engine, it give some example and standard content reporting.
+1 to move birt in extras :)
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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
---
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - Birt and BI
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for
other applications and they would prefer to integrate that tool with
OFBiz, instead of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
Re: Lose Weight Program for OFBiz - Birt and BI
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM, adrian.c...@sandglass-software.com wrote:
I like the idea of keeping reporting tools separate from OFBiz. In my
experience, IT departments are already using a reporting tool for other
applications and they would prefer to integrate that tool with OFBiz,
instead of learning/using a new tool that comes bundled with it.
-Adrian
Quoting Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com:
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
