Question about ECAs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about ECAs

Adrian Crum
Can I use EECAs or SECAs to monitor an entity and trigger an action if
the contents of a field changed? I need a way to track status changes.

-Adrian
Reply | Threaded
Open this post in threaded view
|

Re: Question about ECAs

Brad Plies
Yes.  I believe that is their purpose.  The difference between the two, I imagine, is what you are monitoring.  1.  You could use an EECA to monitor an entity like OrderStatus and hook into the update event and do some logic on event to determine if you want to do something or not.  You might use this to trigger some action.

2.  You could use a SECA to monitor a service like updateOrderStatus and do something similar.  You might use this to intercept and alter the service call, or trigger some action as above.  

I do not know what the recommended practice within OFBIZ is.  But a quick glance over the stock applications suggests that SECAs are more common than ECAs.

Brad


Adrian Crum wrote
Can I use EECAs or SECAs to monitor an entity and trigger an action if
the contents of a field changed? I need a way to track status changes.

-Adrian
Reply | Threaded
Open this post in threaded view
|

Re: Question about ECAs

David E Jones
In reply to this post by Adrian Crum

Are you wondering about when to use an EECA versus when to use an SECA?

In general you should not use EECAs for anything business process  
related, but rather for data maintenance tasks like populating  
denormalized fields (like OrderHeader.grandTotal), or things like  
keeping the status history. However, usually status history  
maintenance code goes right into the create and update services, like  
in the updateExample service. I'm working on this a little bit  
relative to the new entity-auto service engine implementation do  
handle some of these standard patterns automatically.

SECAs are the tool for composing business processes and tying separate  
processes together. They are obviously used for other things, but  
their main purpose is to get a process started automatically based on  
a "system event" instead of a "user event". For example, invoice an  
order once a shipment is packed.

-David


On Jul 23, 2008, at 6:38 PM, Adrian Crum wrote:

> Can I use EECAs or SECAs to monitor an entity and trigger an action  
> if the contents of a field changed? I need a way to track status  
> changes.
>
> -Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Question about ECAs

Adrian Crum
David,

Thank you very much for the advice. I'll keep those differences in mind.

I guess my question wasn't very clear. I need to know if there is
functionality in the SECA to detect if a field changed. I'm thinking
there isn't and I'll have to write some code to keep a history of status
changes.

-Adrian

David E Jones wrote:

>
> Are you wondering about when to use an EECA versus when to use an SECA?
>
> In general you should not use EECAs for anything business process
> related, but rather for data maintenance tasks like populating
> denormalized fields (like OrderHeader.grandTotal), or things like
> keeping the status history. However, usually status history maintenance
> code goes right into the create and update services, like in the
> updateExample service. I'm working on this a little bit relative to the
> new entity-auto service engine implementation do handle some of these
> standard patterns automatically.
>
> SECAs are the tool for composing business processes and tying separate
> processes together. They are obviously used for other things, but their
> main purpose is to get a process started automatically based on a
> "system event" instead of a "user event". For example, invoice an order
> once a shipment is packed.
>
> -David
>
>
> On Jul 23, 2008, at 6:38 PM, Adrian Crum wrote:
>
>> Can I use EECAs or SECAs to monitor an entity and trigger an action if
>> the contents of a field changed? I need a way to track status changes.
>>
>> -Adrian
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Question about ECAs

David E Jones

There is an example of tracking status history in a separate entity in  
the example component, and that pattern is a pretty good one to use.  
It uses SECA rules on the createExample and updateExample services,  
and now that you mention it maybe those would work out fine as EECA  
rules... not sure off the top of my head though.

BTW, for other general field change history stuff you can use the  
relatively new feature of the entity engine for that, done with the  
enable-audit-log attribute on the entity -> field element. There is an  
example of it in the entitymodel_test.xml file on the Testing entity.

-David


On Jul 24, 2008, at 9:32 AM, Adrian Crum wrote:

> David,
>
> Thank you very much for the advice. I'll keep those differences in  
> mind.
>
> I guess my question wasn't very clear. I need to know if there is  
> functionality in the SECA to detect if a field changed. I'm thinking  
> there isn't and I'll have to write some code to keep a history of  
> status changes.
>
> -Adrian
>
> David E Jones wrote:
>> Are you wondering about when to use an EECA versus when to use an  
>> SECA?
>> In general you should not use EECAs for anything business process  
>> related, but rather for data maintenance tasks like populating  
>> denormalized fields (like OrderHeader.grandTotal), or things like  
>> keeping the status history. However, usually status history  
>> maintenance code goes right into the create and update services,  
>> like in the updateExample service. I'm working on this a little bit  
>> relative to the new entity-auto service engine implementation do  
>> handle some of these standard patterns automatically.
>> SECAs are the tool for composing business processes and tying  
>> separate processes together. They are obviously used for other  
>> things, but their main purpose is to get a process started  
>> automatically based on a "system event" instead of a "user event".  
>> For example, invoice an order once a shipment is packed.
>> -David
>> On Jul 23, 2008, at 6:38 PM, Adrian Crum wrote:
>>> Can I use EECAs or SECAs to monitor an entity and trigger an  
>>> action if the contents of a field changed? I need a way to track  
>>> status changes.
>>>
>>> -Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Question about ECAs

