[ebbp] 10/8/2004: We're almost there for v2.0 general exceptions/NOF

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

Great session today and good inputs from those user representatives 
present. Summary for v2.0 boundaries:

    * Exceptions occur when you have control.
          o General exceptions most often apply to:
                + Don't have signals defined. Need to send an exception
                  (other than timeout).
                + Sent RA. No AA. Need to send an exception (same).
                + Sent RA and AA. Expecting to send a response. Need to
                  send an exception (same).
                + Sent signals if required. Sent a response.  Need to
                  send an exception (same).
          o Separate NOF from exceptions.
    * NOF:
          o Occurs after the other business transaction has takes place.
            Recognize that NOF is separate from business transaction
            that initiates the agreement between the parties.
          o Party doesn't have control.
          o Condition precludes you meeting your obligation.
          o Defined as a BT pattern already.
          o At this time, it is trading partner specific on how this is
            used and handled.
          o Separate NOF from exceptions.

Post v2.0: Understand more about NOF and looking for guidance on offer 
revocation.  Looking to UBAC to provide guidance.

ACTIONS:
NAGAHASHI: Provide more RN feedback.
MUKKAMALA: Provide an example of general exception.

More detailed discussion and references attached. Thank you.
General exceptions and NOF special final session with users
8 Oct 2004

Present:
Arrott
Moberg
Mukkamala
Nagahashi
St. Amand
Webber
Martin

Regrets:
Dubray
Kulvantunyou

References:
Detailed summary: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00002.html
NOF and exception criteria: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00011.html
Query to users: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00009.html
Updated details re: NOF and requester: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00040.html

Martin: Summary (see above).
Arrott: Roles depend on trading model. NOF involves deal is falling apart. A marketplace is a broker for both parties. Communicating prices from buyer to seller.
Seller doesn't get price or doesn't respond. Buyer has accepted the price; expects the deal to be done. Marketplace
is in a precarious position; timeout occurs. Seller doesn't respond and marketplace can't respond. NOF should be
sent.
Moberg: Difficult to handle if business document can be anything. If signal, this impacts state synchronization.
Largest issue relates to waiting for expiration of NOF by requesting party. Dubray made this point.
Martin: I think that Dubray indicated an NOF cannot occur if an AA has.
Mukkamala: We saw this problem Dale outlines.
Martin: Couldn't that be optional?
Mukkamala: RosettaNet has taken that as the assumption.
(In RN) With backend integration, even after an AA, a problem could occur and a NOF may be required to be used. 
Webber: Staged scenario could see this condition as well. Do we use more modular BTA to handle this?
Martin: Are you suggesting you had a BTA that is optional to be used that includes the NOF?
Webber: Yes.
Arrott: Are you saying it is a new transaction?
Webber: No, not really.
Arrott: A NOF is a place of true exception and is handled usually by humans (with decision on who pays for it).
We had an agreement. Something occurs and I can't meet contract.
Moberg: Doesn't relate to cancellation logic?
Arrott: State is a new negotiation. This is state misalignment. You have to reference the transaction that has failed.
Webber: In v2.0, this implies human remediation. Later we could possibly create agent software and handles it in an automated fashion.
Martin: Use at your own risk in v2.0?
Webber: In their own fashion. Requires humans.

Martin: Here is what we have agreed in summary:
a. Notification pattern exists.
b. Recognize that NOF is separate from business transaction that initiates the agreement between the parties.
c. We recognize it is trading partner specific on how this is used and handled.
d. In the v2.0 we need to give some description around the timeouts, use of NOF, and 
specifically separate from general exception.

All present, in general, seem agreeable.

Nagahashi: I like Webber's analogy of throw/catch. This is a special condition that impacts transaction.
Arrott: Can't handle 100% of issues that can affect deal. You have to allow the normal process but provide an ability that recognizes
the issues impact the contract but are outside of its mainstream operational flow.

General Exceptions:
Martin: Provided some boundaries about exceptions in email summary 5 Oct 2004.
Reference: http://www.oasis-open.org/archives/ebxml-bp/200410/msg00011.html

Mukkamala: Negative RA and AA are different exception signals.

Primary conditions where a general exception could be sent.
General exception and exception signals in general apply when
you are in the business transaction.  We discussed in the context of the responder
(m2: however I think it could apply to either party).
a. Don't have signals defined. Need to send an exception (other than timeout).
b. Sent RA. No AA. Need to send an exception (same).
c. Sent RA and AA. Expecting to send a response. Need to send an exception (same).
d. Sent signals if required. Sent a response.  Need to send an exception (same).

Martin: We are uncertain the extent of revocation for NOF and other criteria.
Arrott: It is outside of the transaction; concluded the deal. State alignment is achieved. We need to retrench with NOF.
Mukkamala, Webber: Agree.
Webber: Totally unforeseen conditions involve NOF.
Mukkamala: Handle out of band scenarios using NOF.
Nagahashi: Some of the exceptions and NOF that are used in RN are because they don't use AA.
St. Amand: We still have to address changing of roles and perception of state alignment 
which need need more clarity in the future (in a later version?).

ACTIONS:
NAGAHASHI: Provide more RN feedback.
MUKKAMALA: Provide an example of general exception.