Re: [ebxml-bp] RE: BSI retries question - trying again

[Sacha Schlegel <sacha_oasis@schlegel.li>]

Hi Steve
Hi Anthony

I assume you are referencing BPSS 1.1

There is an optional retry attribute in the RequestingBusinessActivity
of type xsd:int

The comment on this attribute is:

"The BSI must retry to send a request n number of times,
in case no signals are returned by the responding activity."

If I understand you right, the requesting business document has been
sent and a Receipt Acknowledgment (Reqeust.ACK.Receipt in 1.1) has been
received. You then received Then you are waiting for either an
Acceptance Exception (Request.NACK.Acceptance in 1.1) and now is the
question whether you can start the requesting business activity again,
with a "new" requesting business document, eg changed payload? or
whether this BPSS instance just fails.

I do not know what others think but I would understand that the business
process fails. You did recieve a signal, just a negative one. 

In my eyes this is information the business analyst can model and is
then propagated down to the CPA where you have the retry count, which I
think is how many times you have to try to send the original business
request document.

I would not interpret it that the BSI can change the payload of the
message "retry" times and try and see if the other party likes the
changed request better. 

Question would be: what happens if this is the last message exchange in
a long running process (eg over several days)? It could be a pain to
have the process start from the beginning again. Could indicate that the
collaborative business better has to be modelled differently (eg process
2 follows one process 1, so two parties can continue with process 2 once
process 1 succeeded).

Maybe a good case for BSI interoperability test cases...

Intersted what others think.

Regards

Sacha

PS: I just found out in Figure 17 "Computation of the Status of a
Business Transaction Activity" of the BPSS 1.1 that the responding
business activity ALSO has an Acceptance Acknowledgment/Exception (eg
Response.ACK.Acceptance, and Response.NACK.Acceptance) messages.

Am Dienstag, den 07.09.2004, 07:53 +1000 schrieb Steve Capell:
> Hi all,
> 
>  
> 
> Nobody responded to this one.  It is an important clarification
> because if different BSIs take a different interpretation of retry
> count then one side might terminate the process after an acceptance
> NACK whilst the other attampts a retry….
> 
>  
> 
> Any comments?
> 
>  
> 
> Steve Capell
> 
> Red Wahoo Pty Ltd
> 
> +61 410 437854
> 
> 
>  
> 
>                                    
> ______________________________________________________________________
> 
> From: Steve Capell [mailto:steve.capell@redwahoo.com] 
> Sent: Thursday, 2 September 2004 7:26 PM
> To: 'ebXML BP'
> Cc: 'anthony.ellis@redwahoo.com'
> Subject: BSI retries question
> 
> 
>  
> 
> Hello all,
> 
>  
> 
> I have a question about exception handling in the context of a BSI
> that is “managing” a BPSS process.   The BSI aggregates all the
> different events that might lead to a protocol failure into one
> “protocol success/ protocol failure” signal to the next layer
> (typically a BPM executing a BPEL?).  
> 
>  
> 
> Is it correct to assume that the “retry count” attribute of the
> “requesting business activity” element represents the maximum number
> of BUSINESS retries and is entirely separate from any technical
> retries at the reliable messaging layer?  For example, if send a
> message that is successfully received from the message handler
> perspective (eg I get a receipt ACK from the other side) but fails
> from the business perspective (eg I get an acceptance NACK) then I can
> modify the document and retry the request in the context of the SAME
> business process instance?  
> 
>  
> 
> However in the context of a time to perform timeout we assume that we
> cannot retry because a mutually agreed maximum time to perform a
> business operation has been exceeded.  In this case the transaction
> needs to be rolled back and tried again in the context of a NEW
> business process instance (or handled manually).
> 
>  
> 
> Hoping someone can confirm our understanding….
> 
>  
> 
> Regards,
> 
>  
> 
> Steve Capell
> 
> Red Wahoo Pty Ltd
> 
> +61 410 437854
> 
>  
> 
>

Dies ist ein digital signierter Nachrichtenteil