[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: BSI retries question - trying again
|
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] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]