ebBP 3/31/2005: Comment re: RA and AA Sequence (wd10-schema 2/22)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Another question from Sacha Schlegel at BPMI Think Tank. Both John 
Yunker and I have attempted to answer Sacha's question:

    What happens if AA received before RA?

Typically, depending on partner agreement, requesting party would 
recognize that the business document had been successfully  received and 
processed. In some cases, the requesting party may wait (if no timeout), 
for the RA as it may be handled by different systems [Martin]. Business 
protocol engines are expected to deal with AA / RA receipt precedence. 
Since many B2B systems are completely asynchronous there is no way to 
guarantee that physical receipt will be sequenced, only that logical 
receipt will be sequenced.

John's suggestion: My preference is that either best practice or 
specification would stipulate the ability to survive AA / RA ordering, 
as long as they are received within the time-out periods. Maybe we 
should discuss how best to specify.

In answer to Sacha and recognizing John's request, I suggest we discuss 
this in Tuesday's call. Proposed change for the technical specification 
is shown below for comment and review prior to 5 April. Thanks and, as 
always, comments welcome.

=============================================================================================================
Section 4.6.6.3
Business Signals
[add before this sentence that leads into a section talking about 
success, timeout, etc.]
Change from:
.......Failure to send either signal, when required (by specifying a 
timeout value in timeToAcknowledgeReceipt or 
timeToAcknowledgeAcceptance), will result in the transaction being null 
and void......

Change to:
.......Based on agreement between the parties, the requesting party 
typically MAY recognize that the business document had been successfully 
received and processed. Where applicable and used, the logical sequence 
of the Receipt Acknowledgement, Acceptance Acknowledgement and Response 
are based on the timing expectations defined. For example, in 
implementation, if an Acceptance Acknowledgement is received prior to a 
Receipt Acknowledgement, the requesting party may wait (if no timeout), 
for the Receipt Acknowledgement because the two business signals are 
handled by different systems.

Business protocol engines are expected to deal with the precedence of 
the receipt of business signals. Many eBusiness systems are completely 
asynchronous, whereby there is no way to guarantee that physical receipt 
will be sequenced. Logical receipt however is sequenced.

Failure to send either signal, when required (by specifying a timeout 
value in timeToAcknowledgeReceipt or timeToAcknowledgeAcceptance), will 
result in the transaction being null and void......

=============================================================================================================