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 > > > >
