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

["Yunker, John" <yunker@amazon.com>]

Title: RE: [ebxml-bp] ebBP 3/21/2005: Comment re: Business Retries and Exception Signals (wd10/schema 2-22)

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.

Thanks!
John

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: Monday, March 21, 2005 3:52 PM
To: ebXML BP
Subject: [ebxml-bp] ebBP 3/21/2005: Comment re: Business Retries and Exception Signals (wd10/schema 2-22)

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).