Hi Taher, Thank you for your review and questions.
Please see in line for specific answers. Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer Apache Steve <https://steve.apache.org>, committer On Mon, Mar 16, 2020 at 4:39 PM Taher Alkhateeb <slidingfilame...@gmail.com> wrote: > Hello and thank you for your work. A few review notes: > > - It would be great if you can briefly explain the new dimensions and > what you're triangulating on > - CountryDimension - applicable when doing aggregations of amounts etc of orders/invoices/etc. per country and/or when doing comparisons between countries - CurrencyDimension - applicable when doing aggregations of amounts etc of orders/invoices/etc. per currency and/or when doing comparisons between currencies. Helpful for optimising cost of banking et.c - CustomerDimension - key to be used in conjunction with SalesOrderItemFact and SalesInvoiceItemFact, in order to do aggregation in appropriate schemas of orders vs invoices per customer, revenues per customer per period and period to period comparison, etc. Currently various fact tables are missing this integration with this dimension. Based on parties with roleTypeId = "CUSTOMER"; - DateDimension - based on ISO definitions and derived from various date(time) fields in transactions - used in various schemas in order to be able to do various aggregations of amounts etc per period (consider year, quarter, month, week, day, etc.), and/or comparisons of grouped amounts of invoices/orders/etc between periods - FacilityDimension - based on Facility entity - to be used in conjunction with not only InventoryItemFact and associated schema, but also applicable regarding shipment(Item)Fact and appropriate schema in order to improve warehousing efficiency and shipment routing. - OrganisationDimension - based on the accounting organisations (PartyAcctgPreference) as the counterpart of all 3rd parties in orders, invoices, etc. - key to be used in conjunction with all Fact tables, in order to do aggregations of orders (amounts, etc) invoices (also amounts etc), etc. - TimeDimension - based on ISO definitions and derived from various date(time) fields in transactions. - e.g. used in various schemas in order to be able to do various aggregations of amounts etc per time slot (day segment e.g. morning, evening, hour, minute) > - Can you elaborate on the purpose for having time dimensions values > for every minute? What is the data being aggregated here? > This is based on the Data WareHouse Toolkit book. and is intended to enable filtering (or roll-up) of periods based on summarised day part group, like 15 minutes intervals > - There is some stramge logic in DimensionServices.groovy where > essentially you're clearing the input map (effectively passing an > empty map) to a bunch of service calls. Why are you using the same map > which you keep clearing from one call to the next? Are those services > not supposed to take input parameters? If so, why not pass an empty > map instead of this logic? > That you for bringing this forward. I will take a look at this, and correct where needed. > - There are some files with windows EOL characters. Need to run > something like dos2unix on those > Thanks. Will correct this. > - There are also tab characters around the code base > Thanks. Will correct this. > > May I also suggest breaking this work into smaller chunks to start > incorporating into the code base to make it easier to review and > integrate the work. Perhaps you can isolate the work for each new > dimension in a branch / patch / etc > Sorry, but at the moment I am not inclined to revert back to individual patch files or development branches for each of the underlying sub-tasks under OFBIZ-11414. While some may regard the contribution too overwhelming for review (and/or testing) at one moment in time, breaking them up into smaller chunks would lead to criticism that chunks are too small to review and lacking coherence with other chunks. IMO, the history in the feature branch in the repo provides enough granulated insights to enable evaluation from commit to commit, while at the same time enable community members to test the whole without them having to bring all appropriate chunks (patch files/development branches per sub-task) together in a correct sequence. I have done that (providing patch files) in the beginning to each of the underlying sub-tasks, and the overhead to maintain the myriad (keeping everything synced) is just too time consuming. As well as increasing the risk of merge conflicts dramatically. I experienced that quite a number of times and have seen patches go stale. > On Mon, Mar 16, 2020 at 6:09 PM Pierre Smits <pierresm...@apache.org> > wrote: > > > > Following up on recent migrations from minilang to groovy regarding the > > functions in the BI component I have made various enhancements to the > > component, enabling the project to move from a Proof of Concept state to > > something that is starting to provide our (potential) adopters some > > additional arguments to use (or select) our product. > > > > BI (or Business Intelligence) is a key factor to measure the success of a > > company (and its underlying departments), whether it is regarding sales, > > purchases, inventory ageing, or employer utilisation (e.g. in > > project-oriented service orgs). BI often works against a Data Warehouse, > > which is fed from the transactions RDBMS using (more or less) > sophisticated > > ETL solutions. Often these ETL tools are quite expensive to operate, and > > require - when talking about development - quite the skill set. > > Unfortunately, Small and Medium Enterprises often lack the budget to > deploy > > such tools and services and make due with exports from the transaction > > RDBMS and the use of MS Excel to do their Business Intelligence analysis. > > > > Given the unique feature set of OFBiz catering to the needs of small and > > medium enterprises, an improved BI component can deliver on an easy (and > > fairly cheap) means to have a DataWarehouse populated, and - through the > > population of dimension and fact tables - get data elements combined into > > star schemas for in-component or external (through external tools as > Excel) > > analysis. > > > > In order to bring the BI component up to a level of usability in a > company, > > I have implemented following changes (in a feature branch in my repo) > > > > - added and updated dimension tables > > - CustomerDimension, OrganisationDimension (internal > organisations), > > and SupplierDimension > > - supporting: DateDimension, TimeDimension, CountryDimension, > > CurrencyDimension > > - updated fact tables to work with the added and improved dimension > > tables > > - SalesInvoiceItemFact > > - InventoryItemFact > > - updated star schemas to bring data elements from dimension and fact > > tables together > > - SalesInvoiceItemStarSchema > > - InventoryItemStarSchema > > - made the Report Builder functionality (screens and such) mode user > > friendly, by applying ajax functionality, to have selection of the > star > > schema, the field selection and the resulting overview in one page > > > > While there are still a lot of areas (BI-wise) that can be improved, such > > as: > > > > - SalesOrderItemFact and SalesOrderItemStarSchema - to enhance the > > analysis regarding sales, > > - Purchase (Spend) analysis functionality, > > - Utilisation analysis function (assets, employee), > > > > enhancements currently available improve the BI component significantly. > > > > Rather than working alone and see contributions go stale, I would like to > > collaborate more via a feature branch in the official plugins repository. > > As you can see in JIRA, there already quite a number of improvement > tickets > > (seeu [1]), and I have already many (up to the point of ready for > > incorporation into the plugins code base) in progress. The improvements > > are currently available in my public fork on Github (see [2]). I invite > you > > to fork or clone and test-drive the enhancements. > > > > And if you have any suggestions, questions, and/or remarks, feel free to > > post them here (or directly to me), or as a comment to the master ticket > > (for general aspects) or to a particular sub-task. > > > > 1. https://issues.apache.org/jira/browse/OFBIZ-11414 > > 2. > > > https://github.com/PierreSmits/plugins/tree/OFBIZ-11414_BI-Improvements > > > > > > Looking forward. > > > > Met vriendelijke groet, > > > > Pierre Smits > > *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> > since > > 2008 (without privileges) > > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > > *Apache Directory <https://directory.apache.org>, PMC Member* > > Apache Incubator <https://incubator.apache.org>, committer > > Apache Steve <https://steve.apache.org>, committer >
