OFBiz › OFBiz - Dev

[DISCUSSION] bi/birt component integration

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Pierre Smits-3

[DISCUSSION] bi/birt component integration

Hi All,
Currently the various business intelligence (BI) functionalities are
scattered in various components (consider all the overviews regarding
inventory positions, orders/deliveries per customer/supplier) in the
applications folder.

And on the other hand we have the BI component and the Birt component in
the plugins repo. Both of those components have minimal functionality
regarding the business intelligence aspect. But both components are
complimentary:

1. the bi (short for: Business Intelligence) component initialised the
OFBiz DWH and has secas and services for copying data from the ofbiz
database to the ofbizolap database, and
2. the birt (short for Business Intelligence Report Tool) component is
intended to deliver on functionalities to display data overviews in
various forms (tables, charts, in PDFs, UI widgets, etc)...

Unfortunately, both components lack of love from our community. But a bit
more love would significantly enhances the appeal of OFBiz for (potential)
adopters!

As a result from a customer project, I recently have been working a bit
more on the business intelligence aspect (see recent tickets in [1] and
[2]).

I believe it would be in the best interest of the project to integrate the
functionalities in the Birt component into the BI component. It will send a
clear message to both (potential) adopters and OFBiz developers (both our
contributors, and those not participating here but working on
implementations of adopters), being:

*everything related with business intelligence happens in and comes from
the bi component*.

What do you think?

When we have this, the community can start working on enhancing the single
component to increase its (and inherently OFBiz) appeal:

1. more entitiy definitions for dimension and fact tables (per [3], from
the OFBiz related books),
2. more scheduled services that move data from various ofbiz tables into
ofbizolap tables,
3. more UI widgets for displaying data aggregations (tables, charts) in
the form of portal pages widgets. These portal page widgets can then be
integrated by our adopters dynamically anywhere in the components of the
applications folder, e.g through starting/main pages.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
[2]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20birt%20AND%20status%20not%20in%20(Closed)
[3] https://www.amazon.com/gp/product/0471200247

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

swapnil

RE: [DISCUSSION] bi/birt component integration

Thanks Pierre for taking it up. It looks promising.

Are you also planning to document the overall high-level design at some
point of time. If yes I would suggest to cut a separate JIRA and share it as
and when you feel it's in good shape. It would be easy to
refer/review/refine and appreciate it in its entirety rather than going
through each of the tix separately to get the complete understanding.

Thanks & Regards,
Swapnil

> -----Original Message-----
> From: Pierre Smits <[hidden email]>
> Sent: Saturday, April 27, 2019 4:53 PM
> To: [hidden email]
> Subject: [DISCUSSION] bi/birt component integration
>
> Hi All,
> Currently the various business intelligence (BI) functionalities are
> scattered in
> various components (consider all the overviews regarding inventory
> positions, orders/deliveries per customer/supplier) in the applications
> folder.
>
> And on the other hand we have the BI component and the Birt component in
> the plugins repo. Both of those components have minimal functionality
> regarding the business intelligence aspect. But both components are
> complimentary:
>
> 1. the bi (short for: Business Intelligence) component initialised the
> OFBiz DWH and has secas and services for copying data from the ofbiz
> database to the ofbizolap database, and
> 2. the birt (short for Business Intelligence Report Tool) component is
> intended to deliver on functionalities to display data overviews in
> various forms (tables, charts, in PDFs, UI widgets, etc)...
>
> Unfortunately, both components lack of love from our community. But a bit
> more love would significantly enhances the appeal of OFBiz for (potential)
> adopters!
>
> As a result from a customer project, I recently have been working a bit
> more
> on the business intelligence aspect (see recent tickets in [1] and [2]).
>
> I believe it would be in the best interest of the project to integrate the
> functionalities in the Birt component into the BI component. It will send
> a
> clear message to both (potential) adopters and OFBiz developers (both our
> contributors, and those not participating here but working on
> implementations of adopters), being:
>
> *everything related with business intelligence happens in and comes from
> the bi component*.
>
>
> What do you think?
>
> When we have this, the community can start working on enhancing the
> single component to increase its (and inherently OFBiz) appeal:
>
>
> 1. more entitiy definitions for dimension and fact tables (per [3],
> from
> the OFBiz related books),
> 2. more scheduled services that move data from various ofbiz tables
> into
> ofbizolap tables,
> 3. more UI widgets for displaying data aggregations (tables, charts) in
> the form of portal pages widgets. These portal page widgets can then be
> integrated by our adopters dynamically anywhere in the components of
> the
> applications folder, e.g through starting/main pages.
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AN
> D%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
> [2]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AN
> D%20component%20%3D%20birt%20AND%20status%20not%20in%20(Close
> d)
> [3] https://www.amazon.com/gp/product/0471200247
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member* Apache
> Incubator <https://incubator.apache.org>, committer *Apache OFBiz
> <https://ofbiz.apache.org>, contributor (without privileges) since 2008*
> Apache Steve <https://steve.apache.org>, committer

