Dev - Proposed changes to the way inventoryItems are created

[Jacopo Cappellato]

Hi all,

based on a conversation between Si and I, there is a list of proposed
changes to the way inventory items are created that I'm going to develop
(and commit later today).

The idea is that some of the InventoryItems fields should never be
empty, namely:

facilityId
ownerPartyId
unitCost
currencyUomId

I'm going to add a new service and then an eca rule triggered to the
creation of InventoryItem records that checks if these fields are empty
and if possible fills them with default values, if not return an error
message.

Some details:

* InventoryItem.facilityId: if not set the service will return an error
and the inventory item will not be created; also, I'd like to make
facilityId a mandatory field of the "createInventoryItem" service

* InventoryItem.ownerPartyId: if not set, Facility.ownerPartyId will be
used; if null, the service will return an error and the inventory item
will not be created

* InventoryItem.currencyUomId: if not set, the PartyAcctgPreference
entry for the ownerPartyId is retrieved and
PartyAcctgPreference.currencyUomId will be used; if null, the service
will return an error and the inventory item will not be created

* InventoryItem.unitCost: if not set, the product's standard cost will
be retrieved (using the "getProductCost" service) and used as unitCost;
if no std cost is available the service will return an error and the
inventory item will not be created; also "unitCost" is now a mandatory
field for the "createInventoryItem" service, I'll make it optional.

What do you think of all this stuff?

Thanks,

Jacopo
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Ok,

I've committed the new service and eca rule in rev 6967, however the eca
rule is disabled to avoid problems creating inventory items (you'll need
to play with some Facility/PartyAccPreferences settings to make it work
fine).

There is one issue I have not solved yet: if the service (triggered by
an eca rule during the inventory item creation) returns an error
message, I still cannot clearly display it on screen and a big dump log
is generated... any hints?

Thanks,

Jacopo


Jacopo Cappellato wrote:

> Hi all,
>
> based on a conversation between Si and I, there is a list of proposed
> changes to the way inventory items are created that I'm going to develop
> (and commit later today).
>
> The idea is that some of the InventoryItems fields should never be
> empty, namely:
>
> facilityId
> ownerPartyId
> unitCost
> currencyUomId
>
> I'm going to add a new service and then an eca rule triggered to the
> creation of InventoryItem records that checks if these fields are empty
> and if possible fills them with default values, if not return an error
> message.
>
> Some details:
>
> * InventoryItem.facilityId: if not set the service will return an error
> and the inventory item will not be created; also, I'd like to make
> facilityId a mandatory field of the "createInventoryItem" service
>
> * InventoryItem.ownerPartyId: if not set, Facility.ownerPartyId will be
> used; if null, the service will return an error and the inventory item
> will not be created
>
> * InventoryItem.currencyUomId: if not set, the PartyAcctgPreference
> entry for the ownerPartyId is retrieved and
> PartyAcctgPreference.currencyUomId will be used; if null, the service
> will return an error and the inventory item will not be created
>
> * InventoryItem.unitCost: if not set, the product's standard cost will
> be retrieved (using the "getProductCost" service) and used as unitCost;
> if no std cost is available the service will return an error and the
> inventory item will not be created; also "unitCost" is now a mandatory
> field for the "createInventoryItem" service, I'll make it optional.
>
> What do you think of all this stuff?
>
> Thanks,
>
> Jacopo
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

What does the message on the screen or dump log look like?

Si

Jacopo Cappellato wrote:

