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

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

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