Login  Register

Re: Users - sendMailToRoles

Posted by Charles Johnson-4 on May 01, 2006; 12:40pm
URL: http://ofbiz.116.s1.nabble.com/Users-sendMailToRoles-tp138731p138739.html



Andrew Sykes wrote:

>Charles,
>
>The definition for storeEmailAsCommunication is:
>
>Service Name: storeEmailAsCommunication
>Description: Store email as a communication event with the status
>COM_COMPLETE. The communication event will be from the party of the
>userLogin to the party of the partyId parameter. It is meant to run a
>SECA after a sendMail to record outgoing emails.
>Exportable: False
>
>The important point to notice is "It is meant to run a SECA after a
>sendMail to record outgoing emails."
>
>In case you haven't come across SECAs yet, here's a quick definition...
>
>SECA = Service Event Condition Action
>A SECA is constituted of three parts, a Service Event, a Condition and
>an Action.
>Service Event = When a particular stage of execution is reached on the
>named service.
>Condition = When specific features of the data being processed are
>found.
>Action = A service to run
>
>In applications/content/servicedef/secas.xml, you will see a definition
>for sendMail that looks like this...
>
><eca service="sendMail" event="commit">
>    <condition field-name="partyId" operator="is-not-empty"/>
>    <action service="storeEmailAsCommunication" mode="sync"/>
></eca>
>
>Each attribute is explained below
>
>eca
>service = sendMail
>event = one of...
> auth: on authorisation
> commit: on transaction commit
> global-commit: on global transaction commit
> global-rollback: on global transaction roll-back
> in-validate: on validation of 'IN' parameters
> invoke: on invocation of the service
> out-validate: on validation of 'OUT' parameters
> return: on service return
> (in each case these are run 'just before' the event)
>
>condition
>field-name = one of the 'IN' parameters
>operator = one of...
> contains
> equals
> greater
> greater-equals
> is-empty
> is-not-empty
> less
> less-equals
> not-equals
>Although not shown above some of these operators also require one of
>format/type/value attribute.
>
>action
>service: the service to call
>mode: one of
> sync: synchronous service call
> async: asynchronous service call
>
>>From all of the above, you can see that the SECA would only be called if
>partyId had a value.
>
>So, I guess that's the first thing to check. Let me know how you get
>on...
>  
>
An *excellent* explanation thank you Andrew. I shall look at it again.

I'm still not clear on what's providing the 'intelligence' here though.
The condition and action are clearly defined here:

<eca service="sendMail" event="commit">
    <condition field-name="partyId" operator="is-not-empty"/>
    <action service="storeEmailAsCommunication" mode="sync"/>
</eca>

but what exactly is providing the inspection, validation and so on here? It would seem that it can't be only the Java implementation as that would detract from the strength of the ability to be declarative (as in the 'eca' element) and what's more the declaration could easily get out of synch with the implementation ...

CJ



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