>Ok,
>
>I've committed the new service and eca rule in rev 6967, however the eca
>rule is disabled to avoid problems creating inventory items (you'll need
>to play with some Facility/PartyAccPreferences settings to make it work
>fine).
>
>There is one issue I have not solved yet: if the service (triggered by
>an eca rule during the inventory item creation) returns an error
>message, I still cannot clearly display it on screen and a big dump log
>is generated... any hints?
>
>Thanks,
>
>Jacopo
>
>
>Jacopo Cappellato wrote:
>  
>
>>Hi all,
>>
>>based on a conversation between Si and I, there is a list of proposed
>>changes to the way inventory items are created that I'm going to develop
>>(and commit later today).
>>
>>The idea is that some of the InventoryItems fields should never be
>>empty, namely:
>>
>>facilityId
>>ownerPartyId
>>unitCost
>>currencyUomId
>>
>>I'm going to add a new service and then an eca rule triggered to the
>>creation of InventoryItem records that checks if these fields are empty
>>and if possible fills them with default values, if not return an error
>>message.
>>
>>Some details:
>>
>>* InventoryItem.facilityId: if not set the service will return an error
>>and the inventory item will not be created; also, I'd like to make
>>facilityId a mandatory field of the "createInventoryItem" service
>>
>>* InventoryItem.ownerPartyId: if not set, Facility.ownerPartyId will be
>>used; if null, the service will return an error and the inventory item
>>will not be created
>>
>>* InventoryItem.currencyUomId: if not set, the PartyAcctgPreference
>>entry for the ownerPartyId is retrieved and
>>PartyAcctgPreference.currencyUomId will be used; if null, the service
>>will return an error and the inventory item will not be created
>>
>>* InventoryItem.unitCost: if not set, the product's standard cost will
>>be retrieved (using the "getProductCost" service) and used as unitCost;
>>if no std cost is available the service will return an error and the
>>inventory item will not be created; also "unitCost" is now a mandatory
>>field for the "createInventoryItem" service, I'll make it optional.
>>
>>What do you think of all this stuff?
>>
>>Thanks,
>>
>>Jacopo
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>    
>>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

This sort of validation should probably be in the service itself  
rather than attached as an ECA. That would be easier to trace/find,  
and kind of makes sense as validation is generally more core to the  
purpose of a service. This would also make it easier to handle the  
error message...

-David


On Mar 10, 2006, at 10:37 AM, Jacopo Cappellato wrote:

> Ok,
>
> I've committed the new service and eca rule in rev 6967, however  
> the eca
> rule is disabled to avoid problems creating inventory items (you'll  
> need
> to play with some Facility/PartyAccPreferences settings to make it  
> work
> fine).
>
> There is one issue I have not solved yet: if the service (triggered by
> an eca rule during the inventory item creation) returns an error
> message, I still cannot clearly display it on screen and a big dump  
> log
> is generated... any hints?
>
> Thanks,
>
> Jacopo
>
>
> Jacopo Cappellato wrote:
>> Hi all,
>>
>> based on a conversation between Si and I, there is a list of proposed
>> changes to the way inventory items are created that I'm going to  
>> develop
>> (and commit later today).
>>
>> The idea is that some of the InventoryItems fields should never be
>> empty, namely:
>>
>> facilityId
>> ownerPartyId
>> unitCost
>> currencyUomId
>>
>> I'm going to add a new service and then an eca rule triggered to the
>> creation of InventoryItem records that checks if these fields are  
>> empty
>> and if possible fills them with default values, if not return an  
>> error
>> message.
>>
>> Some details:
>>
>> * InventoryItem.facilityId: if not set the service will return an  
>> error
>> and the inventory item will not be created; also, I'd like to make
>> facilityId a mandatory field of the "createInventoryItem" service
>>
>> * InventoryItem.ownerPartyId: if not set, Facility.ownerPartyId  
>> will be
>> used; if null, the service will return an error and the inventory  
>> item
>> will not be created
>>
>> * InventoryItem.currencyUomId: if not set, the PartyAcctgPreference
>> entry for the ownerPartyId is retrieved and
>> PartyAcctgPreference.currencyUomId will be used; if null, the service
>> will return an error and the inventory item will not be created
>>
>> * InventoryItem.unitCost: if not set, the product's standard cost  
>> will
>> be retrieved (using the "getProductCost" service) and used as  
>> unitCost;
>> if no std cost is available the service will return an error and the
>> inventory item will not be created; also "unitCost" is now a  
>> mandatory
>> field for the "createInventoryItem" service, I'll make it optional.
>>
>> What do you think of all this stuff?
>>
>> Thanks,
>>
>> Jacopo
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Si,

