Re: [ebxml-bp] ebBP 3/21/2005: Comment re: Business Retries andException Signals (wd10/schema 2-22)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Given your response John with the greater detail (consistent with mine), 
is that we actually place more text in this section for Business Retry. 
Here are the proposed changes that will discuss today (this change 
integrates yesterday's proposal and an update given the conversations 
vetted). I will address a subsequent proposed change on a related 
question from Sacha Schlegel (Note: I am not combining the two in order 
to keep people on track...hopefully).

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).
*
**Open question***: Do we need to provide an attribute to allow a reason 
the exception for RA and AA?  I could see it is 1...n reasons and 
related to the business document or receipt.

We will discuss in today's session if possible. Thank you.

> Yunker: re: "-> only used in a RequestingBusinessActivity
> if there is no default value does that mean there is no retry?"
>
>  >>mm1: Correct. John, can you input here if I have misconstrued.
>
> Actually, if the number of retries is not specified, then the partners 
> have not agreed to a retry protocol.
>
> My take is: in that case, the initiating partner MAY retry as many or 
> as few times as they choose.
>
> If you do NOT want your partner to retry, then the number of retries 
> should be explicitly ZERO.
>
> mm1 3/21: Schlegel question raised about retries. See responses 
> inline. I don't
>
> believe we need any proposed changes unless other team members have
> comments. Thanks.
>
> ========================================================================================================== 
>
> retryCount is a business retry.
>
> -> only used in a RequestingBusinessActivity
> if there is no default value does that mean there is no retry?
>
>  >>mm1: Correct. John, can you input here if I have misconstrued.
>
> if retryCount is set:
> o Does sending a retry after a ReceiptAcknowledgementException business
> signal counts as one retry?
>  >>mm1: A retry cannot be sent after such an exception occurs. See email
> just sent that addresses an explicit mention in Section 4.8.2.3 [1].
>
> o Does sending a retry after an AcceptanceAcknowledgementException
> business signal counts as one retry?
>  >>mm1: See previous response.
>
> Is it right that I cannot send a retry after an ReceiptAcknowledgment
> and not after an AcceptanceAcknowledgement business signal? A retry
> proabably works as defined in the RequestingBusinessActivity? 
> .........How can the backend_A find out WHY po was rejected? Is there a
> standardized AcceptanceAcknowledgementException reason value defined? If
> backend_A does not know WHY po was rejected ..... it will have a hard
> time to figure out how the next retry po should look like...
>
>  >>mm1: Retry is the same business message only with a different time
> stamp. We had a lengthy discussion before. It is not a retry with
> changed information (a topic of discussion for a later version perhaps).
>
> Example:
>
> _A is party A
> _B is party B
>
> backend_A generates purchase order (po). po goes to BSI_A which uses
> MSH_A to send ebXML message with id 1.
>
> MSH_B receives ebXML message with id 1 and goes through a BSI_B and to a
> backend_B. Backend_B sends ReceiptAcknowledgement to A side. Backend_B
> for example checks credit status of party A and has to say NO. So
> backend_B generates a AcceptanceAcknowledgementException (or based on
> some implementation dependent action a non-logical-abstract-BSI
> recognises the situation and generates an
> AcceptanceAcknowledgementException business signal.
>
> question A: I guess this is exactly what for business people is
> important. If the underlying Business transaction pattern requires to
> send Acceptance business signals, it is necessary to also send a
> AcceptanceAcknowledgementException and NOT to skip it and send a
> negative Response.
>
>  >>mm1: Correct, this allows the parties to react more quickly.
>
> The BSI_B sends the AcceptanceAcknowledgementException to MSH_B which
> sends to MSH_A, which sends to BSI_A which sends to backend_A. 
> Backend_A must associate AcceptanceAcknowledgementException (as it had
>
> to do with ReceiptAcknowledgement) to po
>
>
> [1] 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).
>