Pierre Smits-3

Re: [DISCUSSION] bi/birt component integration

Thanks, Swapnil, for the feedback and the suggestions.

You can rest assured that I stay committed to this project and plan to do
more: one contribution at a time.

Why don't you raise the ticket yourself, before I can come to it, so that
it won't be forgotten.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Fri, May 3, 2019 at 12:43 PM Swapnil Shah <[hidden email]>
wrote:

> Thanks Pierre for taking it up. It looks promising.
>
> Are you also planning to document the overall high-level design at some
> point of time. If yes I would suggest to cut a separate JIRA and share it
> as
> and when you feel it's in good shape. It would be easy to
> refer/review/refine and appreciate it in its entirety rather than going
> through each of the tix separately to get the complete understanding.
>
> Thanks & Regards,
> Swapnil
>
> > -----Original Message-----
> > From: Pierre Smits <[hidden email]>
> > Sent: Saturday, April 27, 2019 4:53 PM
> > To: [hidden email]
> > Subject: [DISCUSSION] bi/birt component integration
> >
> > Hi All,
> > Currently the various business intelligence (BI) functionalities are
> > scattered in
> > various components (consider all the overviews regarding inventory
> > positions, orders/deliveries per customer/supplier) in the applications
> > folder.
> >
> > And on the other hand we have the BI component and the Birt component in
> > the plugins repo. Both of those components have minimal functionality
> > regarding the business intelligence aspect. But both components are
> > complimentary:
> >
> > 1. the bi (short for: Business Intelligence) component initialised the
> > OFBiz DWH and has secas and services for copying data from the ofbiz
> > database to the ofbizolap database, and
> > 2. the birt (short for Business Intelligence Report Tool) component is
> > intended to deliver on functionalities to display data overviews in
> > various forms (tables, charts, in PDFs, UI widgets, etc)...
> >
> > Unfortunately, both components lack of love from our community. But a bit
> > more love would significantly enhances the appeal of OFBiz for
> (potential)
> > adopters!
> >
> > As a result from a customer project, I recently have been working a bit
> > more
> > on the business intelligence aspect (see recent tickets in [1] and [2]).
> >
> > I believe it would be in the best interest of the project to integrate
> the
> > functionalities in the Birt component into the BI component. It will send
> > a
> > clear message to both (potential) adopters and OFBiz developers (both our
> > contributors, and those not participating here but working on
> > implementations of adopters), being:
> >
> > *everything related with business intelligence happens in and comes from
> > the bi component*.
> >
> >
> > What do you think?
> >
> > When we have this, the community can start working on enhancing the
> > single component to increase its (and inherently OFBiz) appeal:
> >
> >
> > 1. more entitiy definitions for dimension and fact tables (per [3],
> > from
> > the OFBiz related books),
> > 2. more scheduled services that move data from various ofbiz tables
> > into
> > ofbizolap tables,
> > 3. more UI widgets for displaying data aggregations (tables, charts)
> in
> > the form of portal pages widgets. These portal page widgets can then
> be
> > integrated by our adopters dynamically anywhere in the components of
> > the
> > applications folder, e.g through starting/main pages.
> >
> > [1]
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AN
> > D%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
> > [2]
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AN
> > D%20component%20%3D%20birt%20AND%20status%20not%20in%20(Close
> > d)
> > [3] https://www.amazon.com/gp/product/0471200247
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member* Apache
> > Incubator <https://incubator.apache.org>, committer *Apache OFBiz
> > <https://ofbiz.apache.org>, contributor (without privileges) since 2008*
> > Apache Steve <https://steve.apache.org>, committer
>

