Re: [ebxml-bp] RE: BSI retries question - further clarification

[Martin Sachs <msachs@cyclonecommerce.com>]

I haven't been much tuned into the BPSS discussions recently but I am
sensing the start of a slippery slope in this discussion.

We understand retrying at a messaging or transmission level: 
Something (perhaps a transmission error) caused the message to fail to be
received at all (within some timeout) or to be received with some error
condition that requires discarding the received message.  We permit
the sender to re-send the identical message some number of times on the
assumption that it will probably be correctly received before the maximum
number of retries is exhausted. If the maximum number of retries is
exhausted, the sender attempts to determine and correct the cause of a
permanent error and the operation is restarted from some higher
level.

Once we get into correcting logical errors in the information, we into a
much more complex situation with a possibly unbounded number of
conditions and combinations of conditions.  Unless someone has
already completed an analysis of these kinds of error conditions and has
a proposal for (semi-)automating their recovery, I suggest that:

• For now, retries be confined to the well-understood error conditions that can be retried without changing the content of the message. Errors in the business process which would require changes in the contents of the message in error should be handled by failing the business process, making the corrections, and restarting the business process from the beginning.
• Automatically retrying of errors in the business process be put on a futures list.

Regards,
Marty


At 08:13 PM 9/6/2004, Monica J. Martin wrote:

Let's see if I can weave my way through the starting discussion thread on a holiday (Thanks Sacha for the great followthrough while I was enjoying a fall day).
See my additional comments inline (***mm1: .....***). I encoureage others to comment as well.

Steve Capell wrote:

Capell: Sacha,

Thanks for your feedback.  From an academic perspective what you say makes
sense but I'm just thinking about market acceptance of BPSS based BSI
infrastructure and what reasonable human expectations would be in a real
practical scenario.

The problem is that it is hard to define to what extent a "changed payload"
could be permitted in the context of a retry.  The original basis for my
question was that we often encounter the situation where a business
acceptance fails for a fairly trivial reason.  Consider the following simple
scenario:

1       ACME sends a purchase order to their supplier Widget Co.  All
business signals (receipt & acceptance ACK) are positive.
2       Widget Co generates an order response.  Their system uses arbitrary
internal UOM codes that are transformed to EDIFACT UOM codes before sending
to external parties.  However in this case the transformation is missing so
the order response goes out with a line item UOM of "each" instead of "EA". 3   The ACME system expects EDIFACT UOM and so rejects the order
response and the AVME BSI creates an acceptance NACK.
4       The Widget Co administrator receives a notification from the Widget
Co BSI, quickly identifies the problem and makes a new entry in the Widget
Co UOM mapping tables for "Each" to "EA" mapping. 
 

***mm1: My question would be how you would differentiate the trivial from the business substantive reason here. The reason being is that if the document is changed, this could trigger an open question if the business relationship is also. Some time ago pre-v1.1, we discussed that a warning could occur on an AA not exception but it was from the responding entity perspective. Perhaps we should investigate this further. We also have talked about starting / restarting a business process when alternate means are used [1].

[1] Where for example the order is done via fax and you need to engage the gateways to the automated processing. These two cases buttress on the same/similar set of questions / situations. See comments below.

Now, should Widget Co who is the supplier in this relationship be able to
re-send the Order Response in the context of the same business process or
should the whole collaboration be rolled back - which leaves two options:
1       The two parties have to do manual processing 2  Widget Co has to ask their customer to re-send the original order.

I suspect that the adminsitrator at the Widget Co end would expect to be
able to re-send the corrected POR and that if he can't then he would be
escalating an issue to his management about failure of "this crappy BSI
thingy".

mm1: Hmm, that's a new term....Anyway, should we consider if the use of the extensions for the BT patterns could allow for such conditions. I still don't know how you could create a deterministic way to say this change is substantive or not, however. Perhaps, a notification could be sent in the extended pattern that allows for another order response (but this is purely an example to discuss the matter more fully than a well-thought out case). I'll bring it to the group's attention at our next meeting if we have time (special session with a presentation from an outside group already scheduled- sorry).

My position is that it is up to the business logic in the back-office system
to accept or reject business message. 

mm1: Isn't that the reason that it was rejected in the first place is that it did not meet the expectations?

Therefore whether it is a trivial
change (like the UOM issue) or a huge change to the payload in the context
of a business retry -  it simply does not matter.  It is not the job of the
BSI to determine the business validity of the content in a payload.

mm1: The BSI is only communicating back to partners after processing occurs. Doesn't the BSI handle syntactic validation, handed over for processing/in process and monitoring response from the partner)? A distinction is made in the previous v1.1 spec (section 5.9):

"A Business failure is any failure that is identified by an application during the processing of the business document(s) and based on information not available to the
BPSS. For instance, a “reject purchase order” response document would be considered as a business failure."

Therefore the question simply boils down to whether we accept the concept of
BUSINESS retry at BSI level as a separate thing to a TECHNICAL retry at
messaging level.

mm1: I think with the statement above (if it still holds true), the answer is yes. Let's get more responses this week. Steve, please think more on my suggestions as well. Thanks.

Regards,

Steve Capell
Red Wahoo Pty Ltd
+61 410 437854


-----Original Message-----
From: Sacha Schlegel [mailto:sacha_oasis@schlegel.li] Sent: Tuesday, 7 September 2004 8:55 AM
To: Steve Capell
Cc: ebXML BP; anthony.ellis@redwahoo.com
Subject: Re: [ebxml-bp] RE: BSI retries question - trying again

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



    

 

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com