the error message on screen is (for example in the EditInventoryItem page):

The Following Errors Occurred:
* Error calling event: org.ofbiz.webapp.event.EventHandlerException:
Service invocation error (Commit transaction failed)

In the log you can find the real cause of the problem, i.e. one of the
error messages generated by my new service (this is good) but inside a
big error log (see attached file).

Jacopo

Si Chen wrote:
> What does the message on the screen or dump log look like?
>
> Si
>
> Jacopo Cappellato wrote:
>


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Jacopo,

I think the problem is that EECA probably relies on some kind of
rollback, and after many layers of code somewhere it's not passing back
the message.  You could go back and try to change some of the event
handler or entity engine code and see if David could commit it for us?  
Or maybe David's idea to put your code into the service
createInventoryItem or just call it from createInventoryItem is a good
one, instead of relying on an EECA.

Si

Jacopo Cappellato wrote:

> Si,
>
> the error message on screen is (for example in the EditInventoryItem
> page):
>
> The Following Errors Occurred:
> * Error calling event: org.ofbiz.webapp.event.EventHandlerException:
> Service invocation error (Commit transaction failed)
>
> In the log you can find the real cause of the problem, i.e. one of the
> error messages generated by my new service (this is good) but inside a
> big error log (see attached file).
>
> Jacopo
>
> Si Chen wrote:
>
>> What does the message on the screen or dump log look like?
>>
>> Si
>>
>> Jacopo Cappellato wrote:
>>
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi David,

I see what you mean.

I have choosen to use an entity eca for two reasons:

1) I was not sure if the "createInventoryItem" is the only one method
used to create inventory items (my fear is that somewhere in the system
inventory items could be created bypassing the service engine)

2) to make easier to switch off this complex validations

However, if you think it's better, I can also move all the code inside
the "createInventoryItem" service...

What do you think?

Thanks,

Jacopo


David E. Jones wrote:

>
> This sort of validation should probably be in the service itself rather
> than attached as an ECA. That would be easier to trace/find, and kind of
> makes sense as validation is generally more core to the purpose of a
> service. This would also make it easier to handle the error message...
>
> -David
>
>
> On Mar 10, 2006, at 10:37 AM, Jacopo Cappellato wrote:
>
>> Ok,
>>
>> I've committed the new service and eca rule in rev 6967, however the eca
>> rule is disabled to avoid problems creating inventory items (you'll need
>> to play with some Facility/PartyAccPreferences settings to make it work
>> fine).
>>
>> There is one issue I have not solved yet: if the service (triggered by
>> an eca rule during the inventory item creation) returns an error
>> message, I still cannot clearly display it on screen and a big dump log
>> is generated... any hints?
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>> Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> based on a conversation between Si and I, there is a list of proposed
>>> changes to the way inventory items are created that I'm going to develop
>>> (and commit later today).
>>>
>>> The idea is that some of the InventoryItems fields should never be
>>> empty, namely:
>>>
>>> facilityId
>>> ownerPartyId
>>> unitCost
>>> currencyUomId
>>>
>>> I'm going to add a new service and then an eca rule triggered to the
>>> creation of InventoryItem records that checks if these fields are empty
>>> and if possible fills them with default values, if not return an error
>>> message.
>>>
>>> Some details:
>>>
>>> * InventoryItem.facilityId: if not set the service will return an error
>>> and the inventory item will not be created; also, I'd like to make
>>> facilityId a mandatory field of the "createInventoryItem" service
>>>
>>> * InventoryItem.ownerPartyId: if not set, Facility.ownerPartyId will be
>>> used; if null, the service will return an error and the inventory item
>>> will not be created
>>>
>>> * InventoryItem.currencyUomId: if not set, the PartyAcctgPreference
>>> entry for the ownerPartyId is retrieved and
>>> PartyAcctgPreference.currencyUomId will be used; if null, the service
>>> will return an error and the inventory item will not be created
>>>
>>> * InventoryItem.unitCost: if not set, the product's standard cost will
>>> be retrieved (using the "getProductCost" service) and used as unitCost;
>>> if no std cost is available the service will return an error and the
>>> inventory item will not be created; also "unitCost" is now a mandatory
>>> field for the "createInventoryItem" service, I'll make it optional.
>>>
>>> What do you think of all this stuff?
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> ------------------------------------------------------------------------
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Si, David,