Michael Brohl-3

Re: [DISCUSSION] bi/birt component integration

In reply to this post by Pierre Smits-3

Hi Pierre,

+1 for the initiative as a whole.

One remark though to the current approach: you are creating al lot of
singe Jira issues for new tables, services to load data etc. I currently
do not find the functional part, for example UI elements and
functionality to view the informations loaded into the datastore.

From my perspective, it does not make sense to add tables to the
datamodel and services to the codebase without having a functional part
depending on it.

I think it would help to maybe pick a single aspect (e.g. sales channel
dimension) of the overall approch and implement all of the needed parts
(database mode, service, UI and example data) for it to show what the
desired outcome would be. I'm sure it would help to get the work
accepted and into the codebase.

Thanks,

Michael

Am 27.04.19 um 13:22 schrieb Pierre Smits:

> Hi All,
> Currently the various business intelligence (BI) functionalities are
> scattered in various components (consider all the overviews regarding
> inventory positions, orders/deliveries per customer/supplier) in the
> applications folder.
>
> And on the other hand we have the BI component and the Birt component in
> the plugins repo. Both of those components have minimal functionality
> regarding the business intelligence aspect. But both components are
> complimentary:
>
> 1. the bi (short for: Business Intelligence) component initialised the
> OFBiz DWH and has secas and services for copying data from the ofbiz
> database to the ofbizolap database, and
> 2. the birt (short for Business Intelligence Report Tool) component is
> intended to deliver on functionalities to display data overviews in
> various forms (tables, charts, in PDFs, UI widgets, etc)...
>
> Unfortunately, both components lack of love from our community. But a bit
> more love would significantly enhances the appeal of OFBiz for (potential)
> adopters!
>
> As a result from a customer project, I recently have been working a bit
> more on the business intelligence aspect (see recent tickets in [1] and
> [2]).
>
> I believe it would be in the best interest of the project to integrate the
> functionalities in the Birt component into the BI component. It will send a
> clear message to both (potential) adopters and OFBiz developers (both our
> contributors, and those not participating here but working on
> implementations of adopters), being:
>
> *everything related with business intelligence happens in and comes from
> the bi component*.
>
>
> What do you think?
>
> When we have this, the community can start working on enhancing the single
> component to increase its (and inherently OFBiz) appeal:
>
>
> 1. more entitiy definitions for dimension and fact tables (per [3], from
> the OFBiz related books),
> 2. more scheduled services that move data from various ofbiz tables into
> ofbizolap tables,
> 3. more UI widgets for displaying data aggregations (tables, charts) in
> the form of portal pages widgets. These portal page widgets can then be
> integrated by our adopters dynamically anywhere in the components of the
> applications folder, e.g through starting/main pages.
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
> [2]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20birt%20AND%20status%20not%20in%20(Closed)
> [3] https://www.amazon.com/gp/product/0471200247
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>

smime.p7s (5K) Download Attachment

Pierre Smits-3

Re: [DISCUSSION] bi/birt component integration

Michael, all,

First of all, the abundance of tickets related to the subject (see 1) are
there to enable fellow community members to take small bites to get the
elephant cake eaten.

Your suggestion is appreciated, and taken to heart. Today, I have taken
steps toward that goal. I started reworking OFBIZ-10991 and OFBIZ-11074.
The next steps is to work on OFBIZ-10990 for this channel part.
After this, I will present a pull request encompassing the contributions of
all three tickets to the community for review.

This way the community can see it come together with existing
functionalities, and the result can be experienced through the Report
Builder UI functions (see[ 2]) in the BI component.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20assignee%20is%20not%20EMPTY%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20bi%20ORDER%20BY%20updatedDate%20DESC
[2]
https://demo-trunk.ofbiz.apache.org/bi/control/ReportBuilderSelectStarSchema

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Sat, Feb 1, 2020 at 2:05 PM Michael Brohl <[hidden email]>
wrote:

> Hi Pierre,
>
> +1 for the initiative as a whole.
>
> One remark though to the current approach: you are creating al lot of
> singe Jira issues for new tables, services to load data etc. I currently
> do not find the functional part, for example UI elements and
> functionality to view the informations loaded into the datastore.
>
> From my perspective, it does not make sense to add tables to the
> datamodel and services to the codebase without having a functional part
> depending on it.
>
> I think it would help to maybe pick a single aspect (e.g. sales channel
> dimension) of the overall approch and implement all of the needed parts
> (database mode, service, UI and example data) for it to show what the
> desired outcome would be. I'm sure it would help to get the work
> accepted and into the codebase.
>
> Thanks,
>
> Michael
>
>
> Am 27.04.19 um 13:22 schrieb Pierre Smits:
> > Hi All,
> > Currently the various business intelligence (BI) functionalities are
> > scattered in various components (consider all the overviews regarding
> > inventory positions, orders/deliveries per customer/supplier) in the
> > applications folder.
> >
> > And on the other hand we have the BI component and the Birt component in
> > the plugins repo. Both of those components have minimal functionality
> > regarding the business intelligence aspect. But both components are
> > complimentary:
> >
> > 1. the bi (short for: Business Intelligence) component initialised
> the
> > OFBiz DWH and has secas and services for copying data from the ofbiz
> > database to the ofbizolap database, and
> > 2. the birt (short for Business Intelligence Report Tool) component
> is
> > intended to deliver on functionalities to display data overviews in
> > various forms (tables, charts, in PDFs, UI widgets, etc)...
> >
> > Unfortunately, both components lack of love from our community. But a bit
> > more love would significantly enhances the appeal of OFBiz for
> (potential)
> > adopters!
> >
> > As a result from a customer project, I recently have been working a bit
> > more on the business intelligence aspect (see recent tickets in [1] and
> > [2]).
> >
> > I believe it would be in the best interest of the project to integrate
> the
> > functionalities in the Birt component into the BI component. It will
> send a
> > clear message to both (potential) adopters and OFBiz developers (both our
> > contributors, and those not participating here but working on
> > implementations of adopters), being:
> >
> > *everything related with business intelligence happens in and comes from
> > the bi component*.
> >
> >
> > What do you think?
> >
> > When we have this, the community can start working on enhancing the
> single
> > component to increase its (and inherently OFBiz) appeal:
> >
> >
> > 1. more entitiy definitions for dimension and fact tables (per [3],
> from
> > the OFBiz related books),
> > 2. more scheduled services that move data from various ofbiz tables
> into
> > ofbizolap tables,
> > 3. more UI widgets for displaying data aggregations (tables, charts)
> in
> > the form of portal pages widgets. These portal page widgets can then
> be
> > integrated by our adopters dynamically anywhere in the components of
> the
> > applications folder, e.g through starting/main pages.
> >
> > [1]
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
> > [2]
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20birt%20AND%20status%20not%20in%20(Closed)
> > [3] https://www.amazon.com/gp/product/0471200247
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
>
>

Jacopo Cappellato-3

Re: [DISCUSSION] bi/birt component integration

In reply to this post by Michael Brohl-3

My main concern about this proposal is that the BI component is intended to
provide a "universal data model" (of dimensions, facts and star schemas)
for OLAP that is independent from the specific tools adopted to actually
perform the analysis (reporting tools, user interfaces etc...); its role
for OLAP is similar to the role of the OFBiz "universal data model" (of
entities and views) for OLTP that we all know and love.
On the other hand the Birt component is intended to integrate one specific
technology platform (Birt from Eclipse) to create data visualizations and
reports.
If we merge the two components, an adopter that would like to use a
different technology on our "universal data model" of dimensions/facts/star
schemas would have to deal with more unneeded code and dependencies (on
Birt).
I agree with Pierre that the BI component would need more attention to be
appealing to users; in its current form it is just a Proof Of Concepts
(POC) of some of the great ideas of "The Data Warehouse Toolkit"; but in my
opinion we should focus on improving and completing
the dimensions/facts/star schemas and the scripts that populate them; I am
fine with the idea of moving the definitions of dimensions/facts/star
schemas to the BI component (similarly to what was done with the entity
definitions in the "datamodel" component).
On the other hand, the Birt component can be improved by using and
leveraging more the data model provided by the BI component.

