RE: [ebxml-bp] Data / BTA Retries - the tale of two camels

["Yunker, John" <yunker@amazon.com>]

The number of business retries originated with RosettaNet, as a control in uncertain environments.

The business purpose is to formalize an agreement that if the systems involved break down, the behavior of the participants is predictible, both in setting aside the pending agreement and in providing a mechanism for the business to proceed.

The notification of failure is tied in with this as well, so that both parties are protected from assuming the other is going ahead with the transaction.

Remember that both parties are at risk of financial loss if they assume all is well, and because of either protocol or system failure the transaction does not proceed.

Now, if all parties are:
	1) using reliable reliable messaging (intentional repetition of the word reliable)
	2) their b2b software has business process capabilities (knows when an owed response is not triggered by their business software)
	3) have SLA timeouts with notification of partner in their backend or b2b software

Then you can dispense with the retries and NOF.  PLEASE NOTE that if you don't "get" a response to an offer, before just moving on you had better be sure it is not the fault of your own software, or you may be stuck with the merchandise from both the original seller, and the one you moved on to.

These considerations are best considered in the context of business agreements, which is what UBAC is supposed to be working on.  When RosettaNet, the BCF, and early ebXML were being considered, the retries were in the schema to provide a mechanism for the "eventual" business agreements to communicate expected business behavior.

No simple answer here, unless we limit the scope of our considerations.

John

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Tuesday, September 07, 2004 8:18 AM
To: ebXML BP
Subject: [ebxml-bp] Data / BTA Retries - the tale of two camels


So OK - data validation retries is problematic- but it basically comes down to two strategies -

#1 - if you live in the desert - there is no such thing as an ugly camel.

So you will probably set your system to accept anyones data (eg live new orders for $$$!) - and trap problems at your data handler side - and use something like CAM to tailor transformations to get the order into your order processing system come what may.  You smile and send partners a 'thank you' confirmation.

#2 - you live on the water oasis and you get indundated with people leaving
        their stinking camels on your front yard and trying to pass off 
their
        camels on you.  You only want the best camels, with no problems.

So you will probably set your system to automatically warn off bad transactions - so you can deal with real orders from your best customers. You do not have time to fool with one-offs.

In either case a re-try flag is pretty superflous - since neither mode requires retry!

Cheers, DW