createPartyContactMech

[Adam Heath-2]

The above service has an eca, that attempts to create a
PartyContactMechPurpose, if contactMechPurposeTypeId is given.
However, since most the time a contactMechId is *not* given, the seca
that is configured will not fire.  The seca engine doesn't support
matching against the *result* of a called service, only against the
incoming context.

I'm considering adding support for testing against the result of a
service; anyone else see the utility in this?

[Scott Gray-2]

Hi Adam

Are you sure it doesn't test against the outgoing the parameters?  A  
lot of status change secas depend on an outgoing oldStatusId, e.g. the  
changeOrderStatus service secas

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 15/09/2009, at 11:53 AM, Adam Heath wrote:

> The above service has an eca, that attempts to create a
> PartyContactMechPurpose, if contactMechPurposeTypeId is given.
> However, since most the time a contactMechId is *not* given, the seca
> that is configured will not fire.  The seca engine doesn't support
> matching against the *result* of a called service, only against the
> incoming context.
>
> I'm considering adding support for testing against the result of a
> service; anyone else see the utility in this?
>

[Adam Heath-2]

Scott Gray wrote:
> Hi Adam
>
> Are you sure it doesn't test against the outgoing the parameters?  A lot
> of status change secas depend on an outgoing oldStatusId, e.g. the
> changeOrderStatus service secas

Ok, yes, I was wrong about the details.

createPartyContactMech detects that a matching ContactMech already
exists for a party(based on infoString), logs that it matches, and
returns success, without returning the contactMechId.

[Scott Gray-2]

That sounds much easier to fix :-)

Additionally we should probably change contactMechId to be optional IN  
but required OUT

Regards
Scott

On 15/09/2009, at 12:13 PM, Adam Heath wrote:

> Scott Gray wrote:
>> Hi Adam
>>
>> Are you sure it doesn't test against the outgoing the parameters?  
>> A lot
>> of status change secas depend on an outgoing oldStatusId, e.g. the
>> changeOrderStatus service secas
>
> Ok, yes, I was wrong about the details.
>
> createPartyContactMech detects that a matching ContactMech already
> exists for a party(based on infoString), logs that it matches, and
> returns success, without returning the contactMechId.
>