yes, since the two services are both written in minilang, it is very
easy for me to put the new validation inside the createInventoryItem
service...

I can do it if you think it's better.

Jacopo


Si Chen wrote:

> Jacopo,
>
> I think the problem is that EECA probably relies on some kind of
> rollback, and after many layers of code somewhere it's not passing back
> the message.  You could go back and try to change some of the event
> handler or entity engine code and see if David could commit it for us?  
> Or maybe David's idea to put your code into the service
> createInventoryItem or just call it from createInventoryItem is a good
> one, instead of relying on an EECA.
>
> Si
>
> Jacopo Cappellato wrote:
>
>> Si,
>>
>> the error message on screen is (for example in the EditInventoryItem
>> page):
>>
>> The Following Errors Occurred:
>> * Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>> Service invocation error (Commit transaction failed)
>>
>> In the log you can find the real cause of the problem, i.e. one of the
>> error messages generated by my new service (this is good) but inside a
>> big error log (see attached file).
>>
>> Jacopo
>>
>> Si Chen wrote:
>>
>>> What does the message on the screen or dump log look like?
>>>
>>> Si
>>>
>>> Jacopo Cappellato wrote:
>>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

Maybe just call your new service inside the other one, instead of moving
the code. It's nice to have more modular code too.

Si

Jacopo Cappellato wrote:

>Si, David,
>
>yes, since the two services are both written in minilang, it is very
>easy for me to put the new validation inside the createInventoryItem
>service...
>
>I can do it if you think it's better.
>
>Jacopo
>
>
>Si Chen wrote:
>  
>
>>Jacopo,
>>
>>I think the problem is that EECA probably relies on some kind of
>>rollback, and after many layers of code somewhere it's not passing back
>>the message.  You could go back and try to change some of the event
>>handler or entity engine code and see if David could commit it for us?  
>>Or maybe David's idea to put your code into the service
>>createInventoryItem or just call it from createInventoryItem is a good
>>one, instead of relying on an EECA.
>>
>>Si
>>
>>Jacopo Cappellato wrote:
>>
>>    
>>
>>>Si,
>>>
>>>the error message on screen is (for example in the EditInventoryItem
>>>page):
>>>
>>>The Following Errors Occurred:
>>>* Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>Service invocation error (Commit transaction failed)
>>>
>>>In the log you can find the real cause of the problem, i.e. one of the
>>>error messages generated by my new service (this is good) but inside a
>>>big error log (see attached file).
>>>
>>>Jacopo
>>>
>>>Si Chen wrote:
>>>
>>>      
>>>
>>>>What does the message on the screen or dump log look like?
>>>>
>>>>Si
>>>>
>>>>Jacopo Cappellato wrote:
>>>>
>>>>        
>>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>>      
>>>
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>    
>>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

I don't think you'd even have to call it as a service. You can just
call-method or something, right, and call another method directly?

Si Chen wrote:

>Maybe just call your new service inside the other one, instead of moving
>the code. It's nice to have more modular code too.
>
>Si
>
>Jacopo Cappellato wrote:
>
>  
>
>>Si, David,
>>
>>yes, since the two services are both written in minilang, it is very
>>easy for me to put the new validation inside the createInventoryItem
>>service...
>>
>>I can do it if you think it's better.
>>
>>Jacopo
>>
>>
>>Si Chen wrote:
>>
>>
>>    
>>
>>>Jacopo,
>>>
>>>I think the problem is that EECA probably relies on some kind of
>>>rollback, and after many layers of code somewhere it's not passing back
>>>the message.  You could go back and try to change some of the event
>>>handler or entity engine code and see if David could commit it for us?  
>>>Or maybe David's idea to put your code into the service
>>>createInventoryItem or just call it from createInventoryItem is a good
>>>one, instead of relying on an EECA.
>>>
>>>Si
>>>
>>>Jacopo Cappellato wrote:
>>>
>>>  
>>>
>>>      
>>>
>>>>Si,
>>>>
>>>>the error message on screen is (for example in the EditInventoryItem
>>>>page):
>>>>
>>>>The Following Errors Occurred:
>>>>* Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>>Service invocation error (Commit transaction failed)
>>>>
>>>>In the log you can find the real cause of the problem, i.e. one of the
>>>>error messages generated by my new service (this is good) but inside a
>>>>big error log (see attached file).
>>>>
>>>>Jacopo
>>>>
>>>>Si Chen wrote:
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>>>What does the message on the screen or dump log look like?
>>>>>
>>>>>Si
>>>>>
>>>>>Jacopo Cappellato wrote:
>>>>>
>>>>>      
>>>>>
>>>>>          
>>>>>
>>>>------------------------------------------------------------------------
>>>>
>>>>
>>>>_______________________________________________
>>>>Dev mailing list
>>>>[hidden email]
>>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>>>    
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>>  
>>>
>>>      
>>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>>
>>    
>>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

You are right,

and I'll need to do some minor changes to the new service.

Jacopo

Si Chen wrote:

> I don't think you'd even have to call it as a service. You can just
> call-method or something, right, and call another method directly?
>
> Si Chen wrote:
>
>> Maybe just call your new service inside the other one, instead of moving
>> the code. It's nice to have more modular code too.
>>
>> Si
>>
>> Jacopo Cappellato wrote:
>>
>>  
>>
>>> Si, David,
>>>
>>> yes, since the two services are both written in minilang, it is very
>>> easy for me to put the new validation inside the createInventoryItem
>>> service...
>>>
>>> I can do it if you think it's better.
>>>
>>> Jacopo
>>>
>>>
>>> Si Chen wrote:
>>>
>>>
>>>    
>>>
>>>> Jacopo,
>>>>
>>>> I think the problem is that EECA probably relies on some kind of
>>>> rollback, and after many layers of code somewhere it's not passing back
>>>> the message.  You could go back and try to change some of the event
>>>> handler or entity engine code and see if David could commit it for us?  
>>>> Or maybe David's idea to put your code into the service
>>>> createInventoryItem or just call it from createInventoryItem is a good
>>>> one, instead of relying on an EECA.
>>>>
>>>> Si
>>>>
>>>> Jacopo Cappellato wrote:
>>>>
>>>>  
>>>>
>>>>      
>>>>
>>>>> Si,
>>>>>
>>>>> the error message on screen is (for example in the EditInventoryItem
>>>>> page):
>>>>>
>>>>> The Following Errors Occurred:
>>>>> * Error calling event: org.ofbiz.webapp.event.EventHandlerException:
>>>>> Service invocation error (Commit transaction failed)
>>>>>
>>>>> In the log you can find the real cause of the problem, i.e. one of the
>>>>> error messages generated by my new service (this is good) but inside a
>>>>> big error log (see attached file).
>>>>>
>>>>> Jacopo
>>>>>
>>>>> Si Chen wrote:
>>>>>
>>>>>    
>>>>>
>>>>>        
>>>>>
>>>>>> What does the message on the screen or dump log look like?
>>>>>>
>>>>>> Si
>>>>>>
>>>>>> Jacopo Cappellato wrote:
>>>>>>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

On Mar 10, 2006, at 11:33 AM, Jacopo Cappellato wrote:

> 1) I was not sure if the "createInventoryItem" is the only one method
> used to create inventory items (my fear is that somewhere in the  
> system
> inventory items could be created bypassing the service engine)

This is, unfortunately, always a possibility and it is impossible to  
"enforce" using the services. In some cases we want different  
functionality and need to do direct entity interactions, but really  
ALL data changes should go through the core services for any given  
entity or set of entities. Unfortunately this isn't always done and  
over time we'll just have to improve this. In cases where using the  
core services for data changes for an entity is not possibly, there  
should be comments in the code to explain why it wasn't possible and/
or in general why it was done.