Jacopo

On Sat, Feb 1, 2020 at 2:05 PM Michael Brohl <[hidden email]>
wrote:

taher

Re: [DISCUSSION] bi/birt component integration

I think Jacopo got it just right!

BI to me means a collection of complex queries and services that give
insightful information (not necessarily even visual). Birt on the
other hand is a specific tool that makes it possible to design and
create reports interactively using a drag-and-drop behavior and it is
one of multiple options available. Hence BI is a generic thing while
BIRT is a specific tool. Furthermore, BIRT has lots and lots of
dependencies which might not be appealing to everyone using it.

So I think the two represent entirely different concepts. And the only
relationship might / should be that birt depends on some things in BI
but not the opposite.

On Wed, Feb 5, 2020 at 2:20 PM Jacopo Cappellato
<[hidden email]> wrote:

>
> My main concern about this proposal is that the BI component is intended to
> provide a "universal data model" (of dimensions, facts and star schemas)
> for OLAP that is independent from the specific tools adopted to actually
> perform the analysis (reporting tools, user interfaces etc...); its role
> for OLAP is similar to the role of the OFBiz "universal data model" (of
> entities and views) for OLTP that we all know and love.
> On the other hand the Birt component is intended to integrate one specific
> technology platform (Birt from Eclipse) to create data visualizations and
> reports.
> If we merge the two components, an adopter that would like to use a
> different technology on our "universal data model" of dimensions/facts/star
> schemas would have to deal with more unneeded code and dependencies (on
> Birt).
> I agree with Pierre that the BI component would need more attention to be
> appealing to users; in its current form it is just a Proof Of Concepts
> (POC) of some of the great ideas of "The Data Warehouse Toolkit"; but in my
> opinion we should focus on improving and completing
> the dimensions/facts/star schemas and the scripts that populate them; I am
> fine with the idea of moving the definitions of dimensions/facts/star
> schemas to the BI component (similarly to what was done with the entity
> definitions in the "datamodel" component).
> On the other hand, the Birt component can be improved by using and
> leveraging more the data model provided by the BI component.
>
> Jacopo
>
>
> On Sat, Feb 1, 2020 at 2:05 PM Michael Brohl <[hidden email]>
> wrote:
>
> > Hi Pierre,
> >
> > +1 for the initiative as a whole.
> >
> > One remark though to the current approach: you are creating al lot of
> > singe Jira issues for new tables, services to load data etc. I currently
> > do not find the functional part, for example UI elements and
> > functionality to view the informations loaded into the datastore.
> >
> > From my perspective, it does not make sense to add tables to the
> > datamodel and services to the codebase without having a functional part
> > depending on it.
> >
> > I think it would help to maybe pick a single aspect (e.g. sales channel
> > dimension) of the overall approch and implement all of the needed parts
> > (database mode, service, UI and example data) for it to show what the
> > desired outcome would be. I'm sure it would help to get the work
> > accepted and into the codebase.
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 27.04.19 um 13:22 schrieb Pierre Smits:
> > > Hi All,
> > > Currently the various business intelligence (BI) functionalities are
> > > scattered in various components (consider all the overviews regarding
> > > inventory positions, orders/deliveries per customer/supplier) in the
> > > applications folder.
> > >
> > > And on the other hand we have the BI component and the Birt component in
> > > the plugins repo. Both of those components have minimal functionality
> > > regarding the business intelligence aspect. But both components are
> > > complimentary:
> > >
> > > 1. the bi (short for: Business Intelligence) component initialised
> > the
> > > OFBiz DWH and has secas and services for copying data from the ofbiz
> > > database to the ofbizolap database, and
> > > 2. the birt (short for Business Intelligence Report Tool) component
> > is
> > > intended to deliver on functionalities to display data overviews in
> > > various forms (tables, charts, in PDFs, UI widgets, etc)...
> > >
> > > Unfortunately, both components lack of love from our community. But a bit
> > > more love would significantly enhances the appeal of OFBiz for
> > (potential)
> > > adopters!
> > >
> > > As a result from a customer project, I recently have been working a bit
> > > more on the business intelligence aspect (see recent tickets in [1] and
> > > [2]).
> > >
> > > I believe it would be in the best interest of the project to integrate
> > the
> > > functionalities in the Birt component into the BI component. It will
> > send a
> > > clear message to both (potential) adopters and OFBiz developers (both our
> > > contributors, and those not participating here but working on
> > > implementations of adopters), being:
> > >
> > > *everything related with business intelligence happens in and comes from
> > > the bi component*.
> > >
> > >
> > > What do you think?
> > >
> > > When we have this, the community can start working on enhancing the
> > single
> > > component to increase its (and inherently OFBiz) appeal:
> > >
> > >
> > > 1. more entitiy definitions for dimension and fact tables (per [3],
> > from
> > > the OFBiz related books),
> > > 2. more scheduled services that move data from various ofbiz tables
> > into
> > > ofbizolap tables,
> > > 3. more UI widgets for displaying data aggregations (tables, charts)
> > in
> > > the form of portal pages widgets. These portal page widgets can then
> > be
> > > integrated by our adopters dynamically anywhere in the components of
> > the
> > > applications folder, e.g through starting/main pages.
> > >
> > > [1]
> > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
> > > [2]
> > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20birt%20AND%20status%20not%20in%20(Closed)
> > > [3] https://www.amazon.com/gp/product/0471200247
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > > *Apache Directory <https://directory.apache.org>, PMC Member*
> > > Apache Incubator <https://incubator.apache.org>, committer
> > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> > privileges)
> > > since 2008*
> > > Apache Steve <https://steve.apache.org>, committer
> > >
> >
> >

