[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebbp 10/4/2004: More on NOF for Today's Resolution Scoping
In preparation for today's discussion: I've attempted to solidify many
discussions regarding NOF and how it touches business retries as we try
to finalize the scope for Notification of Failure. Here are some of our
recent stated goals for NOF:
* Clarify the retry counts including original message. DONE
* Specify resetting timers. DONE
* Specify how to specify TTP, TTAR, TTAA when retries are used. SEE EXAMPLES
* Specify checkpoint semantics for state alignment and, in v3.0, for transactional specifics for multi-party.
* Specify front- and backend-system differentiation. SEE EXAMPLES.
Different models can be derived from possible NOF in UMM R10, Chapter 8 (These are not all inclusive). If I have misconstrued any, please let me know.
I was crossed eyed (literally in creating different cases).
Buyer Request=> [1]
Expecting RA
Timeout occurs on RA
Buyer Retry Request=>
-OR-
Buyer NOF (possible revocation of offer)=>
<=RA Seller
[1] In this case: a) Assumes no RA is received during that BTA. b) The business retry exists on the Requesting Business Activity, and is used if there is a business protocol failure. As shown above, if the RA is sent by the Seller and crosses either a retry or NOF, the last understood state should be consistent between the two parties.
Buyer Request=>
<=RA Seller
RA not properly received (something wrong with RA not timeout)
Buyer General Exception (possible if RA not properly received) [2]=>
-OR-
Buyer Retry Request (if not properly received)=>
-OR-
Buyer NOF=>
[2] UMM doesn’t explicitly talk about general exception signals, but talks about exiting a transaction by the responder. Discuss further.
Buyer Request=>
Timeout
<=RA Seller
RA not properly received because of timeout
Buyer Retry Request=>
-OR-
Buyer NOF (possible revocation of offer)=>
Buyer Request=>
<=RA Seller
<=AA Seller
Can’t complete for some reason
Exit transaction [3]
[3] The UMM is not explicit if the Responder can issue a NOF. It stands to reason the answer is yes as Chapter 8 specifies that both parties, if under agreement, must properly receipt business documents within an agreed upon time. If the RA were received after the timeout, what would be the outcome – another exit transaction by the responder?
Buyer Request=>
<=RA Seller
No AA received (is expected from Seller)
Timeout
Buyer Retry Request=>
-OR-
Buyer NOF (possible revocation of offer if timeout)=>
Buyer Request=>
Can’t properly process request
Exit transaction
<=Negative RA Seller (can’t process document)
Terminate Seller
No chance to retry (reinitiate) [4]
[4] From R10: If any business exceptions (includes negative receipt and acceptance acknowledgements) are signaled then the business transaction must terminate. The business transaction must not be re-initiated even if the retryCount parameter is not zero. Business transactions must only be retried if a timeout exception is thrown.
Buyer Request=>
<=RA Seller
Can’t properly process request
<=Negative AA Seller
Terminate Seller
No chance to retry (reinitiate) [same as exit transaction?]
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Can’t properly process response
Buyer Negative RA=>
Buyer Terminate
No chance to retry (reinitiate)
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Can’t properly process response to send when written to disk, for example and disk crashes in unrecoverable fashion.
Exit transaction [3 Apply here? Not specified in UMM.]
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Buyer RA=>
Can’t properly process response
Buyer Negative AA=>
Buyer Terminate
No chance to retry (reinitiate)
(RosettaNet case)
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Buyer RA=>
Can’t properly process response
Buyer NOF=>
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Timeout (RA expected)
Exit transaction [3 see above]
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Expecting RA
Timeout
Buyer RA=>
Exit transaction Seller [3 see above]
If non-repudiation:
Buyer Request=>
Expecting RA Seller
Timeout
Buyer Failed Business Control (seems to be an NOF) [5]=>
[5] This is the logical conclusion. Could also apply if RA Seller sent but not AA Seller. Could also apply if RA and AA sent but no response.
Open question exists what is the difference between failed business control and exit transaction (seem to have same net effect). Both of these seem to be extraneous events that necessitate the invalidation of a transaction. This is supported by:
Reference: ebXML BPSS v1.1, Section 5.14.2.3
isNonRepudiationOfReceiptRequired.
Both partners agree to mutually verify receipt of a requesting business document and that the receipt must be non-repudiable. A requesting partner must initiate a notification of failure business transaction business (possibly revoking a contractual offer) if a responding partner has not properly delivered signed their receipt. For a further discussion of nonrepudiation of receipt, see ebXML E-Commerce and Simple Negotiation Patterns report.
In previous meetings with the now defunct BCP team and UMM team (still active), it was heavily debated about the impact of signals on the transaction when the failures occurred on the requesting side to the responder business document. If a responder does not receive a receipt acknowledgement or acceptance within its timer period then the transaction fails on the responder side. Different schools of thought existed as to the signals' use and any impact on the terms and conditions. At that time, it was agreed that synchronization
could occur as long as the terms and conditions were not
changed from the Request. This may indicate that the business agreement would have to explicitly or indirectly specify that an exception could occur in this case. It may also infer some leeway to Steve Capell’s request about retries. For example, substitution could occur within parameters of the catalog that parties are operating under – substitution of products, deliveries, number of items – where you modify business objects not terms and conditions.
If non-repudiation:
Buyer Request=>
<=RA Seller
<=AA Seller
<=Response Seller
Expecting RA Buyer
Timeout
<=Seller Failed Business Control (seems to be an NOF) [5 above]
Some differences our users have identified for NOF and general exceptions:
BT
==
1. BT has differentiated use of general exception signals when signals could still be used and there are general failures.
2. BT could use NOF when all signals have been exhausted and general failures occur.
RosettaNet
==========
RosettaNet uses NOF when there is a problem processing the business document. This could equate to the sending of an AA (if RosettaNet indeed did use) and then some disconnect between front- and back-end systems occur and the PO must be invalidated.
a. If timeout waiting for RA
b. f timeout occurs + no/no more retries are specified or are available
c. If processing error after Receipt Ack [6]
[6] Option exists to suggest an AA but this assumes the NOF is part of the transaction not a separate one, which is what has been suggested.
Amazon
======
Amazon has as seen different expected and unexpected failures. Don't want to handle unexpected failures; expected failures need to translate to a business result. Example, expecting a quote, but never received. Another transaction must occur. This doesn't mean abandonment with the protocol. Using an NOF or a business retry allows them to presuppose failures and handle somewhat as expected.
Open Questions:
1. Is an exit transaction also an NOF for the Responder? I would favor the answer is yes.
2. What if a NOF is to be sent on an alternate channel? [7]
3. Is an exit transaction the same as a failed business control (seem to be the same)?
4. Can NOF be precluded if AA is used in a transaction? Is this actually a pre-condition on the NOF (new pattern and a transaction) that no AA has been or could be sent, or no AA has been sent and non-repudiation applies.
5. Typically you cannot send an AA if the appropriate flag isn't set and the pattern is complete. Can we send AnyProtocolFailure outside of a transaction? BT uses a general exception even if no signals are allowed.
6. Would a notification message be appropriate inline within the business transaction prior to allowing use of NOF? Tell has asked about the use of a friendly notification message and this could be the business retry.
7. With business retries and NOF, do we then also allow reusable exception handling? [8]
8. If a retry occurs and crosses the expected response or signal, how is this handled? The previous discussions with BCP and UMM teams indicated the parties should be consistent in the last known state. How is this accomplished?
[7] Seems acceptable. BPSS doesn’t specify the channel although this may raise need for a channel type so the NOF is related to the correct party (in this case Buyer to Seller or vice versa). Assumes a NOF is a separate transaction.
[8] Relates indirectly to Steve Capell’s questions about ‘repairing’ logical errors that infers another signal may result (positive or negative even). We had originally planned to handle exception handling as a reusable step in WI-2 for v3.0.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]