Re: svn commit: r729396 [1/2] - in /ofbiz/trunk: applications/accounting/config/ applications/accounting/entitydef/ applications/accounting/src/org/ofbiz/accounting/invoice/ applications/accounting/src/org/ofbiz/accounting/payment/ applications/accou

[David E Jones-3]

On Jan 26, 2009, at 3:09 AM, Jacopo Cappellato wrote:

>
> On Jan 26, 2009, at 7:14 AM, David E Jones wrote:
>
>>
>> I think of the BI stuff as being very like where we are going with  
>> themes and portal and such. The framework has infrastructure and  
>> the applications and such plugin to that infrastructure (through  
>> whatever means make the most sense).
>>
>> For BI that would mean all of the tools (including UI) go in the  
>> framework, as long as they do not depend on anything in  
>> applications, and that data and services and more custom UI and so  
>> on go in the applications or specialpurpose components.
>>
>> That will probably require splitting some of the POC stuff that  
>> Jacopo did into different components...
>>
>
> David, I totally agree, this is the plan. By the way, I already did  
> the split, apart for the last service named quickInitDataWarehouse  
> that I am not sure where to move... but it can be removed as well,  
> for now it is just easier to test the BI features with it.

That service is a good example of one that is a handy feature, and  
that would be nice to always have, but written as-is would have  
undesirable dependencies. The first solution that comes to mind is to  
parameterize it in a way that higher level components can add to,  
preferably without anything changed in any framework component...  
which means the database might be most natural place for the info  
(like some kind of list of services to run to init data warehouse data).

-David

[Jacopo Cappellato-4]

On Jan 26, 2009, at 8:03 PM, David E Jones wrote:

>>
>> David, I totally agree, this is the plan. By the way, I already did  
>> the split, apart for the last service named quickInitDataWarehouse  
>> that I am not sure where to move... but it can be removed as well,  
>> for now it is just easier to test the BI features with it.
>
> That service is a good example of one that is a handy feature, and  
> that would be nice to always have, but written as-is would have  
> undesirable dependencies. The first solution that comes to mind is  
> to parameterize it in a way that higher level components can add to,  
> preferably without anything changed in any framework component...  
> which means the database might be most natural place for the info  
> (like some kind of list of services to run to init data warehouse  
> data).
>
> -David
>

This is an interesting idea... each component could "register" the  
init services required by its bi reports using the Enumeration entity.
And then the BI component will just read the records and run the  
services associated to them. Or we could create JobSandox entries for  
the services, and just let the BI component to run them (reading the  
jobId from the Enumeration).

Does it make sense?

Jacopo

[David E Jones-3]

On Jan 29, 2009, at 3:24 AM, Jacopo Cappellato wrote:

>
> On Jan 26, 2009, at 8:03 PM, David E Jones wrote:
>>>
>>> David, I totally agree, this is the plan. By the way, I already  
>>> did the split, apart for the last service named  
>>> quickInitDataWarehouse that I am not sure where to move... but it  
>>> can be removed as well, for now it is just easier to test the BI  
>>> features with it.
>>
>> That service is a good example of one that is a handy feature, and  
>> that would be nice to always have, but written as-is would have  
>> undesirable dependencies. The first solution that comes to mind is  
>> to parameterize it in a way that higher level components can add  
>> to, preferably without anything changed in any framework  
>> component... which means the database might be most natural place  
>> for the info (like some kind of list of services to run to init  
>> data warehouse data).
>>
>> -David
>>
>
> This is an interesting idea... each component could "register" the  
> init services required by its bi reports using the Enumeration entity.
> And then the BI component will just read the records and run the  
> services associated to them. Or we could create JobSandox entries  
> for the services, and just let the BI component to run them (reading  
> the jobId from the Enumeration).
>
> Does it make sense?

Yes, that makes sense. Don't be afraid of a new entity though. They  
are easy to define and then we don't have to use something that  
doesn't fit well with this...

-David