Until the system in general is "perfect" we should follow this  
pattern of doing validation in the services rather than using EECAs  
and eventually things will "clean up real nice like". This is the  
pattern we've established. As I've written before, Entity ECAs should  
really _only_ be used for maintaining "derivative" data, ie data that  
is based on other data (like to qoh and atp totals in InventoryItem  
based on the InventoryItemDetail fields), and shouldn't generally be  
part of a business process.

-David


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[cjhowe]

I am quite new to java in general, but can't you
"force" services to be used by making the only public
methods (Request, Response)?

--- "David E. Jones" <[hidden email]> wrote:

>
> On Mar 10, 2006, at 11:33 AM, Jacopo Cappellato
> wrote:
>
> > 1) I was not sure if the "createInventoryItem" is
> the only one method
> > used to create inventory items (my fear is that
> somewhere in the  
> > system
> > inventory items could be created bypassing the
> service engine)
>
> This is, unfortunately, always a possibility and it
> is impossible to  
> "enforce" using the services. In some cases we want
> different  
> functionality and need to do direct entity
> interactions, but really  
> ALL data changes should go through the core services
> for any given  
> entity or set of entities. Unfortunately this isn't
> always done and  
> over time we'll just have to improve this. In cases
> where using the  
> core services for data changes for an entity is not
> possibly, there  
> should be comments in the code to explain why it
> wasn't possible and/
> or in general why it was done.
>
> Until the system in general is "perfect" we should
> follow this  
> pattern of doing validation in the services rather
> than using EECAs  
> and eventually things will "clean up real nice
> like". This is the  
> pattern we've established. As I've written before,
> Entity ECAs should  
> really _only_ be used for maintaining "derivative"
> data, ie data that  
> is based on other data (like to qoh and atp totals
> in InventoryItem  
> based on the InventoryItemDetail fields), and
> shouldn't generally be  
> part of a business process.
>
> -David
>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Well, we're not exactly talking about Java methods in the case of the  
service oriented architecture in OFBiz. Even if it were object  
oriented, with a database there is always a problem of going around  
the business logic and hitting the database directly, unless you go  
down the path of architecting an application to put all of your  
validation and logic in the database itself, although that causes  
other problems that are significant enough that much of the world in  
general and OFBiz in particular are staying well away from it.

-David


On Mar 10, 2006, at 12:54 PM, Chris Howe wrote:

> I am quite new to java in general, but can't you
> "force" services to be used by making the only public
> methods (Request, Response)?
>
> --- "David E. Jones" <[hidden email]> wrote:
>
>>
>> On Mar 10, 2006, at 11:33 AM, Jacopo Cappellato
>> wrote:
>>
>>> 1) I was not sure if the "createInventoryItem" is
>> the only one method
>>> used to create inventory items (my fear is that
>> somewhere in the
>>> system
>>> inventory items could be created bypassing the
>> service engine)
>>
>> This is, unfortunately, always a possibility and it
>> is impossible to
>> "enforce" using the services. In some cases we want
>> different
>> functionality and need to do direct entity
>> interactions, but really
>> ALL data changes should go through the core services
>> for any given
>> entity or set of entities. Unfortunately this isn't
>> always done and
>> over time we'll just have to improve this. In cases
>> where using the
>> core services for data changes for an entity is not
>> possibly, there
>> should be comments in the code to explain why it
>> wasn't possible and/
>> or in general why it was done.
>>
>> Until the system in general is "perfect" we should
>> follow this
>> pattern of doing validation in the services rather
>> than using EECAs
>> and eventually things will "clean up real nice
>> like". This is the
>> pattern we've established. As I've written before,
>> Entity ECAs should
>> really _only_ be used for maintaining "derivative"
>> data, ie data that
>> is based on other data (like to qoh and atp totals
>> in InventoryItem
>> based on the InventoryItemDetail fields), and
>> shouldn't generally be
>> part of a business process.
>>
>> -David
>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev