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

[Sacha Schlegel <sacha_oasis@schlegel.li>]

Hi Again

Some corrections. Sorry about that.

Regards

Sacha

Am Dienstag, den 07.09.2004, 00:46 +0200 schrieb Sacha Schlegel:
> 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. 

OLD:
> You then received Then you are waiting for either an

NEW:
 You then receive 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. 

The specification says in case no signals are returned, but in this
example a signal is returned (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.

PSII: There is no optional retry count attribute in the responding
business activity. Is this inconsistency or is there is reason?


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