Jacques Le Roux

Re: [DISCUSSION] bi/birt component integration

Administrator

Hi,

I tend to agree with Taher, Birt has a lot of dependencies

Jacques

Le 05/02/2020 à 14:52, Taher Alkhateeb a écrit :

> I think Jacopo got it just right!
>
> BI to me means a collection of complex queries and services that give
> insightful information (not necessarily even visual). Birt on the
> other hand is a specific tool that makes it possible to design and
> create reports interactively using a drag-and-drop behavior and it is
> one of multiple options available. Hence BI is a generic thing while
> BIRT is a specific tool. Furthermore, BIRT has lots and lots of
> dependencies which might not be appealing to everyone using it.
>
> So I think the two represent entirely different concepts. And the only
> relationship might / should be that birt depends on some things in BI
> but not the opposite.
>
>
> On Wed, Feb 5, 2020 at 2:20 PM Jacopo Cappellato
> <[hidden email]> wrote:
>> My main concern about this proposal is that the BI component is intended to
>> provide a "universal data model" (of dimensions, facts and star schemas)
>> for OLAP that is independent from the specific tools adopted to actually
>> perform the analysis (reporting tools, user interfaces etc...); its role
>> for OLAP is similar to the role of the OFBiz "universal data model" (of
>> entities and views) for OLTP that we all know and love.
>> On the other hand the Birt component is intended to integrate one specific
>> technology platform (Birt from Eclipse) to create data visualizations and
>> reports.
>> If we merge the two components, an adopter that would like to use a
>> different technology on our "universal data model" of dimensions/facts/star
>> schemas would have to deal with more unneeded code and dependencies (on
>> Birt).
>> I agree with Pierre that the BI component would need more attention to be
>> appealing to users; in its current form it is just a Proof Of Concepts
>> (POC) of some of the great ideas of "The Data Warehouse Toolkit"; but in my
>> opinion we should focus on improving and completing
>> the dimensions/facts/star schemas and the scripts that populate them; I am
>> fine with the idea of moving the definitions of dimensions/facts/star
>> schemas to the BI component (similarly to what was done with the entity
>> definitions in the "datamodel" component).
>> On the other hand, the Birt component can be improved by using and
>> leveraging more the data model provided by the BI component.
>>
>> Jacopo
>>
>>
>> On Sat, Feb 1, 2020 at 2:05 PM Michael Brohl <[hidden email]>
>> wrote:
>>
>>> Hi Pierre,
>>>
>>> +1 for the initiative as a whole.
>>>
>>> One remark though to the current approach: you are creating al lot of
>>> singe Jira issues for new tables, services to load data etc. I currently
>>> do not find the functional part, for example UI elements and
>>> functionality to view the informations loaded into the datastore.
>>>
>>> From my perspective, it does not make sense to add tables to the
>>> datamodel and services to the codebase without having a functional part
>>> depending on it.
>>>
>>> I think it would help to maybe pick a single aspect (e.g. sales channel
>>> dimension) of the overall approch and implement all of the needed parts
>>> (database mode, service, UI and example data) for it to show what the
>>> desired outcome would be. I'm sure it would help to get the work
>>> accepted and into the codebase.
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> Am 27.04.19 um 13:22 schrieb Pierre Smits:
>>>> Hi All,
>>>> Currently the various business intelligence (BI) functionalities are
>>>> scattered in various components (consider all the overviews regarding
>>>> inventory positions, orders/deliveries per customer/supplier) in the
>>>> applications folder.
>>>>
>>>> And on the other hand we have the BI component and the Birt component in
>>>> the plugins repo. Both of those components have minimal functionality
>>>> regarding the business intelligence aspect. But both components are
>>>> complimentary:
>>>>
>>>> 1. the bi (short for: Business Intelligence) component initialised
>>> the
>>>> OFBiz DWH and has secas and services for copying data from the ofbiz
>>>> database to the ofbizolap database, and
>>>> 2. the birt (short for Business Intelligence Report Tool) component
>>> is
>>>> intended to deliver on functionalities to display data overviews in
>>>> various forms (tables, charts, in PDFs, UI widgets, etc)...
>>>>
>>>> Unfortunately, both components lack of love from our community. But a bit
>>>> more love would significantly enhances the appeal of OFBiz for
>>> (potential)
>>>> adopters!
>>>>
>>>> As a result from a customer project, I recently have been working a bit
>>>> more on the business intelligence aspect (see recent tickets in [1] and
>>>> [2]).
>>>>
>>>> I believe it would be in the best interest of the project to integrate
>>> the
>>>> functionalities in the Birt component into the BI component. It will
>>> send a
>>>> clear message to both (potential) adopters and OFBiz developers (both our
>>>> contributors, and those not participating here but working on
>>>> implementations of adopters), being:
>>>>
>>>> *everything related with business intelligence happens in and comes from
>>>> the bi component*.
>>>>
>>>>
>>>> What do you think?
>>>>
>>>> When we have this, the community can start working on enhancing the
>>> single
>>>> component to increase its (and inherently OFBiz) appeal:
>>>>
>>>>
>>>> 1. more entitiy definitions for dimension and fact tables (per [3],
>>> from
>>>> the OFBiz related books),
>>>> 2. more scheduled services that move data from various ofbiz tables
>>> into
>>>> ofbizolap tables,
>>>> 3. more UI widgets for displaying data aggregations (tables, charts)
>>> in
>>>> the form of portal pages widgets. These portal page widgets can then
>>> be
>>>> integrated by our adopters dynamically anywhere in the components of
>>> the
>>>> applications folder, e.g through starting/main pages.
>>>>
>>>> [1]
>>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20bi%20AND%20status%20not%20in%20(Closed)
>>>> [2]
>>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20component%20%3D%20birt%20AND%20status%20not%20in%20(Closed)
>>>> [3] https://www.amazon.com/gp/product/0471200247
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>>>> *Apache Directory <https://directory.apache.org>, PMC Member*
>>>> Apache Incubator <https://incubator.apache.org>, committer
>>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
>>> privileges)
>>>> since 2008*
>>>> Apache Steve <https://steve.apache.org>, committer
>>>>
>>>