[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebbp] 10/8/2004: We're almost there for v2.0 general exceptions/NOF
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]