[VOTE] reintroduce the evicted specialpurpose components in R13.07

[Pierre Smits]

To Report or Not To Report, that is the question?

First:

I agree with the viewpoint that optionals in special purpose don't change
the experience of apps in the applications stack. A good example
modification to a longer existing issue regarding the field
parentCustRequestId. In such cases we should assess whether the
implementation should be brought to the appropriate component in the
applications stack.



*Reporting with framework elements in components*


   - *Pro*
      - This is quit easily done, with screens, forms, ftl files and
      services in groovy, java and javascript files.
      - Often integrated in the component that is used to register the
      transactions, e.g. accounting, order, product, etc
      - Works well with screen prints etc.
      - Utilises features from the framework stack (e.g. security, entity
      engine
      - ......
   - *Con*
   - For extra functionality in the report additional effort is necessary
      - For long reports extra burden on the transaction engine.
      - For BI purposes it might prove to complex.
      - Accesses data through features from the framework stack (e.g.
      entity engine)
      - Additional complexity in component
      - ....

*Reporting through report engine*

   - *Pro*
   - Accesses data directly from the rdbms
      - Opens opportunity to do scheduled reporting and have them delivered
      by email, ftp etc.
      - Optional
      - Adds explicitly to the OFBiz value proposition (especially if we
      change the name to reports). OFBiz does reporting!
      - Can be offloaded to a separate OFBiz instance
      - Functions can be added to generate reports via eca's
      - ....
   - *Con*
      - additional learning curve
      - other kind of contributors and committers required
      - ...


Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Mar 25, 2015 at 12:01 PM, Jacques Le Roux <
[hidden email]> wrote:

> Thanks Taher,
>
> I agree on Birt being useful in general, and in OFBiz certainly (Jacopo at
> least thinks it could be better implemented, that's another topic).
> My question was more is it useful for existing accounting reports? Jacopo
> seems to say that there were already FOP implementations what went
> overridden, why? Do we need Birt there?
>
> Jacques
>
>
> Le 25/03/2015 11:52, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> I already provided an answer earlier in this thread while you were typing
>> the question.
>>
>> Taher Alkhateeb
>>
>> On Wed, Mar 25, 2015 at 1:45 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>  Le 25/03/2015 11:34, Jacopo Cappellato a écrit :
>>>
>>>  On Mar 25, 2015, at 10:55 AM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>   Can we say that the Birt reports are better? Do they always work (I
>>>> got
>>>>
>>>>> some issues there)
>>>>>
>>>>>  No, I wouldn't say that (of course you are free to think otherwise,
>>>> it is
>>>> just the *we* part that I disagree with).
>>>>
>>>>  OK to sum up, why do we have Birt there then? (question not
>>> specifically
>>> intended to you Jacopo)
>>>
>>>   Also just tried http://demo-stable-ofbiz.
>>> apache.org/accounting/control/
>>>
>>>> FinancialSummaryReportOptions?organizationPartyId=Company where Birt is
>>>>> not and all reports fail, normal?
>>>>>
>>>>>  I am not sure I understand... I got the same errors with or without
>>>> Birt:
>>>> the request maps are not defined; I don't see how this bug fits into
>>>> this
>>>> conversation.
>>>>
>>>>  Same with trunk demo, OK to be revisited :/
>>>
>>>   But for example, the balance sheet report:
>>>
>>>> https://localhost:8443/accounting/control/BalanceSheet?
>>>> organizationPartyId=Company
>>>> is not a Birt report and works well; however the if you click on the
>>>> "Export as pdf" button you get an error when Birt is active while it
>>>> works
>>>> when Birt is inactive.
>>>>
>>>>  So again, why do we have Birt there then? (question not specifically
>>> intended to you Jacopo)
>>>
>>> Jacques
>>>
>>>
>>>  Jacopo
>>>>
>>>>   Jacques
>>>>
>>>>> Le 24/03/2015 16:36, Jacopo Cappellato a écrit :
>>>>>
>>>>>  The accounting component has financial reports implemented as screen
>>>>>> widgets (html/pdf/csv) that the Birt component overrides with
>>>>>> different
>>>>>> ones implemented with Birt.
>>>>>> This is actually one example about a specialpurpose component that is
>>>>>> overriding/hiding functionality that is already provided by the
>>>>>> applications with a different one: you can't see them when Birt is
>>>>>> enabled.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Mar 24, 2015, at 4:23 PM, Pierre Smits <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>   Don't we also have dependencies on birt? Regarding reporting in
>>>>>>
>>>>>>> accounting
>>>>>>> and order?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>>
>>>>>>
>>>>

[Jacques Le Roux]

Added, I agree, seems logical to me also

Le 25/03/2015 12:41, Jacopo Cappellato a écrit :

> Thank you.
> However one of my sentences had a missing and important word (highlighted below):
>
> "In my opinion, by default, we should not have *enabled* special components hiding/overriding artifacts from other components, this is the main issue here."
>
> Jacopo
>
> On Mar 25, 2015, at 12:38 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Le 25/03/2015 12:05, Jacopo Cappellato a écrit :
>>> On Mar 25, 2015, at 11:49 AM, Pierre Smits <[hidden email]> wrote:
>>>
>>>> Maybe you could file a bug issue regarding that?
>>> I think I did in the past and I have fixed them by disabling the webapp definitions from the Birt component that were overriding the accounting reports; but after some time they have been re-enabled and so the issue is still there.
>>> In my opinion, by default, we should not have special components hiding/overriding artifacts from other components, this is the main issue here.
>>>
>>> Jacopo
>>>
>> I added your comment at https://issues.apache.org/jira/browse/OFBIZ-6212
>>
>> Jacques
>
>

[taher]

Hi Pierre,

A quick note on the pros mentioned by you: integrating BIRT to the RDBMS is
optional. You can do that or call the APIs of the entity engine and in fact
this is how reports are currently implemented (it's called scripted data
set source in BIRT). You can also fully integrate with the framework
(uiLabels, java source code, services API, you name it).

Taher Alkhateeb

On Wed, Mar 25, 2015 at 2:41 PM, Pierre Smits <[hidden email]>
wrote:

> To Report or Not To Report, that is the question?
>
> First:
>
> I agree with the viewpoint that optionals in special purpose don't change
> the experience of apps in the applications stack. A good example
> modification to a longer existing issue regarding the field
> parentCustRequestId. In such cases we should assess whether the
> implementation should be brought to the appropriate component in the
> applications stack.
>
>
>
> *Reporting with framework elements in components*
>
>
>    - *Pro*
>       - This is quit easily done, with screens, forms, ftl files and
>       services in groovy, java and javascript files.
>       - Often integrated in the component that is used to register the
>       transactions, e.g. accounting, order, product, etc
>       - Works well with screen prints etc.
>       - Utilises features from the framework stack (e.g. security, entity
>       engine
>       - ......
>    - *Con*
>    - For extra functionality in the report additional effort is necessary
>       - For long reports extra burden on the transaction engine.
>       - For BI purposes it might prove to complex.
>       - Accesses data through features from the framework stack (e.g.
>       entity engine)
>       - Additional complexity in component
>       - ....
>
> *Reporting through report engine*
>
>    - *Pro*
>    - Accesses data directly from the rdbms
>       - Opens opportunity to do scheduled reporting and have them delivered
>       by email, ftp etc.
>       - Optional
>       - Adds explicitly to the OFBiz value proposition (especially if we
>       change the name to reports). OFBiz does reporting!
>       - Can be offloaded to a separate OFBiz instance
>       - Functions can be added to generate reports via eca's
>       - ....
>    - *Con*
>       - additional learning curve
>       - other kind of contributors and committers required
>       - ...
>
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Mar 25, 2015 at 12:01 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Thanks Taher,
> >
> > I agree on Birt being useful in general, and in OFBiz certainly (Jacopo
> at
> > least thinks it could be better implemented, that's another topic).
> > My question was more is it useful for existing accounting reports? Jacopo
> > seems to say that there were already FOP implementations what went
> > overridden, why? Do we need Birt there?
> >
> > Jacques
> >
> >
> > Le 25/03/2015 11:52, Taher Alkhateeb a écrit :
> >
> >> Hi Jacques,
> >>
> >> I already provided an answer earlier in this thread while you were
> typing
> >> the question.
> >>
> >> Taher Alkhateeb
> >>
> >> On Wed, Mar 25, 2015 at 1:45 PM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >>  Le 25/03/2015 11:34, Jacopo Cappellato a écrit :
> >>>
> >>>  On Mar 25, 2015, at 10:55 AM, Jacques Le Roux <
> >>>> [hidden email]> wrote:
> >>>>
> >>>>   Can we say that the Birt reports are better? Do they always work (I
> >>>> got
> >>>>
> >>>>> some issues there)
> >>>>>
> >>>>>  No, I wouldn't say that (of course you are free to think otherwise,
> >>>> it is
> >>>> just the *we* part that I disagree with).
> >>>>
> >>>>  OK to sum up, why do we have Birt there then? (question not
> >>> specifically
> >>> intended to you Jacopo)
> >>>
> >>>   Also just tried http://demo-stable-ofbiz.
> >>> apache.org/accounting/control/
> >>>
> >>>> FinancialSummaryReportOptions?organizationPartyId=Company where Birt
> is
> >>>>> not and all reports fail, normal?
> >>>>>
> >>>>>  I am not sure I understand... I got the same errors with or without
> >>>> Birt:
> >>>> the request maps are not defined; I don't see how this bug fits into
> >>>> this
> >>>> conversation.
> >>>>
> >>>>  Same with trunk demo, OK to be revisited :/
> >>>
> >>>   But for example, the balance sheet report:
> >>>
> >>>> https://localhost:8443/accounting/control/BalanceSheet?
> >>>> organizationPartyId=Company
> >>>> is not a Birt report and works well; however the if you click on the
> >>>> "Export as pdf" button you get an error when Birt is active while it
> >>>> works
> >>>> when Birt is inactive.
> >>>>
> >>>>  So again, why do we have Birt there then? (question not specifically
> >>> intended to you Jacopo)
> >>>
> >>> Jacques
> >>>
> >>>
> >>>  Jacopo
> >>>>
> >>>>   Jacques
> >>>>
> >>>>> Le 24/03/2015 16:36, Jacopo Cappellato a écrit :
> >>>>>
> >>>>>  The accounting component has financial reports implemented as screen
> >>>>>> widgets (html/pdf/csv) that the Birt component overrides with
> >>>>>> different
> >>>>>> ones implemented with Birt.
> >>>>>> This is actually one example about a specialpurpose component that
> is
> >>>>>> overriding/hiding functionality that is already provided by the
> >>>>>> applications with a different one: you can't see them when Birt is
> >>>>>> enabled.
> >>>>>>
> >>>>>> Jacopo
> >>>>>>
> >>>>>> On Mar 24, 2015, at 4:23 PM, Pierre Smits <[hidden email]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>   Don't we also have dependencies on birt? Regarding reporting in
> >>>>>>
> >>>>>>> accounting
> >>>>>>> and order?
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Pierre Smits
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
>

[Pierre Smits]

Hence a +1, especially if you want utilise the olap fucntions in the bi
component in a separate rdbms (see issue OFBIZ-6087
<https://issues.apache.org/jira/browse/OFBIZ-6087>)

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Mar 25, 2015 at 1:00 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Pierre,
>
> A quick note on the pros mentioned by you: integrating BIRT to the RDBMS is
> optional. You can do that or call the APIs of the entity engine and in fact
> this is how reports are currently implemented (it's called scripted data
> set source in BIRT). You can also fully integrate with the framework
> (uiLabels, java source code, services API, you name it).
>
> Taher Alkhateeb
>
> On Wed, Mar 25, 2015 at 2:41 PM, Pierre Smits <[hidden email]>
> wrote:
>

[Ron Wheeler]

+1
We use JasperReports with our software
It has many of the same characteristics identified below.

Ron

On 25/03/2015 6:44 AM, Taher Alkhateeb wrote:

> Hi Jacques,
>
> With respect to your question below on BIRT and regardless of whether
> reports are failing or not IMHO we should discuss the principles.
>
> So the question is very simple. Is it better to use Apache FOP with the
> screen widgets to create reports or is it better to utilize a reporting and
> business intelligence engine?
>
> To me, this is a no brainer. A full blown engine is definitely better (even
> if not necessarily BIRT) for the following reasons:
>
> 1- Designer WYSIWYG tools available for much greater productivity and user
> friendliness. You can even expose such tools directly to your clients.
>
> 2- Ability to design data set, cubes, parameters, charts, graphs, master
> pages with headers and footers, and a lot more
>
> 3- Ability to do dynamic scripting of the data on an event model which
> allows for maximum flexibility in design
>
> 4- Ability to export output to many formats (PDF, HTML, word, excel, CSV,
> ...)
>
> 5- Ability to specify unified report libraries containing shared themes,
> master pages, javascript source files, CSS, images, etc ...
>
> 6- Ability to deploy the reporting server as a standalone solution
>
> 7- Ability to integrate with the entity engine or to connect directly to
> the database.
> 8- Building reports on a modular design structure
>
> The above is just a quick brain dump, I am sure there are many other
> benefits.
>
> My 2 cents.
>
> Taher Alkhateeb
>
> On Wed, Mar 25, 2015 at 1:34 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> On Mar 25, 2015, at 10:55 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> Can we say that the Birt reports are better? Do they always work (I got
>> some issues there)
>>
>> No, I wouldn't say that (of course you are free to think otherwise, it is
>> just the *we* part that I disagree with).
>>
>>> Also just tried
>> http://demo-stable-ofbiz.apache.org/accounting/control/FinancialSummaryReportOptions?organizationPartyId=Company
>> where Birt is not and all reports fail, normal?
>>
>> I am not sure I understand... I got the same errors with or without Birt:
>> the request maps are not defined; I don't see how this bug fits into this
>> conversation.
>> But for example, the balance sheet report:
>>
>> https://localhost:8443/accounting/control/BalanceSheet?organizationPartyId=Company
>> is not a Birt report and works well; however the if you click on the
>> "Export as pdf" button you get an error when Birt is active while it works
>> when Birt is inactive.
>>
>> Jacopo
>>
>>> Jacques
>>>
>>> Le 24/03/2015 16:36, Jacopo Cappellato a écrit :
>>>> The accounting component has financial reports implemented as screen
>> widgets (html/pdf/csv) that the Birt component overrides with different
>> ones implemented with Birt.
>>>> This is actually one example about a specialpurpose component that is
>> overriding/hiding functionality that is already provided by the
>> applications with a different one: you can't see them when Birt is enabled.
>>>> Jacopo
>>>>
>>>> On Mar 24, 2015, at 4:23 PM, Pierre Smits <[hidden email]>
>> wrote:
>>>>> Don't we also have dependencies on birt? Regarding reporting in
>> accounting
>>>>> and order?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

+1
+0

Jacques

Le 22/03/2015 18:27, Jacques Le Roux a écrit :

> I tried to begin a discussion on this subject few times, notably at http://markmail.org/message/lgqhdtotwhfebqmw
>
> But nothing happened, so I think the best is to start a vote. I see 2 questions hence 2 votes, I don't think it's necessary to start 2 threads
> because these 2 questions are closely related.
> So please vote for both questions, the ballot will last a week to allow everybody to have a chance to cast a vote.
>
> You can refer to https://www.apache.org/foundation/voting.html if you need information on how to vote. I suggest we only use
>
> +1 = I'm for
> +0 = not sure
> -1 = I'm against
>
> 1) Do you agree to reintroduce the evicted specialpurpose components in R13.07?
> Notes:
> The question is not about which components should and should not, it's all or nothing. Choosing component to put to Attic should be done in trunk as
> we did with appserver recently.
> I proposed 2 ways for doing that in the thread linked above, depending on the result of this vote this will be or not a new question (or might be
> discussed again if the vote is positive)
>
> The 2nd is of more importance since it concerns future releases
> 2) Do you agree to reintroduce the evicted specialpurpose components in future R13.07 releases?
> Note: Jacopo already started a thread about it at http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask for a vote to clearly and
> definitively close this chapter with the help of the community. Personally I will be happy with the solutions the community will come with.
>
> The current situation (all but ecommerce component evicted from specialpurpose in R13.07 branch and releases) comes from a lazy consensus (no formal
> vote) but weirdly now both questions concern a code modification so can be vetoed. Note that the second question is not about releasing or not. So
> it's not a vote on releasing a package, it's rather a preamble to future R13.07 package releases.
>
> Thanks for your attention and please vote!
>
> Jacques
>