Adrian Crum
David,

Thank you for the info - that was very helpful.

I wonder if there would be any interest in a new entity field attribute
- something like on-change-call-service. The attribute's value is a
service name. When the field's contents change the specified service is
called with the old GenericValue and the new GenericValue.

-Adrian

David E Jones wrote:

>
> There is an example of tracking status history in a separate entity in
> the example component, and that pattern is a pretty good one to use. It
> uses SECA rules on the createExample and updateExample services, and now
> that you mention it maybe those would work out fine as EECA rules... not
> sure off the top of my head though.
>
> BTW, for other general field change history stuff you can use the
> relatively new feature of the entity engine for that, done with the
> enable-audit-log attribute on the entity -> field element. There is an
> example of it in the entitymodel_test.xml file on the Testing entity.
>
> -David
>
>
> On Jul 24, 2008, at 9:32 AM, Adrian Crum wrote:
>
>> David,
>>
>> Thank you very much for the advice. I'll keep those differences in mind.
>>
>> I guess my question wasn't very clear. I need to know if there is
>> functionality in the SECA to detect if a field changed. I'm thinking
>> there isn't and I'll have to write some code to keep a history of
>> status changes.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> Are you wondering about when to use an EECA versus when to use an SECA?
>>> In general you should not use EECAs for anything business process
>>> related, but rather for data maintenance tasks like populating
>>> denormalized fields (like OrderHeader.grandTotal), or things like
>>> keeping the status history. However, usually status history
>>> maintenance code goes right into the create and update services, like
>>> in the updateExample service. I'm working on this a little bit
>>> relative to the new entity-auto service engine implementation do
>>> handle some of these standard patterns automatically.
>>> SECAs are the tool for composing business processes and tying
>>> separate processes together. They are obviously used for other
>>> things, but their main purpose is to get a process started
>>> automatically based on a "system event" instead of a "user event".
>>> For example, invoice an order once a shipment is packed.
>>> -David
>>> On Jul 23, 2008, at 6:38 PM, Adrian Crum wrote:
>>>> Can I use EECAs or SECAs to monitor an entity and trigger an action
>>>> if the contents of a field changed? I need a way to track status
>>>> changes.
>>>>
>>>> -Adrian
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Question about ECAs

David E Jones

I'd rather have this supported with EECA rules and have them separate  
from the entity defs themselves....

-David


On Jul 24, 2008, at 11:11 AM, Adrian Crum wrote:

> David,
>
> Thank you for the info - that was very helpful.
>
> I wonder if there would be any interest in a new entity field  
> attribute - something like on-change-call-service. The attribute's  
> value is a service name. When the field's contents change the  
> specified service is called with the old GenericValue and the new  
> GenericValue.
>
> -Adrian
>
> David E Jones wrote:
>> There is an example of tracking status history in a separate entity  
>> in the example component, and that pattern is a pretty good one to  
>> use. It uses SECA rules on the createExample and updateExample  
>> services, and now that you mention it maybe those would work out  
>> fine as EECA rules... not sure off the top of my head though.
>> BTW, for other general field change history stuff you can use the  
>> relatively new feature of the entity engine for that, done with the  
>> enable-audit-log attribute on the entity -> field element. There is  
>> an example of it in the entitymodel_test.xml file on the Testing  
>> entity.
>> -David
>> On Jul 24, 2008, at 9:32 AM, Adrian Crum wrote:
>>> David,
>>>
>>> Thank you very much for the advice. I'll keep those differences in  
>>> mind.
>>>
>>> I guess my question wasn't very clear. I need to know if there is  
>>> functionality in the SECA to detect if a field changed. I'm  
>>> thinking there isn't and I'll have to write some code to keep a  
>>> history of status changes.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> Are you wondering about when to use an EECA versus when to use an  
>>>> SECA?
>>>> In general you should not use EECAs for anything business process  
>>>> related, but rather for data maintenance tasks like populating  
>>>> denormalized fields (like OrderHeader.grandTotal), or things like  
>>>> keeping the status history. However, usually status history  
>>>> maintenance code goes right into the create and update services,  
>>>> like in the updateExample service. I'm working on this a little  
>>>> bit relative to the new entity-auto service engine implementation  
>>>> do handle some of these standard patterns automatically.
>>>> SECAs are the tool for composing business processes and tying  
>>>> separate processes together. They are obviously used for other  
>>>> things, but their main purpose is to get a process started  
>>>> automatically based on a "system event" instead of a "user  
>>>> event". For example, invoice an order once a shipment is packed.
>>>> -David
>>>> On Jul 23, 2008, at 6:38 PM, Adrian Crum wrote:
>>>>> Can I use EECAs or SECAs to monitor an entity and trigger an  
>>>>> action if the contents of a field changed? I need a way to track  
>>>>> status changes.
>>>>>
>>>>> -Adrian