Re: Overriding Timing Parameters Specified in a Business Process

[Arvola Chan <arvola@tibco.com>]

Cory,

Do you mean I have to first create a new business process by substituting
parameter values for an existing business process, and then have the
CPP/CPA refer to the new business process?

I was hoping to be able to do the overriding without having to create a
new business process. Up to now, RosettaNet's policy has been to control
the specification of partner interface processes tightly.

The CPP/CPA allows certain BPSS parameters to be overridden, so
why not the timing parameters?

Thanks,
-Arvola

-----Original Message-----
From: Cory Casanave <cory-c@enterprise-component.com>
To: 'Arvola Chan' <arvola@tibco.com>; ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>
Date: Monday, August 20, 2001 12:11 PM
Subject: RE: Overriding Timing Parameters Specified in a Business Process


>Arvola,
>Why do you say you can not override these parameters?  This is specifically
>the intent of the "SubstitutionSet" in the BPSS.
>Regards,
>Cory Casanave
>
>> -----Original Message-----
>> From: Arvola Chan [SMTP:arvola@tibco.com]
>> Sent: Monday, August 20, 2001 2:35 PM
>> To: ebxml-cppa@lists.oasis-open.org
>> Subject: Overriding Timing Parameters Specified in a Business Process
>>
>> The BPSS spec. makes use of the timeToAcknowledgeReceipt and
>> TimeToAcknowledgeAcceptance attributes to indicate whether the receipt
>> acknowledgement / acceptance business signals are to be used, as well as
>> their corresponding timeout values.
>>
>> Currently, it is not possible to override these parameters at the CPP/CPA
>> level.
>>
>> The RosettaNet architecture team has been investigating the possible use
>> of the ebXML MSG, CPPA, and BPSS specs in future versions of the
>> RosettaNet Implementation Framework. Most RosettaNet solution providers
>> already allow these timing parameters to be customized as part of the
>> trading partner agreement in existing implementations.
>>
>> Personally, I think these timing parameters should be overridable in the
>> CPPA 1.1 spec. However, this brings up another deficiency in the existing
>> spec. BPSS parameters that can be overridden are essentially boolean
>> attributes. (In fact, it would be rather cumbersome for a party to
>> indicate that it can accept both True and False values for these
>> attributes. Essentially, all acceptable combinations would have to be
>> enumerated!) There is no established convention to specify the range of
>> acceptable values for non boolean attributes as well their preferred
>> values. Therefore, it is not clear to me whether such enhancements can be
>> introduced easily.
>>
>> -Arvola
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>