[Jacques Le Roux]

Here is the result of this vote for both questions:

1)
+1 =2
0   =1
-1 =3

2)
+1 =1
0  = 1
-1 = 4

None of the propositions passed. We though discussed about voting on this subject for the next releases of the R14.12 branch where the specialpurpose
components are present.

Thanks for your vote!

Jacques


Le 22/03/2015 18:27, Jacques Le Roux a écrit :

> I tried to begin a discussion on this subject few times, notably at http://markmail.org/message/lgqhdtotwhfebqmw
>
> But nothing happened, so I think the best is to start a vote. I see 2 questions hence 2 votes, I don't think it's necessary to start 2 threads
> because these 2 questions are closely related.
> So please vote for both questions, the ballot will last a week to allow everybody to have a chance to cast a vote.
>
> You can refer to https://www.apache.org/foundation/voting.html if you need information on how to vote. I suggest we only use
>
> +1 = I'm for
> +0 = not sure
> -1 = I'm against
>
> 1) Do you agree to reintroduce the evicted specialpurpose components in R13.07?
> Notes:
> The question is not about which components should and should not, it's all or nothing. Choosing component to put to Attic should be done in trunk as
> we did with appserver recently.
> I proposed 2 ways for doing that in the thread linked above, depending on the result of this vote this will be or not a new question (or might be
> discussed again if the vote is positive)
>
> The 2nd is of more importance since it concerns future releases
> 2) Do you agree to reintroduce the evicted specialpurpose components in future R13.07 releases?
> Note: Jacopo already started a thread about it at http://markmail.org/message/vwyuaokuzcj44z6w that's why I decided to ask for a vote to clearly and
> definitively close this chapter with the help of the community. Personally I will be happy with the solutions the community will come with.
>
> The current situation (all but ecommerce component evicted from specialpurpose in R13.07 branch and releases) comes from a lazy consensus (no formal
> vote) but weirdly now both questions concern a code modification so can be vetoed. Note that the second question is not about releasing or not. So
> it's not a vote on releasing a package, it's rather a preamble to future R13.07 package releases.
>
> Thanks for your attention and please vote!
>
> Jacques
>