Re: [DISCUSSION] bi/birt component integration

[Jacques Le Roux]

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
<jacopo.cappell...@gmail.com> 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 <michael.br...@ecomify.de>
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