OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ebBP 3/27/2005: Comment re: Business Retries and Exception Signals(wd10/schema 2-22) [update]


In line with our discussion Tuesday, here is an update to the Business 
Retry. John see the question raised by several TC members in that 22 
March 2005 call in Open Question section. We'll finalize in Tuesday's 
call. Thanks everyone.

Proposed changes:
=====================================================================================================
Section 4.8.2.3
Change from:
The business retry for a RequestingBusinessActivity identifies the 
number of retries allowed in addition to the initial request while the 
time to perform has not been exceeded. The business retry are associated 
with control exceptions such as timeouts. If the number of retries is 
not specified, the parties have not agreed to use a business retry. The 
requesting party may retry as many times as they choose (i.e. it is not 
constrained to a specific number). If a business retry count of 3 is 
chosen (in addition to the initial request), the requesting party MUST 
retry 3 times (no more and no less)......For example, if a business 
retry was not specified and a response was not received, an NOF could be 
issued. If the response is received, it is then ignored because the NOF 
has negated the business transaction.  In another circumstance, if any 
business exceptions (includes negative receipt and acceptance 
Acknowledgments) are signaled then the business transaction SHOULD 
terminate and no business retry SHOULD occur (even if parameter is other 
than zero).

Change to:
The business retry for a RequestingBusinessActivity identifies the 
number of retries allowed in addition to the initial request while the 
time to perform has not been exceeded. The business retry are associated 
with control exceptions such as timeouts. If the number of retries is 
not specified, the parties have not agreed to use a business retry. The 
requesting party may retry as many times as they choose (i.e. it is not 
constrained to a specific number). If a business retry count of 3 is 
chosen (in addition to the initial request), the requesting party MUST 
retry 3 times (no more and no less)......For example, if a business 
retry was not specified and a response was not received, an NOF could be 
issued. If the response is received, it is then ignored because the NOF 
has negated the business transaction.  In another circumstance, if any 
business exceptions (includes negative receipt and acceptance 
Acknowledgments) are signaled then the business transaction SHOULD 
terminate and no business retry SHOULD occur (even if parameter is other 
than zero). Business retries do not apply to exception signals.
=====================================================================================================

Open question:

    * If the retry count is '3', why must all three be sent? Reference
      Yunker response:
      http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200503/msg00074.html

Previous text: 21 March 2005 reference: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200503/msg00077.html 
(shown below)

> Section 4.8.2.3:
> ===========
> Change from: The business retry for a RequestingBusinessActivity 
> identifies the number of retries allowed in addition to the initial 
> request while the time to perform has not been exceeded.....For 
> example, if a business retry was not specified and a response was not 
> received, an NOF could be issued. If the response is received, it is 
> then ignored because the NOF has negated the business transaction.
>
> Change to:
> The business retry for a RequestingBusinessActivity identifies the 
> number of retries allowed in addition to the initial request while the 
> time to perform has not been exceeded. If the number of retries is not 
> specified, the parties have not agreed to use a business retry. The 
> requesting party may retry as many times as they choose (i.e. it is 
> not constrained to a specific number). If a business retry count of 3 
> is chosen (in addition to the initial request), the requesting party 
> MUST retry 3 times (no more and no less)......For example, if a 
> business retry was not specified and a response was not received, an 
> NOF could be issued. If the response is received, it is then ignored 
> because the NOF has negated the business transaction.  In another 
> circumstance, if any business exceptions (includes negative receipt 
> and acceptance Acknowledgments) are signaled then the business 
> transaction SHOULD terminate and no business retry SHOULD occur (even 
> if parameter is other than zero).





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]